Subject: #322: Origin

From: Mark Nottingham <[email-masked]>
Date: Wed, 14 Dec 2011 14:27:56 +1100

<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/322>

Since we now have a definition of an Origin, it'd be good to use it where appropriate.

Proposal for p7 2.2:

"""A protection space is defined by the origin [ref to origin rfc], combined with the realm value (if present)."""

Proposal for p6 2.5:

"""However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if that URI does not have the same origin as that of the effective request URI (section 4.3 of [Part1]), as specified in [ref to origin rfc]."""

Comments?

--
Mark Nottingham   http://www.mnot.net/

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 18:05:13 +0100

> Since we now have a definition of an Origin, it'd be good to use it where appropriate.

Not *entirely* convinced.

> """A protection space is defined by the origin [ref to origin rfc], combined with the realm value (if present)."""

We currently have:

  "canonical root URI (the scheme and authority components of the 
effective request URI; see Section 4.3 of [Part1])"

That is essentially the same as the Origin, if we add the the comparison 
rule from 
<http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-17.html#rfc.section.2.7.3>

My concern is that the Origin spec does all these special things for 
case we don't need to care of. Maybe we should just define the "origin" 
of a effective request URI in Part 1, and state that it's the same as 
the one you'd get following the algorithm in the Origin spec?

> """However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if that URI does not have the same origin as that of the effective request URI (section 4.3 of [Part1]…

Currently: "However, a cache MUST NOT invalidate a URI from a Location 
or Content-Location header field if the host part of that URI differs 
from the host part in the effective request URI (Section 4.3 of 
[Part1]). This helps prevent denial of service attacks."

So this is *different* from Origin in that it doesn't take the scheme 
and the port into account. Is this an intentional change?

> Comments?

Best regards, Julian

---

From: "Roy T. Fielding" <[email-masked]>
Date: Wed, 14 Dec 2011 10:55:29 -0800

No, the notion in Origin is an exception to DNS authorities for broadening
security constraints on javascript, etc.  HTTP caching must not allow a
non-matching-authority (including a different port) define what can be
invalidated or replaced.

....Roy

---

From: Julian Reschke <[email-masked]>
Date: Wed, 14 Dec 2011 20:16:32 +0100

> non-matching-authority (including a different port) define what can be

But scheme + port are part of the Origin.

My concerns are more from an editorial point of view...

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 15 Dec 2011 09:49:57 +1100

On 15/12/2011, at 4:05 AM, Julian Reschke wrote:

> "canonical root URI (the scheme and authority components of the effective request URI; see Section 4.3 of [Part1])"
> 
> That is essentially the same as the Origin, if we add the the comparison rule from <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-17.html#rfc.section.2.7.3>
> 
> My concern is that the Origin spec does all these special things for case we don't need to care of. Maybe we should just define the "origin" of a effective request URI in Part 1, and state that it's the same as the one you'd get following the algorithm in the Origin spec?

Seems reasonable, as long as we don't veer too far into re-defining it.

> Currently: "However, a cache MUST NOT invalidate a URI from a Location or Content-Location header field if the host part of that URI differs from the host part in the effective request URI (Section 4.3 of [Part1]). This helps prevent denial of service attacks."
> 
> So this is *different* from Origin in that it doesn't take the scheme and the port into account. Is this an intentional change?

It's worth talking about. 

My initial reaction is that we shouldn't make a change here. However, there's some value in aligning this scope with others, rather than having so many slightly different ones.

--
Mark Nottingham
http://www.mnot.net/

---

From: Adam Barth <[email-masked]>
Date: Wed, 14 Dec 2011 20:50:36 -0800

> My initial reaction is that we shouldn't make a change here. However, there's some value in aligning this scope with others, rather than having so many slightly different ones.

Is there some advantage to ignoring the scheme?  Generally, it's
better to align all these boundaries along the same lines to avoid the
"cracks" causing problems (e.g., the security problems with cookies).

Adam

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 23 Dec 2011 22:08:10 -0500

> "cracks" causing problems (e.g., the security problems with cookies).

That's roughly what I was thinking too.

The deciding factor here, I think, is how much real security advantage there is to aligning these boundaries; making this change has the potential to make current implementations non-conformant, which we should only do if there's significant advantage in terms of security or interoperability.

That said, my experience is that implementation of cache invalidation is spotty, so implementations are already often non-conformance, and making this more simple / aligned is attractive.

What do others think?

Cheers,

--
Mark Nottingham
http://www.mnot.net/