11–20 of 50 posts
Earlier quoted context omitted.
What is the alternative to cookies? What does he mean by session/identity facility?
There's some discussion in this thread: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/... in short, the need for a Session header to replace the use of Cookies for basic session management
Earlier quoted context omitted.
There's some discussion in this thread: http://lists.w3.org/Archives/Public/ietf-http-wg/2012JulSep/... in short, the need for a Session header to replace the use of Cookies for basic session management
So is that just cookies by another name?
In my view, HTTP/2.0 should kill Cookies as a concept, and replace it with a session/identity facility, which makes it easier to do things right with HTTP/2.0 than with HTTP/1.1. count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.
In my view, HTTP/2.0 should kill Cookies as a concept, and replace it with a session/identity facility, which makes it easier to do things right with HTTP/2.0 than with HTTP/1.1. count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.
Basically, I can guarantee that killing cookies would lead to 0% adoption of HTTP 2.0 forever, due to the same inertia that is holding Python 3 or IPv6 back. Doesn't matter if there's a better mechanism included that does the same job.
Earlier quoted context omitted.
> Cookies are...freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies. Seems like the blame for that lies not with cookies themselves, but with the EU's cookie law.
Oh yes, the regulation was rushed in by people not really sure what to do or what was happening. Why it couldn't be a browser option, I have no idea.
Earlier quoted context omitted.
So is that just cookies by another name?
Cookies with an expire of session and secure flag set: yes. But this should be more secure, and stored for 1 session implicitly.
In my view, HTTP/2.0 should kill Cookies as a concept, and replace it with a session/identity facility, which makes it easier to do things right with HTTP/2.0 than with HTTP/1.1. count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.
> Cookies are...freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies. Seems like the blame for that lies not with cookies themselves, but with the EU's cookie law.
Cookies are for session management; the central problem with cookies is that people feel that servers will treat certain sessions as ephemeral, but instead those servers track these people for a long-term creepy analysis. One connected problem is that many sites require cookies in order to show public content. Public-content sessions should be entirely ephemeral, meaning that you shouldn't need a cookie in the first place. (The New York Times offends in this regard egregiously and persistently.)
You can easily comply with the EU law by either placing the notice on the login page or else not storing cookies. This means that anybody who abuses cookies in the above way needs to be loud about it; "we're not giving you an ephemeral presence like you think!" -- which actually not only fixes this problem but also creates an incentive to not abuse cookies in this way.
I am not saying that we should abandon sessions entirely, but that it would be nice if the 'default' session treatment followed the rules that online banking uses: when the browser is closed, all sessions are done. If we did this then we'd want to include a 'persistent login' mechanism, which would take the form of an in-browser 'would you like to sign in?' dialogue accompanying a web site. This means that unlike current HTTP authentication, it would have to be somewhat asynchronous; you are shown the ephemeral version of the page while the browser itself requests you to confirm that you want to join your long-term session there. (I was originally going to recommend that the browser just handle a digital signature scheme, but of course that does not solve the 'logging on to Facebook from your sister's computer' problem easily. Hm.)
In my view, HTTP/2.0 should kill Cookies as a concept, and replace it with a session/identity facility, which makes it easier to do things right with HTTP/2.0 than with HTTP/1.1. count me in. Cookies are a huge waste of bandwidth and freaking annoying here in Europe as you cannot visit a site anymore without being warned you are about to receive yet even more cookies.
Basically, I can guarantee that killing cookies would lead to 0% adoption of HTTP 2.0 forever, due to the same inertia that is holding Python 3 or IPv6 back. Doesn't matter if there's a better mechanism included that does the same job.
Cookies were originally and with few exceptions remain a hack to try to add state to transactions that were not intended to be stateful.
If indeed the header compression is driven by the growing prevalence and size of cookies, then HTTP/2 is an effort to accomodate a hack. Not very interesting.
Some hacks that find their way into RFC's are difficult to remove because the transition process would be unreasonably expensive, like replacing the "sophomoric" compression scheme in DNS with something more sensible like LZ77 (credit: djb). I guess we might see some passionate arguments by web developers about the great expense of removing cookies from the HTTP standard and replacing it with a session facility, but I think the (long term) benefits easily outweigh the (short term) costs.