W3C home > Mailing lists > Public > public-tracking@w3.org > November 2011

Re: Action 13 - Mandatory Server Response

From: Thomas Roessler <tlr@w3.org>
Date: Tue, 29 Nov 2011 10:10:15 +0100
Cc: Thomas Roessler <tlr@w3.org>, "Tracking Protection Working Group WG (public-tracking@w3.org)" <public-tracking@w3.org>
Message-Id: <C577A4D0-A23E-4304-AF68-B701201AF65F@w3.org>
To: "Roy T. Fielding" <fielding@gbiv.com>
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

This archive was generated by hypermail 2.3.1 : Friday, 3 November 2017 21:44:42 UTC