Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Received-SPF: pass (athena.apache.org: domain of ylavic.dev@gmail.com
 designates 209.85.210.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <6FC30D9B-42E8-4349-9E6B-E8500B1E12DA@jellybaby.net>
References: 
 <CAKQ1sVOb81xpdyNQ4waHT=U4h+Cizn0WUYUxPGSFMKpyGJcmBQ@mail.gmail.com>
	<AE30AB14-D1E1-4028-B886-06FA563C4944@sharp.fm>
	<CAKQ1sVPaGG2PB318-mEUaWA3-oox+ow80eiDfzvcXgRzRtSi2g@mail.gmail.com>
	<5A706E07-D227-4B0A-A428-909E27FA963B@sharp.fm>
	<CAKQ1sVMRmEa1CXcH3QQE-jnV39zmWbHjWjqaptjtJFnY53KKog@mail.gmail.com>
	<CAFHbX1J0rb78qTya4QwAOJJ9MbXbjgXkmxf3f_v934X2-h5GbQ@mail.gmail.com>
	<CAKQ1sVOPJpfycJvcTT8pLN-ixtZDkV_qLGNrAh5tv1f=U7a8Kw@mail.gmail.com>
	<6FC30D9B-42E8-4349-9E6B-E8500B1E12DA@jellybaby.net>
Date: Thu, 14 Mar 2013 00:56:28 +0100
Message-ID: 
 <CAKQ1sVM5R5+ppeo=r4bGzRACXcxyAXzYfAmqAcymNM_BwvSNGg@mail.gmail.com>
Subject: Re: mod_cache with Cache-Control no-cache= or private=
From: Yann Ylavic <ylavic.dev@gmail.com>
To: dev@httpd.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 13, 2013 at 9:28 PM, Tim Bannister <isoma@jellybaby.net> wrote:
> Is this the situation you're worried about:
>
> ClientA: GET /foo HTTP/1.1
> ReverseProxy: GET /foo HTTP/1.1
> Origin: HTTP/1.1 200 OK
> Origin: Set-Cookie: data=3DAAAAAA
> Origin: Cache-Control: private=3DSet-Cookie
> ReverseProxy: Set-Cookie: data=3DAAAAAA
> ReverseProxy: Cache-Control: private=3DSet-Cookie
>
> ClientB: GET /foo HTTP/1.1
> ClientB: Cookie: data=3DBBBBBB
> ReverseProxy: GET /foo HTTP/1.1
> ReverseProxy: Cookie: data=3DBBBBBBB
> Origin: HTTP/1.1 304 Not Modified

Yes, about what happens now, the ReverseProxy (mod_cache) must not
"Set-Cookie: data=3DAAAAAA" to ClientB.

> This should just work. The final reply from the cacheing reverse proxy sh=
ould look like this:
> ReverseProxy: HTTP/1.1 304 Not Modified
> ReverseProxy: Date: =85

This actually does not work, mod_cache will serve the cached Set-Cookie.
The CacheIgnoreHeaders directive only can prevent this (not controlled
by the origin).

The final reply to ClientB, whose request is not conditional, can also be :
ReverseProxy: HTTP/1.1 200 OK
ReverseProxy: Cache-Control: private=3DSet-Cookie
ReverseProxy: <cached body>
That's the main goal I guess (limit backend hits for large things).

> and the Set-Cookie: header from the stored request would not be used (in =
fact, the proxy may have elected not to store it). The origin doesn't have =
to mention that header in the 304 response.

In mod_cache the "no-store" of a particular header is harder to patch
than the "no-cache" (ie. do not serve without revalidation), but
indeed the former would be more efficient, no need to "sanitize" each
served response.

For the "private=3D", the rfc does not say more than its BNF...
If private has the same semantic as without the =3D, the header should
not be stored (the "Cache-Control: private" response is not stored by
mod_cache).

In all cases, IMHO, no cached Set-Cookie should aver played by a cache
with private/no-cache=3D"Set-Cookie" associated with the resource.