- From: Adam Barth <w3c@adambarth.com>
- Date: Wed, 14 Dec 2011 20:50:36 -0800
- To: Mark Nottingham <mnot@mnot.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On Wed, Dec 14, 2011 at 2:49 PM, Mark Nottingham <mnot@mnot.net> wrote: > > On 15/12/2011, at 4:05 AM, Julian Reschke wrote: > >> On 2011-12-14 04:27, Mark Nottingham wrote: >>> <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. >> >> Not *entirely* convinced. >> >>> Proposal for p7 2.2: >>> >>> """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? > > Seems reasonable, as long as we don't veer too far into re-defining it. > >> 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].""" >> >> 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. 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
Received on Thursday, 15 December 2011 06:36:47 UTC