Re: Issue-4

On Oct 28, 2011, at 9:32 AM, David Singer wrote:
> On Oct 28, 2011, at 3:44 , Rigo Wenning wrote:
> 
>> David, 
>> 
>> I think this goes into the net-neutrality debate, an issue we can't tackle 
>> here.
>> 
>> Rigo
>> 
>> On Thursday 27 October 2011 17:11:58 David Singer wrote:
>>> I am, however, not enthused by the idea that intermediates that I did NOT
>>> choose and over which I have no control could change my statement.
>>> 
>>> "By staying in this hotel, you agree to have your outbound HTTP requests
>>> modified to state you explicitly permit tracking."
> 
> I think you may be right, alas.  But this is a powerful reason to need the response header.  If *I* set my system to send DNT, and the hotel modifies my outbound traffic to turn that request off, without a response header I won't know.  *With* the response header, I'll see the "thank you for telling me I can track you" coming back (unless the hotel is REALLY nefarious and remembers what I asked for and rewrites the response as well).

A proxy that is modifying header fields in requests is almost certain to
modify headers in responses as well, whether or not that is intentional.
Indeed, the fatal flaw of any mandatory extension to HTTP via header fields
is that some intermediaries do not forward unknown headers.

In contrast, the well-known location is fully capable of sending a dynamic
response to the user agent that tells them exactly how they are or are not
being tracked (and whether or not this message can be cached), and none of
the deployed intermediaries will interfere with a GET request on a well-known
location.

> I think we need a response, and the statement that intermediate nodes MUST NOT fiddle with responses, or cache them.

I did put that in, but the standard only effects compliant implementations
and any effect on caching will have to be limited to a very small set of
resources.

....Roy

Received on Friday, 28 October 2011 19:34:43 UTC