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 [EMAIL PROTECTED]
