Re: when the Tk header is required

On Monday 27 August 2012 09:59:05 David Singer wrote:
> > I think the policy of "site-wide resource unless a Tk header
> > is present which would override" would be more efficient for
> > implementers. Sites could then use the model of a site-wide
> > tracking status resource being the default but any exceptions
> > being documented in a request-specific resource or specific
> > header. That was my understanding of the Google use case
> > request, for example.
> That makes sense.  
> 
> I also recall that the original motivation for the well-known
> resource was that replies of the kind "I respect your DNT:1
> header" or "I currently behave to you as a 3rd party" were
> user-specific and hence not cachable.  However, many (most) of
> the responses are now of the form "I am designed to be used in a
> 1st party context", i.e. static statements of intent rather than
> user-specific statements of current state.
> 
> Given the concerns about caching, it seems it's worth asking
> whether it works better 'the other way up':  make general,
> cachable statements in the Tk header, and if that is missing (or,
> better, says "ask me"), then ask the UA to resort to the
> well-known resource (which can be a CGI) for personal/contextual
> answers.

Support from me for that. In the other answer, Roy said it isn't an 
answer to _this_ request. But _this_ request is part of an assertion 
on _all_ requests. Thus the statement is binding, legally. So some 
cloudy statement may be more harmful to the service than a system 
where the site-designer can trigger a different answer for _this_ 
request at any moment by sending a TK-Header.

Rigo

Received on Tuesday, 28 August 2012 18:28:10 UTC