W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

RE: draft-ietf-httpbis-p6-cache-06

From: Brian Smith <brian@briansmith.org>
Date: Wed, 27 May 2009 09:28:24 -0500
To: "'Adrien de Croy'" <adrien@qbik.com>, "'Brian Smith'" <brian@briansmith.org>
Cc: "'HTTP Working Group'" <ietf-http-wg@w3.org>
Message-ID: <004301c9ded7$652fb4d0$2f8f1e70$@org>
Adrien de Croy wrote:
> So it's invalid to include a Cache-Control: public say on the POST
> response?

It's not invalid, but it doesn't mean anything. POST responses are never
cacheable; caches must write POST requests through to the server, and a
cache can't use a POST response to respond to a GET/HEAD request.

> >> If a shared cache however appends a bunch of ETags to an If-None-
> >> Match header, then the server selects from those using
> >> Content-Location, then the shared cache / proxy needs to
> >> return the resultant selected entity?
> >> Same as if the origin server returned an ETag.
> >>
> >
> > I'm not sure what you mean here. The origin server doesn't use
> > Content-Location to choose a variant; it is going to use the request
> > to choose a variant.
> >
> It uses it to indicate a chosen variant is what I meant sorry.  the
> cache then uses the Content-Location field to choose from amongst a set
> of variants.

If the server returned cacheable responses with ETags, and then returns a
304 response during validation, then it needs to return an ETag in the 304
response. A cache will only use Content-Location to determine which variant
to return when the server didn't return an ETag (that is, when the
validation is being done using If-Modified-Since instead of If-None-Match).

Received on Wednesday, 27 May 2009 14:30:07 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:10:49 UTC