- From: Brian Smith <brian@briansmith.org>
- Date: Wed, 27 May 2009 09:14:53 -0500
- To: "'Yves Lafon'" <ylafon@w3.org>, "'Brian Smith'" <brian@briansmith.org>
- Cc: "'Adrien de Croy'" <adrien@qbik.com>, "'HTTP Working Group'" <ietf-http-wg@w3.org>
Yves Lafon wrote: > On Tue, 26 May 2009, Brian Smith wrote: > > > I thought I had an explanation of how this could be useful, but my > > explanation doesn't really jive with what the spec. says. I, too, > > would really like to hear somebody explain how a cache is supposed > > to handle private="header1, header2" and > > no-cache="header1, header2". > > The same way you will handle "Cache-Control: no-cache, max-age=86400". > It is an error case, and a good implementation will most probably > choose to take the more restrictive approach (no-cache), or simply > discard the response for the cache purpose (so treat it as > uncachable, which is the same as no-cache, but the intent is > different). Another extreme is to simply reject such responses > as it is clearly an error. I was unclear. I was asking, simply, what does Cache-Control:private="header1, header2" mean? How, exactly, should a cache process subsequent requests differently than if the cache response had just Cache-Control:private? And, how can a cache treat Cache-Control:no-cache="header1, header2" differently than just Cache-Control:no-cache? How can one cache and revalidate only part of a response? Regards, Brian
Received on Wednesday, 27 May 2009 14:30:53 UTC