Varnish author criticizing HTTP/2.0 proposals • Hacker News Board

Re: Varnish author criticizing HTTP/2.0 proposals

#101

Post by ay » Tue, Jul 17, 2012, 1:59 PM UTC

phkamp wrote: post #92

moe wrote: post #91

I have a lot of respect for phkamp, varnish is an impressive piece of engineering. I disagree with the stab he takes at cookie-sessions here, though. He seems to ignore that sessions are not only about identity but also about state. Servers should be stateless, therefor client-sessions (crypt+signed) are usually preferable over server-sessions. Having a few more bytes of cookie-payload is normally an order of magnitu…

No, servers should hold _all the state_ and clients none. If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser, rather than have two shopping baskets. Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it: Its wrong from a privacy point of view, it's wrong from a cost-allocation point of view, it's wron…

I too want to add the first item into the shopping basket from the laptop and the second from my tablet.

But this does not imply that the clients should store no state - it only implies that the state as perceived by the users needs to be the same. Different from how it is implemented.

While we are at the topic of state, why do I have to subscribe to a service just to be able to add the bookmark on one device and use it on the other ?

I view the two problems as congruent (except the bookmarks state is global, thus there is no "server" to offload the state onto) - but at the same time this difference highlights the assumption that there is "The Server" for the web app. What if there weren't ? Can we push the model a bit further and make it p2p - and I am pretty sure that as the homomorphic crypto advances, we will be able to do so even for the untrusted peers. Then there's no "server" anymore to store the state in.

Then, you have the DoS bit. Absolutely correctly the HTTP routers are the most loaded and hard to scale element of the whole setup. If you offload the state on the client, then you can "dumb down" the task of the non-initial content switching decision, based on the trustable client state.

So, I think that distributing the state is a good idea. What is limiting is the naive distributing the state - and this is where I agree with your assessment. And that's probably one of the things that would need to get fixed for something that would is big enough to be called "2.0". (As a by-product, solving the above would also solve the endpoint identity/address change survivability problem).

Re: Varnish author criticizing HTTP/2.0 proposals

#102

Post by DougWebb » Tue, Jul 17, 2012, 2:00 PM UTC

hollerith wrote: post #94

patrickaljord wrote: post #5

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

>telnet and gopher were used by a few thousands servers only and were not consumer facing technologies The card catalogs at most university libraries and most libraries of any national or international importance were reachable by telnet in 1992. And I think card catalogs count as a "consumer-facing" service. The vast majority of internet client software in 1992 was text only. The first exception to this that I am aw…

IRC was pretty widely used back in the day too, and it was and still is text-only. There have been a number of non-text replacements for IRC (SecondLife being the most successful) but most died off. IRC's grandchildren, Twitter, SMS, all of the instant messaging and chat services, are all still text-only or close too it.

Re: Varnish author criticizing HTTP/2.0 proposals

#103

Post by phkamp » Tue, Jul 17, 2012, 2:02 PM UTC

papsosouid wrote: post #100

phkamp wrote: post #92

Earlier quoted context omitted.

No, servers should hold _all the state_ and clients none. If I add something to my shopping basket from my mobile phone, I want to be able to add more from my browser, rather than have two shopping baskets. Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it: Its wrong from a privacy point of view, it's wrong from a cost-allocation point of view, it's wron…

>Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it Not that it is surprising given the source, but this "my opinion is objectively correct" nonsense isn't constructive. Client side sessions give you stateless servers, which allows real seamless fail-over. Having to run a HA session-storage service to get that is a big additional cost. "PHK said it is rig…

They are not wrong because I say so, they are wrong because they are wrong.

When it gets to the point where EU regulates something, the way they did with cookies, it should be painfully obvious to even the most casual observer, that there is something horribly wrong with it.

As for the cost of your HA session-storage ? Cry me a river! You're the one making the money, you're the one who should carry the cost.

Re: Varnish author criticizing HTTP/2.0 proposals

#104

Post by ay » Tue, Jul 17, 2012, 2:04 PM UTC

phkamp wrote: post #96

duckharp wrote: post #95

Earlier quoted context omitted.

But what about preferences for anonymous users? Store that on the server side? Append them to the URL? Both options kinda suck. Also, consider dabblet. The way it allows you to store your stuff using github is very smart IMHO.

Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.

User-agent, and other bits of stuff that is duly noted by http://panopticlick.eff.org/ are much-much-much worse than cookies. Cookies you can erase. User-agent and other "fingerprints" are with you forever. And they travel with you no matter where you are.

So, while you would dismiss the "privacy hazard" that the cookies are, you replace it with something much worse.

Re: Varnish author criticizing HTTP/2.0 proposals

#105

Post by phkamp » Tue, Jul 17, 2012, 2:04 PM UTC

duckharp wrote: post #98

phkamp wrote: post #96

Earlier quoted context omitted.

Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.

Store the settings of anyone who ever connected? For how long? Forever, just in case? Silly. And why do you even assume the server has to have a database? Why should it be required to have one, why should it have to store the stuff? What is your take on statelessness? you concentrate so much on the abuses of cookies and client side storage/computation, but you're not addressing the advantages. I doubt you're aware of…

Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ?

Putting the cost of storage where the decision to store is made is sound economic practics.

Re: Varnish author criticizing HTTP/2.0 proposals

#106

Post by ay » Tue, Jul 17, 2012, 2:22 PM UTC

angelbob wrote: post #53

danellis wrote: post #43

Earlier quoted context omitted.

I don't know what you mean by 'leakable' exactly, but you can already mark cookies as HttpOnly (not accessible from Javascript) and Secure (only transmitted over HTTPS).

"Leakable" in the sense that you can hand it to somebody else and they can actually use it. A cookie is leakable because the client chooses to send it, so copying it to somebody else is really bad. A server-assigned per-connection ID is not leakable unless you can spoof the IP address of the one you're sending as.

Then a translation device at carrier assigns the client a different address. I heard first-hand that this is very annoying.

Re: Varnish author criticizing HTTP/2.0 proposals

#107

Post by paulsutter » Tue, Jul 17, 2012, 2:29 PM UTC

rickmb wrote: post #61

After the whole IPv6 story, I'm surprised the author ignores the political dimension of designing a new protocol. As Mitch Kapor said "Architecture is Politics". It's not just about what solution is best from a technological perspective, it's about what we want our future to look like. The internet has become way more important than back when these protocols first became standard, and every time a protocol or standar…

Moreover, the author seems to completely miss the point that SPDY was designed to overcome wide area networking performance issues with the way http uses tcp. Which it does quite well for substantial latency improvements.

He throws out a lot of criticism about SPDY being haphazardly designed (with no explanation), then we find out that really he has an axe to grind over cookies and SSL.

I call bullshit on the whole post. I found nothing useful in it. I almost fell for the http router bit, but again he offers no more than vague criticisms. If SPDY hasn't been a problem at Google and Facebook for load balancers, SPDY isn't badly designed for load balancer implementation. It leads me to believe that his real issue is that Varnish must have been coded in such a way to make it hard to support SPDY. Or perhaps that the authors real beef with SPDY is that he didn't design it.

Re: Varnish author criticizing HTTP/2.0 proposals

#108

Post by papsosouid » Tue, Jul 17, 2012, 2:31 PM UTC

phkamp wrote: post #103

papsosouid wrote: post #100

Earlier quoted context omitted.

>Servers storing stuff on the clients is just plain wrong, and it is wrong from every single angle you can view it Not that it is surprising given the source, but this "my opinion is objectively correct" nonsense isn't constructive. Client side sessions give you stateless servers, which allows real seamless fail-over. Having to run a HA session-storage service to get that is a big additional cost. "PHK said it is rig…

They are not wrong because I say so, they are wrong because they are wrong. When it gets to the point where EU regulates something, the way they did with cookies, it should be painfully obvious to even the most casual observer, that there is something horribly wrong with it. As for the cost of your HA session-storage ? Cry me a river! You're the one making the money, you're the one who should carry the cost.

"Cry me a river" is no more compelling than "I am right because I say so". I am making money? I didn't realize my free site that I pay hosting expenses for out of my pocket was making me money. When can I expect my check?

You haven't offered any reason why anyone would want to move from client side sessions to server side sessions. If you want to affect change, you need to provide reason for change, not just condescending nonsense.

Re: Varnish author criticizing HTTP/2.0 proposals

#109

Post by papsosouid » Tue, Jul 17, 2012, 2:35 PM UTC

phkamp wrote: post #105

duckharp wrote: post #98

Earlier quoted context omitted.

Store the settings of anyone who ever connected? For how long? Forever, just in case? Silly. And why do you even assume the server has to have a database? Why should it be required to have one, why should it have to store the stuff? What is your take on statelessness? you concentrate so much on the abuses of cookies and client side storage/computation, but you're not addressing the advantages. I doubt you're aware of…

Uhm, isn't that how it works today ? Do you care about how many metric shitloads of storage your cookies take up on client's disks ? Shouldn't you ? Putting the cost of storage where the decision to store is made is sound economic practics.

It is the user's session data. If it is stored on their end, they can choose how long they wish to store it for, and delete it any time they like.

Re: Varnish author criticizing HTTP/2.0 proposals

#110

Post by sophacles » Tue, Jul 17, 2012, 2:42 PM UTC

ay wrote: post #104

phkamp wrote: post #96

Earlier quoted context omitted.

Store it on the server: The user-agent gives you a session-id to use as key. It may be that session-keys should tell if they are anonymous or if they represent (locally) authenticated users, but that's a very complex subject I won't claim to have a clear opinion of yet.

User-agent, and other bits of stuff that is duly noted by http://panopticlick.eff.org/ are much-much-much worse than cookies. Cookies you can erase. User-agent and other "fingerprints" are with you forever. And they travel with you no matter where you are. So, while you would dismiss the "privacy hazard" that the cookies are, you replace it with something much worse.

You can still have the cookie concept, and have the session id be a random number each time someone sends a tab to the site. The cookie can hold those preferences, and the session id can be used for session stuff. As a bonus, you can then only load the cookie on the first page load, and keep the values in cache associated with the browser random session number, saving in data transfer issues, and losing nothing. And for those that don't need cookies, they get a big win in terms of privacy.