Re: Proposal for ... POST when dealing with large numbers of URIs

On Mon, 04 Feb 2008 19:53:01 +0100, John Panzer <jpanzer@acm.org> wrote:
> (I'm assuming substring == path prefix.)

Not just path actually. You'd store

   http://example.org:80/foo

and then if you want to do a request to http://example.org:80/foo/bar.cgi  
you'd do a substring match (if the request URI starts with the "cached"  
URI). (Then again, the implementation details could differ, as long as the  
implementation produces identical results :-))


> 1. Question: If a cache ends up containing entries for both (ref,/foo),  
> (ref,/foo/bar/), and processes a non-GET cross-site request:  
> (ref,/foo/bar/baz.cgi), then it falls under both path prefixes.   My  
> reading of http://dev.w3.org/2006/waf/access-control/#access0 is that  
> the access check process then roughly behaves "as if" all of the  
> Access-Control information for both /foo and /foo/bar were merged and  
> present in an Access-Control header for /foo/bar/baz.cgi.

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/.


> However, Access-Control information that might be present on  
> /foo/bar/baz.cgi itself is not used since no OPTIONS request is sent to  
> that resource.  Is this right?

Yes, that's correct.


> 2. A subsequent GET of /foo/bar/baz.cgi could add a cache entry  
> (ref,/foo/bar/baz.cgi), which could provide access control information  
> for non-GET requests as well.  Would the algorithm above ignore this  
> cache entry's allow and deny clauses for non-GET requests, or fold it  
> in?  (I wasn't sure what 'as a prefix' meant in the paragraph -- it  
> appears to be ruling out an exact full match for the item itself.)

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.


-- 
Anne van Kesteren
<http://annevankesteren.nl/>
<http://www.opera.com/>

Received on Tuesday, 5 February 2008 01:19:43 UTC