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

111–120 of 138 posts

Re: Varnish author criticizing HTTP/2.0 proposals

#111

Post by jerf »

phkamp wrote: post #44
rdsubhas wrote: post #39

(These are just my opinions as web developer. Please feel free to downvote if my expectations are wrong) While I can completely agree with the technical merits of this proposal, there are some very two-faced statements. Author begins by pointing out the painfulness of IPv4 to IPv6, says that the next HTTP upgrade should be humble . But then proceeds to kill cookies and remove all the architectural problems in HTTP. I…

No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs). One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business. If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business wo…

"Ipv6 is Ipv4 with bigger addresses,"

Yeah, I used to think that, then I participated in some IPv6 conversions and watched some others. I don't think that any more. IPv6 may not be the Glorious Solution to All Network Problems Ever, but it's not just the obvious incremental improvement on IPv4 either. It's a new protocol.

(I do sometimes wonder if an IPv4.1 that simply set a flag and used 8 bytes instead of 4 was proposed right now if it could still beat IPv6 out to the field even with IPv6's head start. Note, I'm not saying this would necessarily be a good idea, I just find myself wondering if IPv4.1 could still hypothetically beat IPv6 to deployment.)

Re: Varnish author criticizing HTTP/2.0 proposals

#112

Post by ryanpetrich »

comex wrote: post #77
phkamp wrote: post #70

Earlier quoted context omitted.

You do know that when IPv6 roll-out was initially contemplated, it would happen on IPv4-convertible addresses only, until everybody had converted. That would have allowed seamless IPv6/IPv4 interop and made migration a breeze. Lacking any "must have" features, nobody could see a reason to bother. Now we have to do the migration without the benefit of seamless conversion.

Luckily, HTTP only requires the browser (which tend to be frequently updated) and server to be upgraded, not some random aging routers, there is little reason to fear adoption, there is minimal harm in keeping both protocols around for some time, and there is something much closer to a "must have" feature - speed.

A lot of hardware (proxies, DPI gear, hotel wifi hotspots, cellular carriers, etc) sniffs/mangles HTTP in transit and must be verified to be compatible with new HTTP features. HTTPS doesn't have this constraint.

Re: Varnish author criticizing HTTP/2.0 proposals

#113

Post by sophacles »

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…

So how does having a protocol standard state value, lets say a uuid, rather than a cookie with a bunch of keys, one of which is a uuid, change things? Well first, we can now disassociate valuable private data from a session identifier. Second, we can now have the http routers point session ids to specific servers, allowing a level of "on box" caching per app server, allowing faster lookups without needing to hit memcache-type things, just poll the local state cache first.

Re: Varnish author criticizing HTTP/2.0 proposals

#114

Post by sophacles »

One huge benefit I think people are missing about the notion of a protocol standard session mechanism, is that we can use HTTP auth much easier, and perhaps get away from this notion of every site having to redo the login process. Browsers can handle the "remember login" settings, and logging out is as simple as tab closing. No "remember this computer" or "don't remember this computer" checkbox confusion. No random sites saying "remember me always" and requiring manual logout on a borrowed computer. It certainly helps with the password wallet concept too.

Sure all that stuff has become semi-standard as it currently exists, but it is ugly, hacky, and sometimes doesn't work, and other times opens doors for hilarious malfeasance.

Re: Varnish author criticizing HTTP/2.0 proposals

#115

Post by ay »

sophacles wrote: post #110
ay wrote: post #104

Earlier quoted context omitted.

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…

ok, so I grpk the idea correctly it is something like "send the cookie-like-data from the client only on the first GET, if you are doing it over HTTP/1.1 single TCP connection" - that sense (and could be easily made into an extension to HTTP/1.1 - [though it creates the dependency between the different GET requests] - have the server will just send "X-Dont-Send-Me-More-Cookies-in-this-TCP: yes!" header from the server, and make the compliant clients react to it).

What I do not understand where's the win on the privacy front here. You send the random ids - but the site owner will re-correlate these random IDs with your identity. So, you would not win anything here - or, what am I missing ?

My take on the privacy:

There is no problem with someone collecting a bunch of info about me and using it to improve their services.

There is a little bit of a problem with someone collecting a bunch of info about me and another million people and keeping that in a big blob.

There is a big problem when that someone gets hacked and this bunch of info about another million people gets to the bad kids.

It's the centralization of a lot of data that is bad for the privacy.

Store the data locally on the clients and give it to the server only when it is contextually needed. e.g.: my shipping address, I am happy for my browser to supply it to you from my local storage to you every time you want to ship me something. I am very happy if you do not store and sell this address to someone who will later send snail-mail spam to me. Or store without the due diligence ('cos time to market and all that) and then get hacked and then I find myself "having paid" for the helicopter spare parts.

Of course, this would hurt the nouveau business models that treat the users as a product. And will make the analytics harder - because one would not be able to just run a select... But to me it could be a useful tradeoff.

(above, I use the term "client" to refer to the collective set of the devices that are "mine". As I wrote in another reply, storing the state on client does not imply the difference in the user-seen behavior, so the shopping cart should survive).

Re: Varnish author criticizing HTTP/2.0 proposals

#116

Post by cbr »

pilif wrote: post #34

While in general I understand where he is coming from, I believe his main argument about adoption is flawed. What do you think is more likely going to be adopted? A protocol that's not backwards compatible at all (heck, it even throws out cookies) or something that works over the existing protocol, negotiating extended support and then switching to that while continuing to work the exact same way for both old clients…

> SNI issues aside

What SNI issues? In practice any client that supports SPDY is going to support SNI.

Re: Varnish author criticizing HTTP/2.0 proposals

#117

Post by hollerith »

DougWebb wrote: post #102
hollerith wrote: post #94

Earlier quoted context omitted.

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

OK, but I feel the need to stress that when I wrote "text only", I was referring to the user interfaces.

(And the reason user interfaces are relevant here is that telnet was the main way to export user interfaces over the internet in 1992.)

Re: Varnish author criticizing HTTP/2.0 proposals

#118

Post by cbr »

phkamp wrote: post #35
comex wrote: 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…

I agree that anybody with sufficient clue can and will use cookies as id only. Unfortunately such people are evidently few and far between. Banning cookies and having the client offer a session identifier instead solves many problems. For starters, it stores the data where it belongs: On the server, putting the cost of storage and protection where it belongs too. This is a win for privacy, as you will know if you hav…

An identifier has privacy disadvantages over a cookie with the same duration. The least privacy you have is when the server has a unique identifier for you: then they can do whatever they want. With a cookie the site has an option to store only what they need, instead of something unique. For example if I'm running an a/b test I could do this with a cookie, setting it to "1" for half the users and "2" for the other half.

(I work on mod_pagespeed, and our experimental framework uses cookies this way: https://developers.google.com/speed/docs/mod_pagespeed/modul...)

Re: Varnish author criticizing HTTP/2.0 proposals

#119

Post by romaniv »

jerf wrote: post #111
phkamp wrote: post #44

Earlier quoted context omitted.

No. Ipv6 is Ipv4 with bigger addresses, it didn't try to solve any of the other problems of IPv4 (or attempts to solve them were killed by ISPs). One example was multihoming (having more than one ISP) serveral smart proposals were floated (anycast, nearcast etc) but they were killed by ISP's who protected a lucrative business. If Ipv6 had made multi-ISP multihoming possible without all the trouble of BGP, business wo…

"Ipv6 is Ipv4 with bigger addresses," Yeah, I used to think that, then I participated in some IPv6 conversions and watched some others. I don't think that any more. IPv6 may not be the Glorious Solution to All Network Problems Ever, but it's not just the obvious incremental improvement on IPv4 either. It's a new protocol. (I do sometimes wonder if an IPv4.1 that simply set a flag and used 8 bytes instead of 4 was pro…

What practical problems, aside from address range exhaustion, does it solve? I've read some technical articles about benefits of IPv6, but most of them keep returning to address size problem.

Re: Varnish author criticizing HTTP/2.0 proposals

#120

Post by romaniv »

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…

Although I fully agree with the author's critique of cookies for instance, the idea of replacing them with something "better" frankly scares the crap out of me. Especially when the word "identity" is being used.

Ever heard of evercookie? Does that not scare you? Would creating a clean, well-understood solutions that users can actually control not be better than what we have now?

There is just so much wrong with cookies, it's really surprising that no HTTP upgrades propose anything better. For one, cookies confuse session information and client-side storage, and thus work poorly in both roles.

Post reply on HN