Re: [http-state] Assumed Vary: Cookie

Julian Reschke <> Fri, 21 November 2014 14:25 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 1552C1AD48D for <>; Fri, 21 Nov 2014 06:25:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8E1DV5XhCaYc for <>; Fri, 21 Nov 2014 06:24:58 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5A94E1AD47A for <>; Fri, 21 Nov 2014 06:24:56 -0800 (PST)
Received: from [] ([]) by (mrgmx102) with ESMTPSA (Nemesis) id 0Lxdfb-1Y26iQ2l1H-017DYM; Fri, 21 Nov 2014 15:24:49 +0100
Message-ID: <>
Date: Fri, 21 Nov 2014 15:24:44 +0100
From: Julian Reschke <>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0
MIME-Version: 1.0
To: Bjoern Hoehrmann <>, Anne van Kesteren <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:hGeeMi2vr8NFLJufJt5Vu2Ktlwcex8ty0kJToXuVZUR/Xc24Ia8 ugmEUXWdQ1MADEysV0/7M9GviRZ7NR6lDaiOsC4j6k5lmq7Wl2IdxrDUTG/TWzhPIRVYs+9 hqQ+LBWLbnb1Uzwn/Z5qoTiYAcHSsEbp8120EXmtpFhNgUAB0TQcUhFCoPnAvwYpD9FIYnn Iee1ntOLyeYT2GD11vj5g==
X-UI-Out-Filterresults: notjunk:1;
Cc: Boris Zbarsky <>,
Subject: Re: [http-state] Assumed Vary: Cookie
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Nov 2014 14:25:01 -0000

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:
> 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 

"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.)


Best regards, Julian