On 24/01/2008, at 10:30 AM, Anne van Kesteren wrote:
On Wed, 23 Jan 2008 22:17:36 +0100, Mark Nottingham <[EMAIL PROTECTED]
> wrote:
BTW, I understand the motivation for this now that OPTIONS is used,
but you still have a clock sync problem.
Race conditions are already covered by the specification. Authors
are advised to check to the Referer-Root header to prevent such
issues from occuring.
I didn't say it was a race condition, Anne. Consider a naive
implementation that use a local clock to determine when the policy
expires; e.g., if it expires at 1pm, and the local clock is
incorrectly indicating that it's 12:30pm, the implementation will see
an expired policy and be unable to fetch a valid one. This can be
avoided by using an offset from the Date header, but you need to
specify that.
Another (probably better, based upon experience with caching) approach
would be to use a delta rather than a http-date.
BTW, regarding race conditions -- you're effectively requiring authors
to check referer-root to be really secure. Why is it unacceptable to
use this as the primary mechanism again?
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.
OPTIONS is part of the traffic that is non-static. I'm not sure how
much you can optimize that by using HTTP accelerators. Again though,
the idea is that the request reaches the server and that the server
specifies an HTTP-date indicating how long the policy is valid.
You're making the assumption that per-request OPTIONS has to be part
of the solution. Using a well-known location and using the Referrer-
root alone both interact well with caches.
--
Mark Nottingham [EMAIL PROTECTED]
