Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The HTTP crash course nobody asked for

fasterthanli.me

Post reply on HN
Print view View original

21–30 of 149 posts

Re: The HTTP crash course nobody asked for

#21

Post by Aissen »

Denvercoder9 wrote: post #5
stevewatson301 wrote: post #4

Earlier quoted context omitted.

Depending on your version of nc, -c is for sending CRLFs or executing sent data as commands. You might be looking for ncat instead.

In OpenBSD nc (as GP mentioned), -c is for a TLS connection: https://man.openbsd.org/nc.1

Reminder, there are many different netcats, here are some of the most commons:

- netcat-traditional http://www.stearns.org/nc/

- netcat-openbsd : https://github.com/openbsd/src/blob/master/usr.bin/nc/netcat... (also packaged in Debian)

- ncat https://nmap.org/ncat/

- netcat GNU: https://netcat.sourceforge.net/ (quite rare)

To prevent any confusion, I like to recommend socat: http://www.dest-unreach.org/socat/

Re: The HTTP crash course nobody asked for

#22

Post by pletnes »

411111111111111 wrote: post #18
danuker wrote: post #12

Earlier quoted context omitted.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

WiFi supposedly needs more power and has higher latency. Not sure how true that remains post WiFi6 though

Range and bandwidth is orders of magnitude larger, and both have direct limitations in terms of energy budget.

Re: The HTTP crash course nobody asked for

#23

Post by fasterthanlime »

Andys wrote: post #13

I learned HTTP1 pretty well but not much of 2. Since playing with QUIC, I've lost all interest in learning HTTP/2, it feels like something already outdated that we're collectively going to skip over soon.

I tend to agree with you there, however the thing I'm replacing does HTTP/2, and HTTP/3 is yet another can of worms as far as "production multitenant deployment" goes, so, that's what my life is right now.

As far as learning goes, I do think HTTP/2 is interesting as a step towards understanding HTTP/3 better, because a lot of the concepts are refined: HPACK evolves into QPACK, flow control still exists but is neatly separated into QUIC, I've only taken a cursory look at H3 so far but it seems like a logical progression that I'm excited to dig into deeper, after I've gotten a lot more sleep.

Re: The HTTP crash course nobody asked for

#24

Post by sireat »

Is HTTP always the same protocol as HTTPS - given the same version - and ignoring the encryption from TLS?

Theoretically yes, but in practice?

I've done my share of nc testing even simpler protocols than HTTP/1.1

For some reason the migration to HTTPS scared me despite the security assurances. I could not see anything useful in wireshark anymore. I now had to trust one more layer of abstraction.

Re: The HTTP crash course nobody asked for

#25

Post by masklinn »

Andys wrote: post #13

I learned HTTP1 pretty well but not much of 2. Since playing with QUIC, I've lost all interest in learning HTTP/2, it feels like something already outdated that we're collectively going to skip over soon.

FWIW HTTP/3 very much builds upon / reframes HTTP/2’s semantics, so it might be useful to get a handle on /2, as I’m not sure all the /3 documentation will frame it in /1.1 terms.

Re: The HTTP crash course nobody asked for

#26

Post by masklinn »

danuker wrote: post #12
Donckele wrote: post #10

“By contrast, I think about Bluetooth a lot. I wish I didn't.” LOL, yes same here. Can’t wait for Bluetooths b̶a̶l̶l̶s̶ baggage to be chopped.

How is WiFi so much more reliable than Bluetooth? I installed a web server on my phone and send files this way much faster (and Android -> Apple works): https://f-droid.org/en/packages/net.basov.lws.fdroid/ I wish there were a standard for streaming (headphones could connect to your network via WPS, and stream some canonical URL with no configuration needed).

> How is WiFi so much more reliable than Bluetooth?

WiFi uses near 10x the power Bluetooth does when active (and that’s before factoring in BLE which cuts that down in half). WiFi also has access to the much less crowded 5GHz band.

IIRC WiFi is also a much simpler protocol, it’s just a data channel (its aim being to replace LAN cables).

Plus in order to support cheap and specialised devices Bluetooth supports all sorts of profiles and applications. This makes the devices simpler, and means all the configuration can be automated to pairing, but it makes the generic hosts a lot more complicated.

Re: The HTTP crash course nobody asked for

#27

Post by dochtman »

sireat wrote: post #24

Is HTTP always the same protocol as HTTPS - given the same version - and ignoring the encryption from TLS? Theoretically yes, but in practice? I've done my share of nc testing even simpler protocols than HTTP/1.1 For some reason the migration to HTTPS scared me despite the security assurances. I could not see anything useful in wireshark anymore. I now had to trust one more layer of abstraction.

For 1.1 and 2, the byte stream is the same for TCP vs TLS over TCP. For 3, it uses one stream per request over a QUIC connection which is always encrypted.

Re: The HTTP crash course nobody asked for

#29

Post by st_goliath »

sireat wrote: post #24

Is HTTP always the same protocol as HTTPS - given the same version - and ignoring the encryption from TLS? Theoretically yes, but in practice? I've done my share of nc testing even simpler protocols than HTTP/1.1 For some reason the migration to HTTPS scared me despite the security assurances. I could not see anything useful in wireshark anymore. I now had to trust one more layer of abstraction.

> Is HTTP always the same protocol as HTTPS - given the same version - and ignoring the encryption from TLS?

> Theoretically yes, but in practice?

Yes, that's the whole point of encapsulation. The protocol is blissfully unaware of encryption and doesn't even have to be. It has no STARTTLS mechanism either.

Your HTTPS traffic consists of a TCP handshake to establishes a TCP connection, a TLS handshake across that TCP connection to exchange keys and establish a TLS session, and the exact, same HTTP request/response traffic, inside the encrypted/authenticated TLS session.

The wonderful magic of solving a problem by layering/encapsulating.

> I could not see anything useful in wireshark anymore

Wireshark supports importing private keys for that, see: https://wiki.wireshark.org/TLS

Re: The HTTP crash course nobody asked for

#30

Post by mihneawalker »

I_complete_me wrote: post #14

That was an excellent, well-written, well-thought out, well presented, interesting, humorous, enjoyable read. Coincidentally I recently did a Rust crash course so it all made perfect sense - I am not an IT pro. Anyhows, thanks.

I'd like to ask you what crash course on Rust did you take, as there are quite a few out there, and it would help if someone recommends a certain course.
Post reply on HN