- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 23 Dec 2011 22:08:10 -0500
- To: Adam Barth <w3c@adambarth.com>
- Cc: Julian Reschke <julian.reschke@gmx.de>, HTTP Working Group <ietf-http-wg@w3.org>
On 14/12/2011, at 11:50 PM, Adam Barth wrote: >>> 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). 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/
Received on Saturday, 24 December 2011 03:08:35 UTC