- From: Daniel Stenberg <daniel@haxx.se>
- Date: Wed, 15 Aug 2018 08:01:45 +0200 (CEST)
- To: Mike West <mkwst@google.com>
- cc: HTTP Working Group <ietf-http-wg@w3.org>
On Tue, 14 Aug 2018, Mike West wrote: > https://github.com/mikewest/http-state-tokens suggests that we should > introduce a client-controlled, origin-bound, HTTPS-only session identifier > for network-level state management. And eventually deprecate cookies. I'm thinking this suggestion will handle some cookie use cases really fine (login-like for example) but some others much less fine: Imagine a site that uses a cookie (for millions of users) if they saw the introduction page or not and can skip showing it if the user already saw it. Setting a cookie "sawintro=yes" is very lightweight and easy. Each client is then responsible for telling the server on the next visit that it already saw it; cookies used for client-side state as it was meant to be. Sec-HTTP-State doesn't make this very easy... So, looking into the crystal ball, won't this lead to clients using both cookies *and* Sec-HTTP-State ? Then, a suggestion on terminology: The document says "browser" in eight places when talking about a cookie-using HTTP client. Cookies is a well used mechanism even for non-browser HTTP clients and I believe referring to the user-agent as a "browser" in a document like this is bad. -- / daniel.haxx.se
Received on Wednesday, 15 August 2018 06:02:11 UTC