On Tue, 05 Feb 2008 07:18:59 +0100, John Panzer <[EMAIL PROTECTED]> wrote:
Anne van Kesteren wrote:
I haven't actually decided how to deal with this situation. My plan was
to actually remove all entries that match a certain URI when entering a
new one. So if /foo/bar/ gives me a cache policy under /foo/bar/
(leaving out the full URI for now) and /foo/baz/ gives me a policy for
/foo/ entering the /foo/ entry would mean deletion of /foo/bar/.
OK. So if a server isn't consistent in its access policies, then
retrieving /foo/bar/ and then /foo/ might accidentally remove a
restriction that exists only on /foo/bar/. I think this is fine as long
as the semantics are clearly spelled out for server policy makers; if
they did this, their policies would either be redundant or
contradictory. Probably a rule of thumb like "pick a directory level
and stick with it for access control policies" would be good.
Yeah.
During GET requests no cache information related to cross-site requests
is created. That can only happen as the result of a "special" preflight
OPTIONS request.
Ah, OK. Why? (Being able to tell conforming clients to short-circuit
disallowed GETs would certainly save us all some DDOS attacks...)
GET is already possible cross-site using <img>, <script>, <form>, etc.
Putting additional constraints on GET request for protocols following the
Access Control specification wouldn't make much sense. As currently
specified nothing is short-circuited, by the way. That is, a failed
OPTIONS request obviously won't be followed by the actual POST (or other
non-GET method) request, but you can after that try to make another POST
request which will result in a new OPTIONS request that might very well
fail again.
--
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>
