Re: Proposal for a way to avoid a round-trip on every POST when dealing with large numbers of URIs

On 2008-01-30 22:09:57 +0000, Ian Hickson wrote:

> When a 200 OK OPTIONS response (i.e. after following redirects)
> has this header, the path in the header is compared to the path
> of the 200 OK response itself. If the path in the header doesn't
> start with a slash, then add a slash at the start of the path. If
> the path in the header doesn't end with a slash, then add a slash
> to it. If the path, with the added slashes if any, is an exact
> prefix match for the URI of the 200 OK response itself, but is
> not an exact match for that URI, then the whole process of
> sending OPTIONS requests is repeated, with the URI consisting of
> the same scheme, host, and port as the 200 OK response, and the
> path given in the header, without the added slash at the end if
> one was added.

I'd propose one material (but not very deep) change here: Define
that header to hold a URI reference which - if relative - is
resolved with the request's URI as the base.  Then, perform an
origin comparison between that URI and the request URI; then the
remaining magic as currently specified (except for the "prepend a
slash" part which is now redundant).

(I'm assuming here that "the URI of the 200 OK response" is meant to
be the request URI of the OPTIONS request that caused this
response.)

Rationale: This permits (a) pinning things to one particular host
name on the target side in case of interestingly configured virtual
hosting environments (which might ignore Host headers), and (b)
might open the door for later extensions if we'd ever decide that
delegating authority across origins is a good idea.

Regards,
-- 
Thomas Roessler, W3C  <tlr@w3.org>

Received on Thursday, 31 January 2008 14:19:52 UTC