6 ms·

"HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities,

by akerl_ 12y ago

"HTTP/2.0 is not a technical masterpiece. It has layering violations, inconsistencies, needless complexity, bad compromises, misses a lot of ripe opportunities, etc." I wish the article had spent more time talking about these things rather than rambling about "politics". "HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." That would have destroyed any hope of adoption by content providers and probably browsers. "HTTP/2.0 will require a lot more computing power than HTTP/1.1 and thus cause increased CO2 pollution adding to climate change." Citation? That said, I'm not considerably shocked that web standards aren't judged based on the impact of whatever computing devices may end up using them on their power grids and those power grids' use of energy sources. "The proponents of HTTP/2.0 are also trying to use it as a lever for the "SSL anywhere" agenda, despite the fact that many HTTP applications have no need for, no desire for, or may even be legally banned from using encryption." In the same paragraph, the author complains that HTTP/2.0 has no concern for privacy and then that they attempted to force encryption on everybody. "There are even people who are legally barred from having privacy of communication: children, prisoners, financial traders, CIA analysts and so on." This is so close to "think of the children" that I don't even know how to respond. The listed groups may have restrictions placed on them in certain settings that ensure their communications are monitored. But this doesn't prevent HTTP/2.0 with TLS from existing: there are a variety of other avenues by which their respective higher-ups can monitor the connections of those under their control.

ibotty 12y ago
> That would have destroyed any hope of adoption by content providers and probably browsers. why adoption by browsers?
- akerl_ 12y ago
  I'm less sure browsers wouldn't adopt, but if content providers are slow to adopt due to massive changes in how they handle sessions / tracking / everything else they do with cookies, browsers are not incentivized to adopt. I suspect it would end up looking similar to IPv6: Unless ISPs are providing the majority of users with IPv6, software developers aren't well incentivized to support IPv6 in their software. Similarly to browsers, they'd lose very little for supporting the new standard now, but the gains are low while adoption by the other group is low.
  - boracay 12y ago
    I don't see how this should stop us from fixing legitimate problems. As far as I know IPv6 adaptation is not a software problem at this point.
    - vidarh 12y ago
      You are not fixing legitimate problems if the new spec never gets adopted by anyone.
      - iopq 12y ago
        The new spec wouldn't get adopted it if didn't offer anything better. See: IPv6
        akerl_ 12y ago
        "won't". It hasn't been adopted by even a significant portion of the internet yet, and based on these discussions I'm fearful it will turn out exactly like IPv6.
      - boracay 12y ago
        That's not really my position to represent though. As an engineer you have to be firm if the issue is worthwhile. Just because the tech industry is a largely a vertical oligopoly doesn't mean we should support it. Technology would be a better place if the parties opposing security, robustness, privacy etc. would have to take an active stand against it rather than being able to hide behind vague design decisions. I do also think there are things that aren't worthwhile to be fighting for though.
Argorak 12y ago
PHK discusses a lot of these point here: http://www.infoq.com/presentations/HTTP-Performance http://www.infoq.com/presentations/HTTP-Performance (especially his views on encryption) (sorry for the repost, this wasn't posted when I posted the other one)
- jerf 12y ago
  This is probably a better link: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html There's a lot of fairly concrete issues in there, concrete suggestions for improvements, concrete suggestions for better problems to focus on (it's hard to overestimate how important that is for proper engineering!), and it's in text instead of a 40 minute video.
  - Argorak 12y ago
    I disagree, the link is also interesting, but as I said further down: the video holds an interesting discussion of his views on encryption, especially end-to-end, something the parent explicitly discussed.
  - MichaelGG 12y ago
    So as a problem, he lists server push. What other proposals are there to get rid of stuff like spritesheets?
- Luker88 12y ago
  Just saw it. Basically he's an advocate of the "only bad guys want privacy everywhere". I still have not seen a single proposal from him that is not "forget about crypto", or "let everything be tracked". He doesn't seems to even understand how basic key exchange work, and all his arguments boil down to "I think they can break it anyway, so we should stop using it". IMHO, forget about him. he has no proposal and his understanding of security and crypto is downright dangerous.
  - phkamp 12y ago
    You obviously havn't spent much time looking either, have you? You could look at section 15 here for instance: http://phk.freebsd.dk/words/httpbis.html http://phk.freebsd.dk/words/httpbis.html With respect to key-exchange, maybe the problem is that I do understand, and therefore know that there is a difference between privacy and secrecy ? Some places we want privacy, some places we want secrecy. Mandating privacy everywhere makes it almost mandatory for police-states to trojan the privacy infrastructure (ie: CA's -- yes they already did), and therefore we have neither privacy nor secrecy anymore. PS: Dangerous for who ? PPS": Google "Operation Orchestra" if you don't undstand the previous question.
joosters 12y ago
"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them. Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!
- deleted 12y ago
  [deleted]
- hrjet 12y ago
  > there's no need for this to be tied in with HTTP/2.0 at all. Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.
- robomc 12y ago
  Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).
  - organsnyder 12y ago
    I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.
  - phkamp 12y ago
    It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
nly 12y ago
> That would have destroyed any hope of adoption by content providers and probably browsers. Bullshit, browser vendors have always lead the way on web tech. Remember XMLHttpRequest (Microsoft)? How about Javascript or SSL, both invented by Netscape? A proper session layer is inevitable for HTTP. Websites are no longer stateless, making HTTP an ill-suited protocol. We should just accept it and move on.
- akerl_ 12y ago
  I believe that browser vendors will push technology that benefits them. That's definitely not in dispute. But you need to convince them that HTTP/2.0 is beneficial to them, and I don't think that will be easy if content providers aren't serving content via HTTP/2.0.
  - tracker1 12y ago
    Most of the enhancements I'm aware of HTTP/2 are centered around SPDY.. along with persistent connections. The upconvert for SPDY and WebSocket connections are interesting on HTTP/1.0, I kind of wish that this had worked hand in hand with DNS to allow for DNSSEC publishing of public encryption keys for use with HTTP, then HTTP negotiating against that key. I also wish there were layer between full encryption for content that is intended to be available for http and https (without the extra overhead) for signed content.
    - ibotty 12y ago
      What you want re public keys in dnssec secured DNS is called Dane. Browsers are slow to implement it though.
- pfraze 12y ago
  if you need to have a stateful connection, why not just use websockets? in many other cases (eg asset fetching) http/http2 are fine
imajes 12y ago
Re the environmental impact: A large contingent of internet networked servers are webservers, transacting with the HTTP protocol (be it spiders or producers or whatever). If it takes more computing resources to provide HTTP/2.0, then it would in fact require more servers, and thus increase the energy consumption. But given how large datacenter consumers are considering how to build greener/smarter operations to reduce their impact (and costs) then clearly it's something to be mindful of.

by akerl_ 12y ago

ibotty 12y ago

> That would have destroyed any hope of adoption by content providers and probably browsers. why adoption by browsers?

akerl_ 12y ago
I'm less sure browsers wouldn't adopt, but if content providers are slow to adopt due to massive changes in how they handle sessions / tracking / everything else they do with cookies, browsers are not incentivized to adopt. I suspect it would end up looking similar to IPv6: Unless ISPs are providing the majority of users with IPv6, software developers aren't well incentivized to support IPv6 in their software. Similarly to browsers, they'd lose very little for supporting the new standard now, but the gains are low while adoption by the other group is low.
- boracay 12y ago
  I don't see how this should stop us from fixing legitimate problems. As far as I know IPv6 adaptation is not a software problem at this point.
  - vidarh 12y ago
    You are not fixing legitimate problems if the new spec never gets adopted by anyone.
    - iopq 12y ago
      The new spec wouldn't get adopted it if didn't offer anything better. See: IPv6
      - akerl_ 12y ago
        "won't". It hasn't been adopted by even a significant portion of the internet yet, and based on these discussions I'm fearful it will turn out exactly like IPv6.
    - boracay 12y ago
      That's not really my position to represent though. As an engineer you have to be firm if the issue is worthwhile. Just because the tech industry is a largely a vertical oligopoly doesn't mean we should support it. Technology would be a better place if the parties opposing security, robustness, privacy etc. would have to take an active stand against it rather than being able to hide behind vague design decisions. I do also think there are things that aren't worthwhile to be fighting for though.

Argorak 12y ago

PHK discusses a lot of these point here: http://www.infoq.com/presentations/HTTP-Performance http://www.infoq.com/presentations/HTTP-Performance (especially his views on encryption) (sorry for the repost, this wasn't posted when I posted the other one)

jerf 12y ago
This is probably a better link: https://www.varnish-cache.org/docs/trunk/phk/http20.html https://www.varnish-cache.org/docs/trunk/phk/http20.html There's a lot of fairly concrete issues in there, concrete suggestions for improvements, concrete suggestions for better problems to focus on (it's hard to overestimate how important that is for proper engineering!), and it's in text instead of a 40 minute video.
- Argorak 12y ago
  I disagree, the link is also interesting, but as I said further down: the video holds an interesting discussion of his views on encryption, especially end-to-end, something the parent explicitly discussed.
- MichaelGG 12y ago
  So as a problem, he lists server push. What other proposals are there to get rid of stuff like spritesheets?
Luker88 12y ago
Just saw it. Basically he's an advocate of the "only bad guys want privacy everywhere". I still have not seen a single proposal from him that is not "forget about crypto", or "let everything be tracked". He doesn't seems to even understand how basic key exchange work, and all his arguments boil down to "I think they can break it anyway, so we should stop using it". IMHO, forget about him. he has no proposal and his understanding of security and crypto is downright dangerous.
- phkamp 12y ago
  You obviously havn't spent much time looking either, have you? You could look at section 15 here for instance: http://phk.freebsd.dk/words/httpbis.html http://phk.freebsd.dk/words/httpbis.html With respect to key-exchange, maybe the problem is that I do understand, and therefore know that there is a difference between privacy and secrecy ? Some places we want privacy, some places we want secrecy. Mandating privacy everywhere makes it almost mandatory for police-states to trojan the privacy infrastructure (ie: CA's -- yes they already did), and therefore we have neither privacy nor secrecy anymore. PS: Dangerous for who ? PPS": Google "Operation Orchestra" if you don't undstand the previous question.

joosters 12y ago

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them. Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!

deleted 12y ago
[deleted]
hrjet 12y ago
> there's no need for this to be tied in with HTTP/2.0 at all. Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.
robomc 12y ago
Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).
- organsnyder 12y ago
  I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.
- phkamp 12y ago
  It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.

nly 12y ago

> That would have destroyed any hope of adoption by content providers and probably browsers. Bullshit, browser vendors have always lead the way on web tech. Remember XMLHttpRequest (Microsoft)? How about Javascript or SSL, both invented by Netscape? A proper session layer is inevitable for HTTP. Websites are no longer stateless, making HTTP an ill-suited protocol. We should just accept it and move on.

akerl_ 12y ago
I believe that browser vendors will push technology that benefits them. That's definitely not in dispute. But you need to convince them that HTTP/2.0 is beneficial to them, and I don't think that will be easy if content providers aren't serving content via HTTP/2.0.
- tracker1 12y ago
  Most of the enhancements I'm aware of HTTP/2 are centered around SPDY.. along with persistent connections. The upconvert for SPDY and WebSocket connections are interesting on HTTP/1.0, I kind of wish that this had worked hand in hand with DNS to allow for DNSSEC publishing of public encryption keys for use with HTTP, then HTTP negotiating against that key. I also wish there were layer between full encryption for content that is intended to be available for http and https (without the extra overhead) for signed content.
  - ibotty 12y ago
    What you want re public keys in dnssec secured DNS is called Dane. Browsers are slow to implement it though.
pfraze 12y ago
if you need to have a stateful connection, why not just use websockets? in many other cases (eg asset fetching) http/http2 are fine

imajes 12y ago

Re the environmental impact: A large contingent of internet networked servers are webservers, transacting with the HTTP protocol (be it spiders or producers or whatever). If it takes more computing resources to provide HTTP/2.0, then it would in fact require more servers, and thus increase the energy consumption. But given how large datacenter consumers are considering how to build greener/smarter operations to reduce their impact (and costs) then clearly it's something to be mindful of.