Re: Action 13 - Mandatory Server Response

Thanks — I had missed that earlier note.  That clarifies things.

(Also, this is still related to ACTION-13; just making sure that tracker catches this message in the right thread.)
--
Thomas Roessler, W3C  <tlr@w3.org>  (@roessler)







On 2011-11-29, at 01:42 +0100, Roy T. Fielding wrote:

> On Nov 27, 2011, at 5:49 AM, Thomas Roessler wrote:
> 
>> Roy,
>> 
>> looking through previous discussion of dynamic DNT response headers and "Vary: DNT", about the most extensive explanation I see is:
>> 	http://lists.w3.org/Archives/Public/public-tracking/2011Oct/0044.html
>> 
>>> Note that this would require all responses from that server
>>> to disable shared caching ("Vary: DNT").  I think that is a non-starter.
>> 
>> Just from the protocol definition, that conclusion doesn't follow (using the httpbis draft):
>> 	http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-17#section-3.5
>> 
>> I vaguely recall that you had the behaviors of particular implementations in mind in previous discussions.
>> 
>> Care to put on the record in a bit more detail what that was all about?
> 
> Did you see the follow-on to that thread?
> 
>  http://lists.w3.org/Archives/Public/public-tracking/2011Oct/0047.html
> 
> Vary is a semantic requirement --- sending it is only required if the
> server wishes to retain uniform semantics in the presence of caching.
> [RFC2616 had a variety of requirements on "transparency" that meant
> the same thing.]
> 
> The server can choose not to send Vary on request-varying content
> if shared caching has been disabled by other means (cache-control)
> or if the server does not care what intermediate caches deliver to
> other user agents.  IOW, if one user visits with DNT: 0 and the
> next visits with DNT: 1, and if the server doesn't care that an
> intermediate cache stores the first response and delivers it to
> the second user, then the server does not need to set Vary.
> 
>  http://tools.ietf.org/html/draft-ietf-httpbis-p6-cache-17#section-2.7
> 
> For example, the server could instead send
> 
>   Cache-control: s-maxage=0
> 
> and force shared caches to revalidate (conditional GET) every time.
> Note, however, that this option is not well implemented in practice
> and relies on the cache merging the header fields from the 304
> response with the fields already in the cache.
> 
> I don't know how s-maxage is implemented on Windows, so I don't
> know if the second option would mitigate the problems in WinINET
> 
> http://blogs.msdn.com/b/ieinternals/archive/2009/06/17/vary-header-prevents-caching-in-ie.aspx
> 
> In any case, a negative effect on caching must have proven benefits
> that exceed the cost.  So far, there gave been no such benefits
> demonstrated by the presence of a response header (i.e., the
> recipient does not sufficiently gain anything from that response
> such that it offsets the cost to the network of disabling caching).
> 
> That is why I am only considering response headers on content
> for which shared caching is already disabled.
> 
> ....Roy
> 
>

Received on Tuesday, 29 November 2011 09:10:22 UTC