RE: Action 13 - Mandatory Server Response

If a response is necessary, I really do not see the value of repeating the request value.  In addition to Roy's arguments, this just seems like a waste of a byte and additional parsing and processing for everyone.  It would tell you that the server received and understood the DNT request.  However, given the fact that the server returned a DNT Response, I think it can be implied that the server received the DNT request.  And I cannot believe that we are really concerned with whether or not the value was received correctly (at least more so than the rest of the request) since at the moment, we are talking about a single character with exactly 2 legal values.  

Are there other examples of request headers that get echoed and then appended to in the response?  If not, is there a compelling reason why this request should be handled differently?  And how would the browsers use the response (either when it is the same or different), if they use the response at all?  Tom, can you provide an example of how a browser would use the echoed value?  Would you expect the browser, or auditor, or regulator to change anything based on the echoed value?  

Unless the first response value ("A" in the proposal below) really means "This is the privacy setting the user has indicated to me" rather than "this is what I heard in the DNT request header".  Meaning that it incorporates other opt-in/opt-out settings as well.  In which case, it is really a "why I am not respecting the DNT header" field, and as such should only be sent when it differs from the DNT request.


-----Original Message-----
From: public-tracking-request@w3.org [mailto:public-tracking-request@w3.org] On Behalf Of Roy T. Fielding
Sent: Monday, October 10, 2011 7:48 PM
To: Jonathan Robert Mayer
Cc: Tom Lowenthal; public-tracking@w3.org
Subject: 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 Wednesday, 12 October 2011 13:45:12 UTC