[http-state] Assumed Vary: Cookie

[Anne van Kesteren]

RFC 6265 does not really explain the relationship to the HTTP cache
and how this is somewhat special for cookies. In particular,
implementations assume that a different value for the Cookie request
header means the cache cannot be reused. Can errata be issued?

For additional context:

http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0464.html
https://bugzilla.mozilla.org/show_bug.cgi?id=1075297#c5


--
https://annevankesteren.nl/

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

[Bjoern Hoehrmann]

* Anne van Kesteren wrote:
>RFC 6265 does not really explain the relationship to the HTTP cache
>and how this is somewhat special for cookies. In particular,
>implementations assume that a different value for the Cookie request
>header means the cache cannot be reused. Can errata be issued?
>
>For additional context:
>
> http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0464.html
> https://bugzilla.mozilla.org/show_bug.cgi?id=1075297#c5

It seems that implementations vary in what assumptions they make about
server responses when sending or omitting a `Cookie` header in requests.
Even for the dominant web browsers there does not seem to be a common
reliable behavior, and I am sure there are non-browser caches that do
not assume `Vary: Cookie`. So it's not obvious to me what the document
should say on the matter.

(And as an aside, for the specific bug report above, it seems Chrome's
behavior is better than that of Firefox, but Mozilla does not seem in-
terested in aligning their implementation with Chrome in this regard.)
--
Björn Höhrmann · mailto:bjo...@hoehrmann.de · http://bjoern.hoehrmann.de
D-10243 Berlin · PGP Pub. KeyID: 0xA4357E78 · http://www.bjoernsworld.de
Available for hire in Berlin (early 2015) · http://www.websitedev.de/

[Julian Reschke]

On 2014-11-21 15:13, Bjoern Hoehrmann wrote:
> * Anne van Kesteren wrote:
>> RFC 6265 does not really explain the relationship to the HTTP cache
>> and how this is somewhat special for cookies. In particular,
>> implementations assume that a different value for the Cookie request
>> header means the cache cannot be reused. Can errata be issued?
>>
>> For additional context:
>>
>> http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0464.html
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1075297#c5
>
> It seems that implementations vary in what assumptions they make about
> server responses when sending or omitting a `Cookie` header in requests.
> Even for the dominant web browsers there does not seem to be a common
> reliable behavior, and I am sure there are non-browser caches that do
> not assume `Vary: Cookie`. So it's not obvious to me what the document
> should say on the matter.

What it currently says is (a) intentional and (b) consistent with the
relevant HTTP spec
(<http://greenbytes.de/tech/webdav/rfc6265.html#rfc.section.3.p.3>):

"The presence of a Cookie or a Set-Cookie header field does not preclude
HTTP caches from storing and reusing a response."

Furthermore, Anne says:

"...that a different value for the Cookie request header means the cache
cannot be reused. ..."

If a resource varies on "Cookie", it will also vary on the *absence* of
Cookie (which in general would imply non-authenticated access if the
cookie was used to identify the user). So that would need to be made
very clear.

I'm ok with a potential revision of RFC 6265 *mentioning* the caching
heuristics that are in common use, but right now I don't see a normative
requirement coming out of that.

> (And as an aside, for the specific bug report above, it seems Chrome's
> behavior is better than that of Firefox, but Mozilla does not seem in-
> terested in aligning their implementation with Chrome in this regard.)

Pointer?

Best regards, Julian