4 ms·

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." In fact there's no need for this to be tied i

"HTTP/2.0 could have done away with cookies, replacing them instead with a client controlled session identifier." In fact there's no need for this to be tied in with HTTP/2.0 at all. Alternate systems could be designed without regard to HTTP/1.x or HTTP/2.y, they just have to agree on some headers to use and when to set them. Making these kind of changes as part of a new version of HTTP would just be bloat on an already bloated spec, it is actually a good thing that the spec writers did not touch this!

deleted 12y ago
[deleted]
hrjet 12y ago
> there's no need for this to be tied in with HTTP/2.0 at all. Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.
robomc 12y ago
Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).
- organsnyder 12y ago
  I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.
- phkamp 12y ago
  It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
  - jchrisa 12y ago
    It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step? More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
  - a_dutch_guy 12y ago
    (Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).
  - robomc 12y ago
    Seems like anything a server could do via cookies, they could also do via your client-generated session id. Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id. If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.
codexon 12y ago
This is not equivalent to cookies. Cookies allow you to specify arbitrary data, not just a session ID, so you can set preferences without having to hit a database or even running a completely static page, using javascript to read the settings. Cookies as they are now already allow you to control persistence. You can edit or delete them however you wish.
- ricardobeat 12y ago
  Except that deleting/not allowing cookies will make most of the things we use everyday unusable. Including this website.

deleted 12y ago

[deleted]

hrjet 12y ago

> there's no need for this to be tied in with HTTP/2.0 at all. Not only that, tying cookies with HTTP/2.0 would be a layering violation! The cookie spec is a separate spec that uses HTTP headers, and the cookie spec also explicitly says that cookies can be entirely ignored by the user-agent.

robomc 12y ago

Anyone have a link where I can read about these 'client controlled session identifiers'? I can't picture an approach to web app sessions which isn't essentially equivalent to a cookie (in terms of privacy, and ability of the client to control persistence).

organsnyder 12y ago
I was in the middle of writing a response with a description of a client-provided UUID, with the scope and persistence specified by the client, but then I realized that I was basically describing a cookie. My version might have been better because it would more easily allow the user to control how the session ID is disseminated, but that would have been a feature of the HTTP client–not the protocol itself.
phkamp 12y ago
It's really very simple: Instead of all the servers dumping cookies on you, you send a session-id to them, for instance 127 random bits. In front of those you send a zero bit, if you are fine with the server tracking you, and you save the random number so you send the same one every time you talk to that server. This works just like a cookie. If you feel like you want a new session, you can pick a new number and send that instead, and the server will treat that as a new (or just different!) session. If instead you send a one bit in front of the 127 random bits, you tell the server that once you consider this "session" over, and that you do not want them to track you. Of course this can be abused, but not nearly as much as cookies are abused today. But it has the very important property, that all requests get a single fixed size field to replace all the cookies we drag across the net these days.
- jchrisa 12y ago
  It also forces the session to be tracked on the server. Many apps use cookies to keep the session in the browser. Maybe deprecating the document.cookie API so that people move to local storage, is a good first step? More critique of cookies: https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
- a_dutch_guy 12y ago
  (Without being pedantic) are you aware of MinimaLT? It is really interesting technology (UDP).
- robomc 12y ago
  Seems like anything a server could do via cookies, they could also do via your client-generated session id. Servers which currently drop lots of individual cookies on you now, would just start dropping that data in the server-side session data. In either case they can tie your client to the same persistent information. Same for situations where javascript sets or gets cookie values - these could all be achieved via ajax, storing server-side against your session id. If anything, it possibly reduces my options as a client, in situations where a site previously dropped lots of cookies on me, as now my only options are to completely close my session, or persist all data, when before there were situations where I could maintain, say, my logged in user session, while removing the "is_a_jerk=true" cookie.

codexon 12y ago

This is not equivalent to cookies. Cookies allow you to specify arbitrary data, not just a session ID, so you can set preferences without having to hit a database or even running a completely static page, using javascript to read the settings. Cookies as they are now already allow you to control persistence. You can edit or delete them however you wish.

ricardobeat 12y ago
Except that deleting/not allowing cookies will make most of the things we use everyday unusable. Including this website.