Live data from Hacker News

Varnish author criticizing HTTP/2.0 proposals

lists.w3.org

21–30 of 138 posts

Re: Varnish author criticizing HTTP/2.0 proposals

#21
post #17

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.

so your "solution" for cookies, is to mandate that all web apps must use ajax, and pass session IDs as part of the URL for all requests?

Re: Varnish author criticizing HTTP/2.0 proposals

#22
post #8

Earlier 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.…

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.

Re: Varnish author criticizing HTTP/2.0 proposals

#23
post #8

Earlier 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.…

> 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 better methods for managing them (or just disabling them).

Re: Varnish author criticizing HTTP/2.0 proposals

#24
post #3

Removing 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…

HTTP/2.0 doesn't have to be backwards compatible at all. In fact, I see the future protocol switch being pretty simple. There will be new HTTP/2.0 servers and HTTP/1.1 legacy servers. The clients will speak either language, but 2.0 servers will be faster. Eventually clients will let the user say if they want to talk to 1.1 servers at all.

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

#25
post #22
post #8

Earlier 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.

It's easy to work around this in a backwards compatible way, though, in a way that's applicable to more than just cookies - in requests after the first, only re-send headers that have changed.

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

#26
post #23
post #8

Earlier 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…

Eh... maybe eventually, once nothing uses cookies anymore (including existing HTTP sites). But surely this can be solved today by having browsers force cookies to expire with the session?

Re: Varnish author criticizing HTTP/2.0 proposals

#27
post #12

load 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…

I don't see the issue with doing away with cookies. Cookies sucks for so many reasons. A natively handled session is just fine. Oh yes, it means also you can't be easily tracked, because that's the other purpose of cookies. Well too bad. You can still track through other means.

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

#28

Earlier 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.

If you don't store a leakable cookie on the client and only use a connection ID (which is autoassigned by the server and cannot be easily forged) then a lot of cross-domain evil hackery goes away.

Re: Varnish author criticizing HTTP/2.0 proposals

#29
post #2

His 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…

Maybe he's trying to bring light to Unhosted?

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.

The factors that caused slow IP4 to IP6 transition are cited as examples by the author you are criticizing. It's very clear they are aware of the scale of http deployment as well as the challenges that brings. In fact, that key point motivates most of their objections to the current standards proposals.
Post reply on HN