Re: [ISSUE-81, ACTION-13] Response Header Format

The issue of conflicting policies under one domain (as in your multiple
businesses example), can be handled by regex patterns (I think that Roy
offered this solution?) inside the response document.  One problem with a
link/rel or an HTTP header, is that the user might have already been tracked
when the first document was fetched, before they have the opportunity to
parse the response.  Having a well-known URI does not have this
disadvantage, if tracking is universally forbidden during the fetch of that
well-known URI.

--ronan


On Fri, Oct 28, 2011 at 3:28 PM, Karl Dubost <karld@opera.com> wrote:

>
> Le 26 oct. 2011 à 07:02, Matthias Schunter a écrit :
> > Imagine a well-known URL http://[site]/dnt where a file with two lines
> > is stored:
> > Tracking: [code] //* similar to the codes discussed for the headers
> > MoreInfo: [URL]  //* Explanations, privacy policy, opt-in, ...
>
>
> well-known URIs do not work when example.com domain names host more than
> one web site.
>
> example.com/business1
> example.com/business2
> example.com/.well-known/dnt
>
> Exactly the same issue than robots.txt or favicon.ico. favicon.ico
> has been partly solved by the creation of a link header in the HTML
> document. But that doesn't work with non HTML document. I have not
> tested favicon with an HTTP "Link:"
> robots.txt is definitely useless in this context.
>
> Another issue is that it has a tendency to create useless HTTP
> requests on the Web for each individual requests.
>
> I would be happier with a
>
> Link: <URI>;rel=[tobedefined]
>
>
>
> --
> Karl Dubost - http://dev.opera.com/
> Developer Relations & Tools, Opera Software
>
>
>