Re: Well-known URI vs response headers? [ISSUE-81, ISSUE-47, ISSUE-80]

I've never seen that use-case with Akamai.  The normal configuration is that
a company creates a personalized domain-name that ultimately resolves to a
server on the Akamai network, like "ak.mysite.com", and that is where your
content is hosted.  Normal sites do not host their content under an "
akamai.net" domain name.

By putting content under "ak.mysite.com", the wkl for your DNT response
would be something like "mysite.com/dnt/" or "ak.mysite.com/dnt/" (with the
possibility to 301 or 302 redirect to another location?)  There is no need
for a million-line wkl response at the root of Akamai.

--Ronan Heffernan


On Fri, Oct 28, 2011 at 7:24 AM, Rigo Wenning <rigo@w3.org> wrote:

> Hi Matthias,
>
> if all the site honors DNT or P3P, no issue. We have a well-known location
> in
> P3P and we had to steam-roll Dan Connolly to get it. All is now very
> simple:
> The browser checks the well-known location, finds the policy (or DNT
> confirmation) and done for the entire site. Simple! Do you check that with
> every http-request? It may change. What does that mean for the policy
> assertion being made?
>
> Now imagine that some parts of a site are DNT enabled, others are not. In
> your
> well-known location (wkl), you will have to tell the DNT client which part
> of
> the site can do DNT and which can't. The client will have to remember, so
> it
> can avoid to request the DNT  wkl with every request. We will invent regex
> in
> the file on the wkl to determine the parts of the site that can do DNT and
> those they don't. And we will invent caching as sites are more complex than
> we
> imagined because the file became bigger and bigger.
>
> Now imagine you're akamai or some other cloud thingy. The request of the
> content goes to your site (e.g. large images) because your globally
> distributed system is designed to improve loading times. The way this works
> is
> that you request the image from xyz.akamai.net. So every akamai server has
> to
> know about all clients it provides content for and whether they can do DNT
> or
> not. If you put all this information in a wkl, the file will be huge. But
> it
> is no issue to have a server-side smallish simple database that determines
> when to send DNT=1 (enabled) or not.
>
> Now imagine, you're a technology provider who provides content for
> customers
> from own servers that are dynamically meshed into your customer's content.
> How
> would you construct a wkl here?
>
> Creativity of configurations of http servers is endless. The wkl can't cope
> with that. I'm just saying that I got my fingers already burned once.
>
> Best,
>
> Rigo
>
> On Thursday 27 October 2011 09:32:19 Matthias Schunter wrote:
> > Roy (the editor & http guru) and I perceive a well-known URI to be the
> > simpler option: Once a user has turned on DNT, a simple round-trip to
> > check this URL to us seemed simpler than adding a response header to
> > all (many!)  http responses.
>
>
>
>