Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Varnish author criticizing HTTP/2.0 proposals

lists.w3.org

Post reply on HN
Print view View original

91–100 of 138 posts

Re: Varnish author criticizing HTTP/2.0 proposals

#91

Post by moe »

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 magnitude cheaper (in terms of latency) than performing the respective lookups server-side for every request. Very low bandwidth links might disagree, but that's a corner-case and with cookies we always have the choice.

Removing cookies in favor of a "client-id" would effectively remove the session-pattern that has proven optimal for the vast majority of websites.

Re: Varnish author criticizing HTTP/2.0 proposals

#92

Post by phkamp »

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 wrong from an architecture point of view and it's wrong from a protocol point of view.

But it was a quick hack to add to HTTP in a hurry back in the dotcom days.

It must die now.

Re: Varnish author criticizing HTTP/2.0 proposals

#93

Post by mcbridematt »

obtu wrote: post #68
bifrost wrote: post #40

Frankly many problems addressed by these proposals are not things that should be solved in a protocol like HTTP. Do you want every HTTP request to be slowed down with a crypto token exchange and verification? unlikely. In special cases you definately want it, but all the time? Absolutely not.

It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.

What about embedded devices/the 'internet of things'? Should I have to add a (costly) crypto chip to my microcontroller just to have a HTTP/web interface? Or a large SSL stack?

(HTTP 1 would be sufficient for these use cases for a long time to come, but resource considerations should factor into these standards discussions)

Re: Varnish author criticizing HTTP/2.0 proposals

#94

Post by hollerith »

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 aware of is the WWW, which most internet users had not started to use by the end of 1992 (email, newsgroups and ftp being the most widely used services). The way most connected to the internet or an intranet from home was by sending vt100 or similar protocol over a dial-up link -- with a Unix shell account or VMS account at the other end of the link. Repeating myself for emphasis: in 1992 most people accessing the internet from home or from a small office used a modem and IP packets did not pass over that modem link. The point of this long paragraph is that the vast majority of the machines on which these shell accounts ran were also reachable by telnet.

Finally, the telnet protocol in 1992 was a "general-purpose adapter" similar to how HTTP is one today. For example, the first web page I ever visited I visited through a telnet-HTTP gateway so that I could get a taste of the new WWW thing without having to install a WWW browser. Note that this telnet-HTTP gateway is another example of a "consumer-facing" telnet server.

In summary, there were probably more than a few thousand telnet servers in 1992 -- and many of them were "consumer-facing".

I am almost certain there were a few million users (certainly so if we include college students who used it for a semester or so, then stopped) of the internet in 1992, and most of those users used telnet.

Re: Varnish author criticizing HTTP/2.0 proposals

#95

Post by duckharp »

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…

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.

Re: Varnish author criticizing HTTP/2.0 proposals

#96

Post by phkamp »

duckharp wrote: post #95
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…

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.

Re: Varnish author criticizing HTTP/2.0 proposals

#97

Post by obtu »

mcbridematt wrote: post #93
obtu wrote: post #68

Earlier quoted context omitted.

It may be counter-intuitive, but with the right cyphers, the crypto costs of SSL and SPDY are negligible.

What about embedded devices/the 'internet of things'? Should I have to add a (costly) crypto chip to my microcontroller just to have a HTTP/web interface? Or a large SSL stack? (HTTP 1 would be sufficient for these use cases for a long time to come, but resource considerations should factor into these standards discussions)

I would keep HTTP/1.1, as you suggest. SSL servers on cheap (sub-Raspberry Pi) embedded devices are a no-go for another reason: it is hard to keep the certificate unique and private. Embedded devices with smart cards might be workable.

Re: Varnish author criticizing HTTP/2.0 proposals

#98

Post by duckharp »

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.

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 them to be honest.

Re: Varnish author criticizing HTTP/2.0 proposals

#99

Post by DougWebb »

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…

Clients can't be completely stateless; at the very least they need to pass along a key to identify their server-side state. That's what cookies do now (among other things) and it sounded to me like that's what you were proposing for the session/identify facility. I agree with you on that point; a specific feature in the protocol would be better than the generic cookie feature, given the ways cookies have been abused.

What's your opinion on IndexedDB and other local storage mechanisms? I believe that single-page-apps are overused, but I do think that they have their niche and standards for storing data locally are valuable and necessary. In my own work I'd use that space as a cache rather than permanent storage, just like I'd use something like memcached on the server side to reduce database queries.

Re: Varnish author criticizing HTTP/2.0 proposals

#100

Post by papsosouid »

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…

>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 right" doesn't provide sufficient benefits to overcome that downside.

Post reply on HN