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.
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.)
Like the author said:
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 and
incompetences, EU felt compelled to legislate a "notice
and announce" policy for HTTP-cookies.Why it couldn't be a browser option, I have no idea.
in short,
the need for a Session header to replace the use of Cookies
for basic session managementThe recent why SPDY is succeeding is because it is not trying to solve every problem and grind every axe.
> One simple way to gain a lot of benefit for little cost in this area, would be to assign "flow-labels" which each are restricted to one particular Host: header, allowing HTTP routers to only examine the first request on each flow.
I don't understand what he's saying here. Who assigns a label to the "Host" header when? Is he proposing sticky cookies?
http was nice because it was easy for software programmers to write apps that could work over http, because no binary protocol was involved: reading ASCII strings is never complicated. It was good for a growing industry.
Now most browsers are open source, why can't the IETF work out a binary protocol ? Bittorrent is binary, and it's awesome and it's used. Why can't any browser work out a binary protocol ? Truly dynamic pages over the network ? Why not ? I'm sure some software already does that. Make one open source, make it work on firefox or chrome, I guess things would start to light up.
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.
s: http/2.0 {SERVER INFO}
c: connect host/ <-- no path
s: OK {server-cert/key}
-- all futher requests encrypted against public key/cert
c: session-start {client key/cert}
s: SESSION: {session id} ({domain1},{domain2},...)
c: (COMMAND|get|put|post|delete) {PATH}
s: OK
or
DENIED ### (reason) <-- response code & reason
or
REDIRECT host/(path) <-- if the file is physically on another backend
c: {OTHER REQUEST HEADERS START}
s: http/2.0 {SERVER INFO}
c: connect host/{path}
s: OK {server-cert/key} or DENIED ### Reason
-- all futher requests encrypted against public key/cert
c: session-join {SESSION_ID} {client key/cert}
s: OK or DENIED...
c: {COMMAND} {path}