3 ms·

A well designed HTTP/2.0 would not "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mas

by phkamp 12y ago

A well designed HTTP/2.0 would not "fundamentally differ from HTTP", and it would be trivial for web-servers like NGNIX and APACHE or frameworks like PHP to mask the differences for the application code. For instance moving cookies to the server side would just require a simple key-value store lookup.

Sammi 12y ago
Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask: Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead? Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?
- phkamp 12y ago
  They could if the client provided a session-id so they knew which "cookie" to retrive from server-side storage. My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session. A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time. This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.
  - gregory144 12y ago
    Can't the client side do this already (with HTTP/1.1) by turning off cookies? Or are you pushing for browsers to turn off cookies by default?

by phkamp 12y ago

Sammi 12y ago

Forgive me if I'm not well enough informed to partake productively in this discussion. I just wanted to ask: Can't anyone implementing a webclient and webservice on top of common web servers and browsers, choose to forgo cookies and keep the state server side? If this is so, then why do people choose to use cookies if they give more overhead? Also you would need to keep some sort of unique identifier on the client, that the client can send the server, in order for the server to be able to look up the session state (a session id). Isn't this what cookies often are used for? I'm guessing this is probably what you meant "information-free session nonces" would solve above. This sounds interesting, could you explain this scheme to me or maybe point me in the direction of a good resource?

phkamp 12y ago
They could if the client provided a session-id so they knew which "cookie" to retrive from server-side storage. My proposals is to do that, and have the top bit in the session-id mean "Persistent" or "Anonymous", so that client undisputably controls if anything will be stored about the session. A Pesistent session-ID would be the same next time you visit the site, an Anonymous would be random, and thus not retrive any state on the server side, even if they saved it last time. This would put the privacy decision in the hands of the client, provided we also eliminate crap like almost-per-user-unique user-agent headers.
- gregory144 12y ago
  Can't the client side do this already (with HTTP/1.1) by turning off cookies? Or are you pushing for browsers to turn off cookies by default?