Re: Action 13 - Mandatory Server Response

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 00:42:44 UTC