- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Wed, 14 Dec 2011 18:05:13 +0100
- To: Mark Nottingham <mnot@mnot.net>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
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? > 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? > Comments? Best regards, Julian
Received on Wednesday, 14 December 2011 17:05:55 UTC