Earlier quoted context omitted.
It doesn't seem like the proposals are "fully" compatible with HTTP. Some of them are entirely different encodings. And I doubt people are thinking of carrying over comments in headers and line folding... What actually is the proposal to eliminate cookies? Just provide some fixed "identifier" type field?
I'd say the cookies situation could be solved by one-page apps. Because the software persists across page-views, it'll be able to maintain session using some other mechanism (localstorage, the lifetime of the tab, whatever). The user could then disable cookies and not be worried about tracking.
Varnish author criticizing HTTP/2.0 proposals
21–30 of 138 posts
Re: Varnish author criticizing HTTP/2.0 proposals
#22Earlier quoted context omitted.
Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both. Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal…
> Why must HTTP 2.x be backwards compatible with 1.x? Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk... > Cookies suck, from a technical Agreed, but.…
Re: Varnish author criticizing HTTP/2.0 proposals
#23Earlier quoted context omitted.
Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both. Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal…
> Why must HTTP 2.x be backwards compatible with 1.x? Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk... > Cookies suck, from a technical Agreed, but.…
One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users better methods for managing them (or just disabling them).
Re: Varnish author criticizing HTTP/2.0 proposals
#24Removing cookies from a protocol which is otherwise fully compatible with HTTP/1, in the sense of being able to be interposed as a proxy or substituted in the web server without breaking apps, is a terrible idea. > Cookies are, as the EU commision correctly noted, fundamentally flawed, because they store potentially sensitive information on whatever computer the user happens to use, and as a result of various abuses…
Why must HTTP 2.x be backwards compatible with 1.x? Should SSH have not been created because you can't talk to it with a telnet client? If a new protocol offers sufficient benefits, it would be worth having to make minor changes to apps to support both. Cookies suck, from a technical and regulatory-compliance standpoint. Plus, I'll finally stop having to clear my cookies every month or so just to log in to my PayPal…
The initial line will remain the same, except for the version:
GET /page HTTP/2.0
*** extra 2.0 headers/request ***
If the server speaks 2.0, it will just carry on. If it doesn't, the server will return a 505 and the client will resubmit the request: GET /page HTTP/2.0
505 HTTP Version Not Supported
GET /page HTTP/1.1
*** 1.1 headers / request ***
There is no reason the protocols must to be backwards compatible past the first line. Hell, 2.0 could even be binary after that first line. So, while they don't have to be compatible, they can still coexist.Re: Varnish author criticizing HTTP/2.0 proposals
#25Earlier quoted context omitted.
> Why must HTTP 2.x be backwards compatible with 1.x? Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk... > Cookies suck, from a technical Agreed, but.…
you probably know this, but cookies are sent with every damn request the client makes. So it's a tax, It may be a small % of total traffic, but most of the time, it's useless.
Or just live with the hit while sites migrate to the new mechanism; I'm fine with it being considered a legacy thing.
Re: Varnish author criticizing HTTP/2.0 proposals
#26Earlier quoted context omitted.
> Why must HTTP 2.x be backwards compatible with 1.x? Because the only benefit of removing cookies is a tiny bit of simplicity which could theoretically allow removing (a small amount of) code browsers will already have to keep around for probably at least a decade to support existing websites. If cookies are mostly unused by the time HTTP/3.x rolls around, we can talk... > Cookies suck, from a technical Agreed, but.…
> and regulatory-compliance standpoint One of the main reasons why people can't just turn off Cookies is because they are needed for session management. This makes it very difficult to just disable. If there was a dedicated session management method in HTTP/2.0 then that would remove a lot of the need for Cookies. Then they could be used for what they were intended (local persistent state). This would also give users…
Re: Varnish author criticizing HTTP/2.0 proposals
#27load balancers aren't meant to just be "HTTP routers". they can definitely be used as such for smaller applications and do a good job at it, but a real load balancer needs to be quite complex, being able to adapt to the underlying applications that make use of it. if your goal is to only route HTTP requests, then you're only solving the first step of an increasingly complicated field of computer science (namely, web…
If you wanna store stuff, there's HTML5. Cookies are really just tracking and session.
As for the router, what he says makes complete sense, but, if there is more to it, then, what are you thinking about? Personally I think the host header is the most important thing to parse, for, well, routing, termination, etc. I'm not certain what else is needed beyond that point.
Re: Varnish author criticizing HTTP/2.0 proposals
#28Earlier quoted context omitted.
If I'm interpreting that correctly, that could be a huge win for privacy
How so? A unique identifier is a unique identifier.
Re: Varnish author criticizing HTTP/2.0 proposals
#29His proposal is at http://phk.freebsd.dk/misc/draft-kamp-httpbis-http-20-archit... It comes with the caveats that "Please disregard any strangeness in the boilerplate, I may not thrown all the right spells at xml2rfc, and also note that I have subsequently changed my mind on certain subjects, most notably Cookies which should simply be exterminated from HTTP/2.0, and replaced with a stable session/identity concept wh…
Re: Varnish author criticizing HTTP/2.0 proposals
#30> See for instance how SSH replaced TELNET, REXEC, RSH, SUPDUP > Or I might add, how HTTP replaced GOPHER[3]. telnet and gopher were used by a few thousands servers only and were not consumer facing technologies (for the most part), it doesn't make sense to compare that to IPv4 and HTTP that are used by millions (billion?) of servers.