4 ms·

Number one “HTTP is text based” was true, but with the advent of HTTP/2, it uses a binary protocol now

davydog187 4y ago
“ The client opens a random port to receive the request on, sends a SYN packet to the server, waits for a SYN-ACK packet from the server…” The client “connects” to the port, while the server opens/listens on that port. I should check if I can submit corrections to the OP. Great article, btw!
- ominous_prime 4y ago
  There’s a lot of things wrong with the article, but that’s not really one. A connection is started by binding a local port. You can’t receive the SYN-ACK if there’s no open socket to receive it.
- jesprenj 4y ago
  What's wrong exactly?
est31 4y ago
Yeah and in fact even for HTTP/1.1 only the start of requests/responses are plain text, as the content is transmitted in its raw, binary, form. If it's textual content, or none at all, it's definitely all text, but if it's say an image being uploaded, then the content is binary. I'm glad that HTTP was so pragmatic about this compared to purist e-mail with its base64. As for HTTP/2 changes, header names are now all lowercased (the article still works with 1.x casing). A stupid decision to lowercase if you ask me, but that's what the HTTP/2 authors went with. Lastly, the article mentions server push, but Chrome has announced its deprecation 2 years ago.
- secondcoming 4y ago
  Mandating lowercase is good because it makes parsing faster. Of course, there’s going to be some poorly coded client out there that ignores this rule and so everybody else will have to accommodate this half-assedness too.
  - est31 4y ago
    I get the arguments why lowercasing is better, and it's certainly more beautiful than making everything caps, but the transition from the old system to everything being lower case headers leads to a lot of bugs. https://github.com/cockpit-project/bots/commit/3cdbaa6d6765a583d337f4da7b9605a7c0223978 https://github.com/cockpit-project/bots/commit/3cdbaa6d6765a... https://github.com/edwardspec/mediawiki-aws-s3/issues/49 https://github.com/edwardspec/mediawiki-aws-s3/issues/49 https://github.com/firecracker-microvm/firecracker/pull/3006 https://github.com/firecracker-microvm/firecracker/pull/3006 https://github.com/snapview/tungstenite-rs/pull/267 https://github.com/snapview/tungstenite-rs/pull/267
    - secondcoming 4y ago
      Yes, libs that don’t adhere to the spec need to be fixed or deprecated.
- cesarb 4y ago
  > I'm glad that HTTP was so pragmatic about this compared to purist e-mail with its base64. The issue with e-mail is that it's store-and-forward, and the server which receives your message might have to forward it to another server which understands only 7-bit characters (using the 8th bit for parity). This worry might not make much sense nowadays, but remember that e-mail is old, back from before "all bytes are 8 bits" won over all other variants. As for HTTP, it was specified over TCP, which has always used 8-bit bytes, so it doesn't have to worry about systems which mangle or reject data with a high bit set.
MaxBarraclough 4y ago
It strikes me as misleading at best even regarding HTTP/1.1, which was of course still capable of transferring binary files. just text might be taken to indicate that it just supports text.
- bena 4y ago
  Yeah, but you have to convert the binary into a text representation. Same thing with email, you have to base64 encode binary to transform it into something capable of being represented by a string of ASCII characters.
  - jesprenj 4y ago
    No, you don't have to - you mustn't. Binary is transfered as binary, except in cases when the actual data contains already encoded values - www-form-urlencoded or application/json, ...

“ The client opens a random port to receive the request on, sends a SYN packet to the server, waits for a SYN-ACK packet from the server…” The client “connects” to the port, while the server opens/listens on that port. I should check if I can submit corrections to the OP. Great article, btw!

ominous_prime 4y ago
There’s a lot of things wrong with the article, but that’s not really one. A connection is started by binding a local port. You can’t receive the SYN-ACK if there’s no open socket to receive it.
jesprenj 4y ago
What's wrong exactly?

est31 4y ago

Yeah and in fact even for HTTP/1.1 only the start of requests/responses are plain text, as the content is transmitted in its raw, binary, form. If it's textual content, or none at all, it's definitely all text, but if it's say an image being uploaded, then the content is binary. I'm glad that HTTP was so pragmatic about this compared to purist e-mail with its base64. As for HTTP/2 changes, header names are now all lowercased (the article still works with 1.x casing). A stupid decision to lowercase if you ask me, but that's what the HTTP/2 authors went with. Lastly, the article mentions server push, but Chrome has announced its deprecation 2 years ago.

secondcoming 4y ago
Mandating lowercase is good because it makes parsing faster. Of course, there’s going to be some poorly coded client out there that ignores this rule and so everybody else will have to accommodate this half-assedness too.
- est31 4y ago
  I get the arguments why lowercasing is better, and it's certainly more beautiful than making everything caps, but the transition from the old system to everything being lower case headers leads to a lot of bugs. https://github.com/cockpit-project/bots/commit/3cdbaa6d6765a583d337f4da7b9605a7c0223978 https://github.com/cockpit-project/bots/commit/3cdbaa6d6765a... https://github.com/edwardspec/mediawiki-aws-s3/issues/49 https://github.com/edwardspec/mediawiki-aws-s3/issues/49 https://github.com/firecracker-microvm/firecracker/pull/3006 https://github.com/firecracker-microvm/firecracker/pull/3006 https://github.com/snapview/tungstenite-rs/pull/267 https://github.com/snapview/tungstenite-rs/pull/267
  - secondcoming 4y ago
    Yes, libs that don’t adhere to the spec need to be fixed or deprecated.
cesarb 4y ago
> I'm glad that HTTP was so pragmatic about this compared to purist e-mail with its base64. The issue with e-mail is that it's store-and-forward, and the server which receives your message might have to forward it to another server which understands only 7-bit characters (using the 8th bit for parity). This worry might not make much sense nowadays, but remember that e-mail is old, back from before "all bytes are 8 bits" won over all other variants. As for HTTP, it was specified over TCP, which has always used 8-bit bytes, so it doesn't have to worry about systems which mangle or reject data with a high bit set.

MaxBarraclough 4y ago

It strikes me as misleading at best even regarding HTTP/1.1, which was of course still capable of transferring binary files. just text might be taken to indicate that it just supports text.

bena 4y ago
Yeah, but you have to convert the binary into a text representation. Same thing with email, you have to base64 encode binary to transform it into something capable of being represented by a string of ASCII characters.
- jesprenj 4y ago
  No, you don't have to - you mustn't. Binary is transfered as binary, except in cases when the actual data contains already encoded values - www-form-urlencoded or application/json, ...