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

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.

/ Jonas