- 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>
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). Regards, Brian
Received on Wednesday, 27 May 2009 14:30:07 UTC