Re: Action 13 - Mandatory Server Response

On Oct 10, 2011, at 4:57 PM, Jonathan Robert Mayer wrote:

> Please provide a concrete use case with an example set of resource requests. Either I'm not seeing the problem, or it seems trivial to solve.

Umm, all use cases?  All GET requests made to the site.  Every single
page, CSS, javascript, inline image, etc.

HTTP requires that Vary be added when a cacheable response will
change based on the presence on an HTTP header field in the request.

HTTP requires caches that receive Vary in a response to use the list
of header fields as part of the key for matching cached responses.

In other words, a stored response that contains an echo of the
client's request is necessarily unique to that request, requires
that "Vary: DNT" be added to the response, and MUST NOT be reused
for other clients that send a different DNT field (or none at all).
A response generated for a "DNT: 1" client can only be sent to other
requests that have "DNT: 1".  Without that requirement, a cached
response produced for one client (e.g., that asked for DNT: 0) will
confuse all other clients that send a different value for that field.

The effect of such variance is a tripling of the cache space
required for every resource on that site, for those caches that
support Vary, or a disabling of all shared caching for those
caches that do not support Vary.

To make matters worse, some operating systems (Windows) use a
shared cache for all client tools (i.e., MSIE) that does not
support Vary, which means it disables all caching if it receives
a Vary'ing response. [It has been five or so years since we
last tested that, so it may no longer be true of Windows 7.]

I hope that explains it.  In general, it is VERY bad form to
respond uniquely to a given request in HTTP unless the content
is truly unique.  Most large sites would collapse under the load
if they couldn't rely on at least 30% of their traffic being cached.
Thus, relatively few resources are customized -- user pages
and dynamic ad placements being the main ones -- and all of the
other responses made to a browser are designed to be cached.

I haven't seen a compelling reason to send any response, let alone
a response to every request.  The contents of the response are not
relevant to compliance -- it is the behavior of the origin server
after the current response that matters to DNT.  A well-known
location for indicating compliance is a far simpler and more
efficient solution.  If we do need to send a pacifier response on
requests, then it should be limited to those responses that are
already non-cacheable.  Otherwise, we break the Internet (or
make it impossible for sites to comply).

....Roy

> On Oct 10, 2011, at 7:46 PM, "Roy T. Fielding" <fielding@gbiv.com> wrote:
> 
>> Note that this would require all responses from that server
>> to disable shared caching ("Vary: DNT").  I think that is a non-starter.
>> 
>> If any DNT response is given, it should be restricted to responses
>> that are already intended to be non-cacheable (e.g., custom content
>> and advertising placements).
>> 
>> ....Roy
>> 
>> On Oct 10, 2011, at 4:25 PM, Tom Lowenthal wrote:
>> 
>>> Proposal to the W3C Tracking Protection Working Group
>>> Authored by Thomas Lowenthal, Mozilla
>>> Associated with [Action
>>> 13](http://www.w3.org/2011/tracking-protection/track/actions/13)
>>> 
>>> 
>>> When a server receives a request in which the DNT header is present, any
>>> response **must** include a header of the form:
>>> 
>>>> DNT:AB
>>> 
>>> where:
>>> - "A" is the the value of the header that the server received, and
>>> - "B" is a statement by the server about how it will act, where:
>>>  -"0" represents "will act as if the DNT signal is not present", and
>>>  -"1" represents "will act as if the DNT signal is present".
>>> 
>>> Examples:
>>> - A client sends a request with "DNT:1". The server knows that this user
>>> has previously agreed to be tracked in exchange for a delicious scone.
>>> The server responds with "DNT10", thereby stating that the user has
>>> requested not to be tracked, but the server will still track this user.
>>> - A client sends a request with "DNT:1". The server responds with
>>> "DNT:11", thereby stating that they have received, and will honor the
>>> user's request not to be tracked.
>>> - A client sends a request with "DNT:0". The server protects the privacy
>>> of all users equally, and responds with "DNT:01", thereby stating that
>>> the server will not track the user.    
>>> 
>> 
>>

Received on Tuesday, 11 October 2011 01:48:37 UTC