4 ms·

I'm here in case you want to ask me anything. Poul-Henning

by phkamp 12y ago

acdha 12y ago
For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over. http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0833.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.
- phkamp 12y ago
  I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason. If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP. Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause. And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol. Nobody seems to have heard the expression "Festina Lente" in this WG.
  - throwaway7767 12y ago
    If I understand your argument correctly, you are opposed to oppurtunistic encryption as there is no identity validation, as it does not improve privacy. But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that? (I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)
    - phkamp 12y ago
      You read me wrong then. I'm opposed to a protocol which claims to "improve privacy" while leaving some of the most troubling privacy invasions in place. If we are going to the trouble to upgrade HTTP, we fix all the serious problems we can.
  - pierrebai 12y ago
    All these concerns share an overlook of the practicalities of the web. On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind. Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation. (The same argument hold to SCTP vs TCP.)
    - ubernostrum 12y ago
      * All these concerns share an overlook of the practicalities of the web.* There's nothing "practical" about HTTP/2.0. I've read the spec, since I was interested in it, and it confused the hell out of me. Then I learned that even people who implement networking specs for a living, and have tons of experience at it, are stuck trying to figure out how to implement the current spec. So if you're going to push for shitty-but-practical, at least make sure you have the practical bit.
    - phkamp 12y ago
      A well designed HTTP/2.0 would not "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mask the differences for the application code. For instance moving cookies to the server side would just require a simple key-value store lookup.
      - Sammi 12y ago
        Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask: Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead? Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?
  - Titanous 12y ago
    > Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. It absolutely does, global passive attackers have been documented using the associated unencrypted tracking cookies to find targets.
  - youngtaff 12y ago
    > If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Yes, they add request and response overhead but what evidence is there that removing them would deliver greater performance improvements than a multiplexed protocol does?
    - phkamp 12y ago
      Comparing to multiplexing is wrong. You should compare it to the header-compression ("HPACK") which is a major complication and risk in HTTP/2.0 The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms. Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them. Using information-free session nonces would have neither of these problems, and take up much less bandwidth.
      - youngtaff 12y ago
        I understand the issue of complexity in header compression but the impression I get is you seem to object to the whole basis of HTTP/2 seemingly because it's not ambitious enough. If it didn't have HPACK but still did multiplexing would you still say abandon it?
        phkamp 12y ago
        It's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.
      - dfabulich 12y ago
        > Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them. Can you spell this out in more detail? (Maybe you've written an article about this at some point?) When, if ever, is it OK to store state on the client? It seems like you'd at least make an exception for one session ID. I presume you'd also make exceptions for client-side caches? Anything else? Do you advocate against all forms of client-side storage? IndexedDB, localStorage, Web SQL, etc? RESTful advocates keep telling me not to store state on the server. Do you agree with that? If I can't store state on the server and I can't store it on the client, where am I supposed to store it?
gerardvanvooren 12y ago
What do you think about the http/0.2 proposal? http://http02.cat-v.org/ http://http02.cat-v.org/ Of course we don't live in Plan-9's 9P world, and I don't think we will ever live in that world, but if you think about it, it makes a lot more sense. In every aspect. 9P could make lots of troubled / tied (think XML standard such as WebDAV) / historical standards (FTP, NFS) obsolete. It is sane, simple, fast and secure because it is just a stream of bytes, displayed as a filesystem. There is no need for tons of librarycode. And http/0.2 could be backwards compatible. With http/0.2 you could also have session id. Besides that, with mounting httpfs there is no absolute need for a browser. You could use the standard commandline tools, altough the browser is gonna be used in almost any case. All I wanna say is that I agree with your ideas. HTTP/2 is probably gonna have a long breath, so thinking it over, and start from scratch would be a good idea IMO. With 9P it could be a real dealmaker.

I'm here in case you want to ask me anything. Poul-Henning

by phkamp 12y ago

I'm here in case you want to ask me anything. Poul-Henning

acdha 12y ago

For those of us who don't follow this discussion in detail, why are you thinking the protocol needs to be scrapped outright rather than modified? Is it simply the complexity Greg Wilkins mentioned or are you really thinking about bigger philosophical changes like dropping cookies as we know them? Dropping HPACK seems like a great engineering call but that seems like a relatively minor change rather than starting over. http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/0833.html http://lists.w3.org/Archives/Public/ietf-http-wg/2014AprJun/... made me wonder what your standby plan would be – let the people who really need to care about performance use SPDY until a more ambitious HTTP 2.0 stabilizes? One of the concerns I have is that many people want performance now and it seems like HTTP 2.0 might turn into the next XHTML if it takes too long to emerge.

phkamp 12y ago
I think the fundamental problem with HTTP/2.0 is that it is a inadequate rush job for no good reason. If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. But the entire focus has been to rush out a gold-plated version of SPDY, rather than to actually solve these "deep" problems in HTTP. Similarly: Rather than accept that getting firewalls fixed will take a bit of time, everything gets tunneled through port 80/443, with all the interop trouble that will cause. And instead working with the SCTP people on getting a better transport protocol than TCP ? Stick it all into the HTTP protocol. Nobody seems to have heard the expression "Festina Lente" in this WG.
- throwaway7767 12y ago
  If I understand your argument correctly, you are opposed to oppurtunistic encryption as there is no identity validation, as it does not improve privacy. But an active man-in-the-middle attack at least has a chance of being detected, as opposed to the current passive sniffing being done on a wholesale basis. Do you not see any value in that? (I have not followed the HTTP/2 development closely enough to comment on other areas of concern.)
  - phkamp 12y ago
    You read me wrong then. I'm opposed to a protocol which claims to "improve privacy" while leaving some of the most troubling privacy invasions in place. If we are going to the trouble to upgrade HTTP, we fix all the serious problems we can.
- pierrebai 12y ago
  All these concerns share an overlook of the practicalities of the web. On the protocol level, there is a huge knowledge and API momentum that makes any protocol that fundamentally differs from HTTP an uphill battle for adoption. Whatever changes are made to HTTP, if it is too different from the application POV, it will linger behind. Same thing about tunneling. It may not be elegant, but it's the way to fight the system. You won't change IT behaviour with a protocol change. One possible way to work would be to make new version oF HTTP have a working mode that reduces overhead to a minimum for any tunneling operation. (The same argument hold to SCTP vs TCP.)
  - ubernostrum 12y ago
    * All these concerns share an overlook of the practicalities of the web.* There's nothing "practical" about HTTP/2.0. I've read the spec, since I was interested in it, and it confused the hell out of me. Then I learned that even people who implement networking specs for a living, and have tons of experience at it, are stuck trying to figure out how to implement the current spec. So if you're going to push for shitty-but-practical, at least make sure you have the practical bit.
  - phkamp 12y ago
    A well designed HTTP/2.0 would not "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mask the differences for the application code. For instance moving cookies to the server side would just require a simple key-value store lookup.
    - Sammi 12y ago
      Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask: Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead? Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?
- Titanous 12y ago
  > Likewise, wrapping all the small blue 'f' icons and their associated tracking icons in TLS/SSL does not improve privacy on the net in any meaningful way. It absolutely does, global passive attackers have been documented using the associated unencrypted tracking cookies to find targets.
- youngtaff 12y ago
  > If you really want to gain performance for instance, the way to go is to get rid of the enormous overhead of cookies, to replace the verbose but almost content-free User-Agent header and so on. Yes, they add request and response overhead but what evidence is there that removing them would deliver greater performance improvements than a multiplexed protocol does?
  - phkamp 12y ago
    Comparing to multiplexing is wrong. You should compare it to the header-compression ("HPACK") which is a major complication and risk in HTTP/2.0 The answer is that well-designed cookies are incompressible because they come out of cryptographic algorithms. Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them. Using information-free session nonces would have neither of these problems, and take up much less bandwidth.
    - youngtaff 12y ago
      I understand the issue of complexity in header compression but the impression I get is you seem to object to the whole basis of HTTP/2 seemingly because it's not ambitious enough. If it didn't have HPACK but still did multiplexing would you still say abandon it?
      - phkamp 12y ago
        It's a tradeoff: The added complexity must provide sufficient benefit to be worth it. HTTP/2.0 doesn't IMO, not even close.
    - dfabulich 12y ago
      > Also, cookies are wrong, because they store the servers state on the client computer, which led the EU to legislate against them. Can you spell this out in more detail? (Maybe you've written an article about this at some point?) When, if ever, is it OK to store state on the client? It seems like you'd at least make an exception for one session ID. I presume you'd also make exceptions for client-side caches? Anything else? Do you advocate against all forms of client-side storage? IndexedDB, localStorage, Web SQL, etc? RESTful advocates keep telling me not to store state on the server. Do you agree with that? If I can't store state on the server and I can't store it on the client, where am I supposed to store it?

gerardvanvooren 12y ago

What do you think about the http/0.2 proposal? http://http02.cat-v.org/ http://http02.cat-v.org/ Of course we don't live in Plan-9's 9P world, and I don't think we will ever live in that world, but if you think about it, it makes a lot more sense. In every aspect. 9P could make lots of troubled / tied (think XML standard such as WebDAV) / historical standards (FTP, NFS) obsolete. It is sane, simple, fast and secure because it is just a stream of bytes, displayed as a filesystem. There is no need for tons of librarycode. And http/0.2 could be backwards compatible. With http/0.2 you could also have session id. Besides that, with mounting httpfs there is no absolute need for a browser. You could use the standard commandline tools, altough the browser is gonna be used in almost any case. All I wanna say is that I agree with your ideas. HTTP/2 is probably gonna have a long breath, so thinking it over, and start from scratch would be a good idea IMO. With 9P it could be a real dealmaker.