Re: Feedback on Access Control

BTW, I understand the motivation for this now that OPTIONS is used,  
but you still have a clock sync problem.

Also, HTTP caches won't be able to exploit this. I'm thinking  
especially of HTTP accelerators (e.g., Akamai); OPTIONS traffic is  
going to create a lot of undesirable back-end communication for them,  
until they come up with a workaround. My main concern is that  
different intermediaries are going to come up with different  
strategies for caching OPTIONS results.


On 22/01/2008, at 8:59 PM, Anne van Kesteren wrote:

>> 3) The Method-Check-Expires header creates a secondary expiration  
>> mechanism, separate from the HTTP caching model. I'm not convinced  
>> of its utility (are there convincing use cases where the access  
>> control metadata has a significantly different lifetime from the  
>> GET response?), doing so adds complexity to implementations, and  
>> the interactions with HTTP caching aren't defined (e.g., what if  
>> the response expires before the metadata does? Vice versa?).
>>
>> Also, it seems to assume clock sync between the server and the  
>> client, which has been proven to be a bad thing to do.
>>
>> Overall, this mechanism doesn't seem very well thought out, and I'd  
>> recommend its removal.
>
> This cache is there to ensure that you don't have to do an  
> authorization request again and again, etc. (Remember that  
> authorization requests use the OPTIONS HTTP method.) It also uses  
> the Referer-Root and request URI as key.

--
Mark Nottingham       mnot@yahoo-inc.com

Received on Wednesday, 23 January 2008 21:18:23 UTC