Subject: Re: The document's address

From: Nicholas Shanks <[email-masked]>
Date: Fri, 8 Mar 2013 15:32:16 +0000

On 18 January 2013 12:23, Roy T. Fielding <[email-masked]> 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.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Mar 2013 16:42:11 +0100

On 2013-03-08 16:32, Nicholas Shanks wrote:
> ...

That implies a concept of hierarchical ownership that simply does not 
exist in HTTP. It might for some servers, but there's no guarantee.

Best regards, Julian

---

From: Nicholas Shanks <[email-masked]>
Date: Fri, 8 Mar 2013 16:10:48 +0000

On 8 March 2013 15:42, Julian Reschke <[email-masked]> wrote:

> That implies a concept of hierarchical ownership that simply does not exist
> in HTTP. It might for some servers, but there's no guarantee.

Can you provide an example (make one up) where ownership cannot be
defined as hierarchical and accumulative?

I am suggesting that HTTP's concept of "ownership" (for purposes of
replacing cache entries) be defined by the specs to be hierarchical,
since if I own / and I want to sabotage /subdir/ all I have to do is
log in to the server and replace/delete it.

-- 
Nicholas.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 08 Mar 2013 17:15:32 +0100

> defined as hierarchical and accumulative?

Pretty much any server that is backed by a content management system 
where ACLs can be set on individual resources.

> log in to the server and replace/delete it.

How is that relevant? Me confused.

Best regards, Julian

---

From: Albert Lunde <[email-masked]>
Date: Fri, 08 Mar 2013 10:24:50 -0600

> log in to the server and replace/delete it.

That's only true for a server based on a simple file system with no 
aliases.  I used to run a Apache web server where the home page and the 
top-level menu content were all aliased in from another directory, and 
htdocs was owned by root and rarely changed. This was to prevent things 
like Dreamweaver from nuking unrelated content.

But this is an implementation detail, unrelated to what's on the wire; a 
dynamic database-driven site, like a Web CMS, can implement completely 
different scopes of control.

---

From: Eitan Adler <[email-masked]>
Date: Fri, 8 Mar 2013 12:18:51 -0500

> log in to the server and replace/delete it.

What about systems that don't rely on path based hierarchy?  Imagine a
system that treats each term in the path as a filter for a search
query?  Also, what about aliases of items in multiple locations?
CMS/Database driven websites that have ACLs per item?

It is a mistake to treat any part of the URI beyond the domain as
indicating hierarchy.

-- 
Eitan Adler

---

From: Martin Thomson <[email-masked]>
Date: Fri, 8 Mar 2013 11:30:24 -0800

On 8 March 2013 08:15, Julian Reschke <[email-masked]> wrote:

>>> exist
> Pretty much any server that is backed by a content management system where
> ACLs can be set on individual resources.
>
>
We have this exact issue for push in HTTP/2.0.  The solution is to require
the server to understand the ownership structure of all the resources that
it serves and to enforce any constraints as necessary.

That's a fairly fundamental change to the expectations and responsibilities
around routing and ownership.  Clearly there are cases where this is
difficult for a server.  We have text on the subject, but more feedback is
always welcome.  We certainly do not make any assumptions about a
hierarchical structure to ownership.  That's the server's business.

--Martin