Re: [http-state] Welcome to http-state

> While technically true, this doesn't actually help in practice because
> Secure and non-Secure cookies are serialized identically in the Cookie
> header, make it impossible for the server to tell whether the cookie
> was set over HTTP or HTTPS.

I see what you're a saying. However, if the user-agent actively asserts
"the integrity of these cookies is preserved" or the server operates on
the assumption that the cookie it previously set over HTTPS did not get
overwritten via HTTP (much like servers currently assume the user-agent
implements the same-origin policy), the server is still in the same
position - it must trust what the user agent is telling it with respect
to cookie integrity. 

> XHR has a generic generic namespace of headers that can't be set by
> script: those that begin with "Sec-".  We could simple name the header
> "Sec-Cookie-Integrity" if we want this behavior.

Good idea. 

> Oops.  Typo.  I meant "overwrite Secure cookies over HTTP (for
> example, during logout)." 

Ah, yes, I agree this use case would break. Though, I don't think I've
encountered many, if any, instances of this. That surely doesn't mean a
million of them don't exist :)

Blake 
_______________________________________________
http-state mailing list
http-state@ietf.org
https://www.ietf.org/mailman/listinfo/http-state