7 ms·

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to

by byuu 12y ago

> May nobody else have to suffer through writing an interoperable HTTP/1.1 parser! Yes, now it'll be much easier than parsing plain-text. Now they just have to write a TLS stack (several key exchange algorithms; block ciphers; stream ciphers; and data integrity algorithms); then implement the new HPACK compression; then finally a new parser for the HTTP/2 headers themselves. Now instead of taking maybe one day to write an HTTP/1.1 server, it'll only take a single engineer several years to write an HTTP/2 server (and one mistake will undermine all of its attempts at security.) If you are going to say, "well use someone else's TLS/HPACK/etc library!", then I'll say the same, "use someone else's HTTP/1.1 header parsing library!" HTTP/2 may turn out to be great for a lot of things. But making things easier/simpler to program is certainly not one of them. This is a massive step back in terms of simplicity.

ddalex_ro 12y ago
And the lack in simplicity is why it will fail. People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. People are not good with dealing with a single monstrous object of unfathomable proportions, they will try to break it down in things they understand. If the thing is too complex, with too many inputs, too many outputs and too many states, this is a recipe for confusion. This is why overly complicated things always fail in face of simple things. One could argue that FTP/SFTP was just as good as transferring bytes over network, but HTTP/1.0 won because it was simpler. HTTP/2 was written to tickle the egos of its developers, following the principle - it is hard to write, it is hard to read. And its downfall is going to come from this problem.
- stephen_g 12y ago
  I'm really confused by comments like these. Are you somebody who implements low-level network protocols? I've written parsers and generators for plenty of binary protocols. It's actually really not that bad - you just need slightly different tooling. Yes, if somebody else hasn't written those it takes a bit longer because you have to do that yourself, but you save a lot of time because it's far easier to parse than text. And guess what - people have already written plenty of tooling for HTTP/2 already... And HTTP/2 is fairly straightforward as protocols go (you wouldn't believe the crazy proprietary control protocols around the place - trust me, HTTP/2 is not at all bad) The 'downfall' of HTTP/2 is also a real long shot - most people are already browsing in browsers that support it, and for many web site owners, using it is literally adding two lines to an nginx configuration file...
- exelius 12y ago
  > People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. Not true! Text parsing is a pain in the ass; give me a well-documented binary protocol any day. On the upside, binary protocols tend to force good documentation. HTTP/1.1 is far from simple; every browser supports a slightly different implementation and the server is expected to serve to all of them. But a binary protocol is not any more difficult than a text-based protocol for someone with a decent knowledge of CS. If you don't have a decent knowledge of CS, you probably shouldn't be writing code at the protocol level. Besides, who in their right mind outputs directly to ANY protocol these days? Unless you're building a web server, you should be doing it through an abstraction layer because it's a proper architecture practice. Once abstraction layers are built for all of the major languages (which I'm willing to bet has already happened) it will become a non-issue.
nyir 12y ago
I haven't looked more into that, but wouldn't it also be viable now to start HTTP/1.2 with e.g. a more restrictive header grammar, restricting all existing features to what's actually used, at least on the server side? Clients with 1.1 support would keep working, but future clients would be simplified.
- byuu 12y ago
  That would be absolutely lovely. Since we're not viewing headers manually on 80x25 terminals anymore, we could do away with multi-line header values. That alone would drop off most of the complexity. (Being perfectly honest, even though it's part of the standard, you don't have to parse them now, anyway. I don't, and I've never had anyone complain to me about the site not working. Nothing mainstream sends them for the important fields.) Add a Server-Push header (filename+ETag), and we could eliminate most extraneous 304 Not Modified requests. Have browsers actually acknowledge Connection: keep-alive instead of opening tons of parallel requests. And leave this as the "hobbyist level, can't afford wildcard SSL certs" option, and I think it'd be quite beneficial. If browsers want to warn that it's not encrypted, fine. So long as they don't go into ridiculous hysteria levels like they do now with self-signed certs. One immediate potential downside is Apache. It completely ignores the protocol request. If you ask for "GET / HTTP/1.2", or even "GET / HackerNewsTP/3.141e", it will happily reply with "HTTP/1.1 200 OK" As a result, the negotiation would be trickier than with HTTP/2. But like you said, it could be done in a way that it's 100% backward-compatible with existing 1.1 software, so long as their responses are also in a compatible, simplified format (and most already are.)
  - IgorPartola 12y ago
    I am with you up to letting people use unencrypted HTTP. I assume people in this can use telnet instead of ssh because it is simpler. No, browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.
    - josteink 12y ago
      > browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live. To the people who keep insisting everything needs encryption: No it doesn't. Fuck off! You don't see me forcing PGP on on your email, do you? No? Fine, then let us non-weirdoes keep using plain HTTP where we want it, where we have determined that it is a good fit for our needs. Besides, this is purely a theoretical concern because a browser which drops support for plain HTTP wont have any user-base as soon people discover that 95% of the internet will broken when using that browser.
iopq 12y ago
HTTP/2 is easier to parse than HTTP/1.1 because there's less edge cases Also a bonus: no more "Referer" (sic)
- frnucz900 12y ago
  No referrer header at all, or did they fix the spelling? I looked in the HTTP/2 spec quickly and didn't see a mention but I could be missing something..
sambe 12y ago
I was under the impression that the parent was making the simplicity argument for people on the other side of things - people writing frameworks and websites. Using someone else's HTTP1.1 stack doesn't solve those problems. Then, separately, writing interoperable HTTP 1.1 is hard because it was designed/taken up ad-hoc in a time of relatively immature browsers. I would expect HTTP2 to increase standardisation in the same way newer HTML/CSS specs have relative to the late-nineties. That doesn't mean that initial implementation will not be more difficult, but it's done once every 20 years (per-vendor).
stephen_g 12y ago
Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc. Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things. Anyway, there are already plenty of good tools for debugging HTTP/2 streams (Wireshark filters, etc.), and there's only going to be plenty more as time goes by.
- carsonreinke 12y ago
  So won't HTTP/2 have these edge cases also?
  - TylerE 12y ago
    Essentially, no. HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set. HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.
    - byuu 12y ago
      > HTTP/2 is all 100% mandatory That's a nice idea in theory, but what makes you think anyone is going to adhere to that? Developers have always, and will always, do whatever they want when they implement your standards. It was bad enough that when I worked on a binary delta patching format, I made sure there were absolutely zero possible undefined values, because I knew someone might try and use them to add new functionality in. For something as complex as HTTP, I can guarantee you people will ignore parts of the spec they don't care about. And you can yell at them and say it's not a valid/legal HTTP/2 implementation, but they won't care. They'll keep on doing what they're doing.
      - TylerE 12y ago
        It's still a much better situation than HTTP/1.1. At least an HTTP/2 compliant implementation has an exact definition, that it either is, or isn't. An HTTP/1.1 implementation has a vast number of corner cases and optional bits. Sure, if you're out-of-spec, all bets are off. It's just that with hTTP/1.1 even 100% in-spec implementations are a pretty wide target zone.
lagg 12y ago
Thank you for saying this. I'm so fucking tired of the masturbation by and towards Google when it comes to this stuff. People are so used to reusing over-abstracted libs by large companies that they never think about the fact that they're both locking themselves in and actively harming robust standards (since a standard that only a few people can implement leads to only those people defining it. As is already happening here with Google). I have a side project going on where I'm doing videos for people I'm mentoring to show them what lower level systems programming looks like. One of these videos was socket I/O where I fetched a page via HTTP in about 10 lines. I'll never be able to do something like this again in the near future. Yet people call HTTP2 "simple".

by byuu 12y ago

ddalex_ro 12y ago

And the lack in simplicity is why it will fail. People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. People are not good with dealing with a single monstrous object of unfathomable proportions, they will try to break it down in things they understand. If the thing is too complex, with too many inputs, too many outputs and too many states, this is a recipe for confusion. This is why overly complicated things always fail in face of simple things. One could argue that FTP/SFTP was just as good as transferring bytes over network, but HTTP/1.0 won because it was simpler. HTTP/2 was written to tickle the egos of its developers, following the principle - it is hard to write, it is hard to read. And its downfall is going to come from this problem.

stephen_g 12y ago
I'm really confused by comments like these. Are you somebody who implements low-level network protocols? I've written parsers and generators for plenty of binary protocols. It's actually really not that bad - you just need slightly different tooling. Yes, if somebody else hasn't written those it takes a bit longer because you have to do that yourself, but you save a lot of time because it's far easier to parse than text. And guess what - people have already written plenty of tooling for HTTP/2 already... And HTTP/2 is fairly straightforward as protocols go (you wouldn't believe the crazy proprietary control protocols around the place - trust me, HTTP/2 is not at all bad) The 'downfall' of HTTP/2 is also a real long shot - most people are already browsing in browsers that support it, and for many web site owners, using it is literally adding two lines to an nginx configuration file...
exelius 12y ago
> People are good with dealing with a small number of simple things that can be stacked together. Throw in a human-readable data stream, and you're set to understand and use a stack of simple programs. Not true! Text parsing is a pain in the ass; give me a well-documented binary protocol any day. On the upside, binary protocols tend to force good documentation. HTTP/1.1 is far from simple; every browser supports a slightly different implementation and the server is expected to serve to all of them. But a binary protocol is not any more difficult than a text-based protocol for someone with a decent knowledge of CS. If you don't have a decent knowledge of CS, you probably shouldn't be writing code at the protocol level. Besides, who in their right mind outputs directly to ANY protocol these days? Unless you're building a web server, you should be doing it through an abstraction layer because it's a proper architecture practice. Once abstraction layers are built for all of the major languages (which I'm willing to bet has already happened) it will become a non-issue.

nyir 12y ago

I haven't looked more into that, but wouldn't it also be viable now to start HTTP/1.2 with e.g. a more restrictive header grammar, restricting all existing features to what's actually used, at least on the server side? Clients with 1.1 support would keep working, but future clients would be simplified.

byuu 12y ago
That would be absolutely lovely. Since we're not viewing headers manually on 80x25 terminals anymore, we could do away with multi-line header values. That alone would drop off most of the complexity. (Being perfectly honest, even though it's part of the standard, you don't have to parse them now, anyway. I don't, and I've never had anyone complain to me about the site not working. Nothing mainstream sends them for the important fields.) Add a Server-Push header (filename+ETag), and we could eliminate most extraneous 304 Not Modified requests. Have browsers actually acknowledge Connection: keep-alive instead of opening tons of parallel requests. And leave this as the "hobbyist level, can't afford wildcard SSL certs" option, and I think it'd be quite beneficial. If browsers want to warn that it's not encrypted, fine. So long as they don't go into ridiculous hysteria levels like they do now with self-signed certs. One immediate potential downside is Apache. It completely ignores the protocol request. If you ask for "GET / HTTP/1.2", or even "GET / HackerNewsTP/3.141e", it will happily reply with "HTTP/1.1 200 OK" As a result, the negotiation would be trickier than with HTTP/2. But like you said, it could be done in a way that it's 100% backward-compatible with existing 1.1 software, so long as their responses are also in a compatible, simplified format (and most already are.)
- IgorPartola 12y ago
  I am with you up to letting people use unencrypted HTTP. I assume people in this can use telnet instead of ssh because it is simpler. No, browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live.
  - josteink 12y ago
    > browsers should drop support for unencrypted HTTP soon after Let's Encrypt goes live. To the people who keep insisting everything needs encryption: No it doesn't. Fuck off! You don't see me forcing PGP on on your email, do you? No? Fine, then let us non-weirdoes keep using plain HTTP where we want it, where we have determined that it is a good fit for our needs. Besides, this is purely a theoretical concern because a browser which drops support for plain HTTP wont have any user-base as soon people discover that 95% of the internet will broken when using that browser.

iopq 12y ago

HTTP/2 is easier to parse than HTTP/1.1 because there's less edge cases Also a bonus: no more "Referer" (sic)

frnucz900 12y ago
No referrer header at all, or did they fix the spelling? I looked in the HTTP/2 spec quickly and didn't see a mention but I could be missing something..

sambe 12y ago

I was under the impression that the parent was making the simplicity argument for people on the other side of things - people writing frameworks and websites. Using someone else's HTTP1.1 stack doesn't solve those problems. Then, separately, writing interoperable HTTP 1.1 is hard because it was designed/taken up ad-hoc in a time of relatively immature browsers. I would expect HTTP2 to increase standardisation in the same way newer HTML/CSS specs have relative to the late-nineties. That doesn't mean that initial implementation will not be more difficult, but it's done once every 20 years (per-vendor).

stephen_g 12y ago

Have you tried writing anything more than a very simple HTTP/1.1 parser/server? It's actually not as easy as it seems at first - edge cases everywhere, different user agents doing subtly different things, etc. etc. Your argument is invalid in my opinion. HTTP/1.1 is not simple to implement to any decent level of completeness and correctness, and HTTP/2 does fix a fair few things. Anyway, there are already plenty of good tools for debugging HTTP/2 streams (Wireshark filters, etc.), and there's only going to be plenty more as time goes by.

carsonreinke 12y ago
So won't HTTP/2 have these edge cases also?
- TylerE 12y ago
  Essentially, no. HTTP/1.1 contains tons of optional features. Practially no two implementations support the same set. HTTP/2 is all 100% mandatory. Any compliant HTTP/2 implementation will support an EXACT set of known features.
  - byuu 12y ago
    > HTTP/2 is all 100% mandatory That's a nice idea in theory, but what makes you think anyone is going to adhere to that? Developers have always, and will always, do whatever they want when they implement your standards. It was bad enough that when I worked on a binary delta patching format, I made sure there were absolutely zero possible undefined values, because I knew someone might try and use them to add new functionality in. For something as complex as HTTP, I can guarantee you people will ignore parts of the spec they don't care about. And you can yell at them and say it's not a valid/legal HTTP/2 implementation, but they won't care. They'll keep on doing what they're doing.
    - TylerE 12y ago
      It's still a much better situation than HTTP/1.1. At least an HTTP/2 compliant implementation has an exact definition, that it either is, or isn't. An HTTP/1.1 implementation has a vast number of corner cases and optional bits. Sure, if you're out-of-spec, all bets are off. It's just that with hTTP/1.1 even 100% in-spec implementations are a pretty wide target zone.

lagg 12y ago

Thank you for saying this. I'm so fucking tired of the masturbation by and towards Google when it comes to this stuff. People are so used to reusing over-abstracted libs by large companies that they never think about the fact that they're both locking themselves in and actively harming robust standards (since a standard that only a few people can implement leads to only those people defining it. As is already happening here with Google). I have a side project going on where I'm doing videos for people I'm mentoring to show them what lower level systems programming looks like. One of these videos was socket I/O where I fetched a page via HTTP in about 10 lines. I'll never be able to do something like this again in the near future. Yet people call HTTP2 "simple".