- From: Nicholas Shanks <nickshanks@gmail.com>
- Date: Fri, 8 Mar 2013 15:32:16 +0000
- 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 separated) Given this, a client or caching proxy CAN know that responses from /~fred are authoritative for /~fred/jane/jogging.html (but not for /~fredjones) 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 response? > 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) -- Nicholas.
Received on Friday, 8 March 2013 15:33:29 UTC