W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: The document's address

From: Nicholas Shanks <nickshanks@gmail.com>
Date: Fri, 8 Mar 2013 15:32:16 +0000
Message-ID: <CA+hEJVWww72deBu9nWTxJax+XX8u7E=wez37hmZJtRR0jtPTVA@mail.gmail.com>
To: IETF HTTP Working Group <ietf-http-wg@w3.org>
Cc: alexandre.fournel@gmail.com
On 18 January 2013 12:23, Roy T. Fielding <fielding@gbiv.com> wrote:

> Which would be a security hole if /collection-uri and /resource-uri
> are controlled by different owners.  In practice, there is no way
> for clients to know the scope of resource ownership.

I have always presumed that it must be defined somewhere that resource
ownership is accumulative and descendant.
i.e. the owner of the .uk TLD "owns" (can be considered authoritative
for) all resources under that domain, and that the (different) owner
of ".gov.uk" additionally owns all resources under *that* domain.
Isn't that how DNS, BCP, zones and glue all work?
Therefore a resource such as
http://homepages.megahostcorp.com/~fred/jane/jogging.html would have
the following owner set: { Network Solutions, Megahost Corp, Fred
Smith, Jane Smith } each one authoritative for all resources
underneath it (rtl for DNS; dot separated, ltr for paths; slash

Given this, a client or caching proxy CAN know that responses from
/~fred are authoritative for /~fred/jane/jogging.html (but not for

This is a restriction I could live with, since my item resources are
identified with a subpath of the collection URI.

Conflicts between owners would need to be handled by defining which
owner wins (those earlier up the chain probably know more about HTTP,
and have other mechanisms by which to sabotage resources under them
without having to resort to cache poisioning, but if MegaHostCorp
screw up, Fred can't fix it, even if he knew how to). So I suggest
that those further down the chain override those higher up. Then it's
also their own fault if things don't work.

Going back to my immediate need, given that Roy has shot down my own
suggestion and that anything proposed above isn't implemented yet, is
there no alternative mechanism people can think of within the HTTP
layer and below (i.e. one that does not require AJAX &
window.history.pushState) for a request to be made to one URL, and an
authoritative response to return the URI and representation of another
resource in a single round-trip, which caches can either ignore or
preferably cache as the representation for the URI provided in the

> Search for "cache poisoning" for more explanation.

Would we not be able to avoid any cache poisoning worries if the
transaction occurred over TLS? (caching on the client is still
desirable, even if proxies are not privy)

Received on Friday, 8 March 2013 15:33:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:10 UTC