W3C home > Mailing lists > Public > public-appformats@w3.org > January 2008

Re: Feedback on Access Control

From: Mark Nottingham <mnot@yahoo-inc.com>
Date: Thu, 24 Jan 2008 08:17:36 +1100
Cc: "WAF WG (public)" <public-appformats@w3.org>
Message-Id: <967EC445-010F-4C12-858A-32BB0D38777F@yahoo-inc.com>
To: Anne van Kesteren <annevk@opera.com>

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:56:21 UTC