Re: [access-control] non-GET threat model and authorization choreography

On Oct 9, 2007, at 01:26, Jonas Sicking wrote:

> Henri Sivonen wrote:
>>> Also note that the server can make the GET request be cached in  
>>> the browser which should make the overhead of a GET fairly low.
>> Actually, the HTTP-level cacheability of GET doesn't work here.  
>> The POST request to the URI invalidates the cached GET response,  
>> so when you are doing the next POST, the GET response should no  
>> longer be in cache. (This is not currently true of Firefox, but  
>> that's a bug: https://bugzilla.mozilla.org/show_bug.cgi?id=327765 )
>> Therefore, with GET you'd need to maintain an access-control  
>> method authorization cache independently of the HTTP caching of  
>> the GET response. And at that point, you might as well maintain an  
>> access-control method authorization cache for information obtained  
>> via OPTIONS.
>
> Hmm.. this is very interesting indeed. I don't really have an  
> opinion either way as I don't know the specifics of HTTP well  
> enough. Another option would be to simply state that the  
> implementation is allowed to ignore that rule for the POST/PUT/ 
> DELETE request that is coming after the GET for this one case.

I think making an exception to HTTP caching in this case to make the  
GET response stick against RFC 2616 rules would be a bad idea since  
the Web app might well malfunction if subsequent non-access-control  
GETs retrieved a stale resource representation from the cache (in  
cases where the GET is really about getting the resource).

The HTTP rule that POST invalidates the cache is actually useful and  
it is very frustrating to develop a Web app when the browser doesn't  
invalidate the cache properly. If the app developer can't count on  
cache consistency working, (s)he'll have to break HTTP caching  
*altogether* by never GETting the same URI twice by appending salt  
that the server ignores. This would, of course, defeat any access- 
control caching as well, so driving app developers to do this would  
be bad.

OTOH, if you meant that the cache should be flagged stale for all  
subsequent GETs except access-control checks, then you'd effectively  
be special-casing access-control GETs on the HTTP library level  
instead of keeping a separate access control cache on the XHR level.  
I don't see how that would be better.

-- 
Henri Sivonen
hsivonen@iki.fi
http://hsivonen.iki.fi/

Received on Tuesday, 9 October 2007 11:15:31 UTC