- From: Anne van Kesteren <annevk@opera.com>
- Date: Mon, 04 Feb 2008 14:26:16 +0100
- To: "Thomas Roessler" <tlr@w3.org>, "Ian Hickson" <ian@hixie.ch>
- Cc: "WAF WG (public)" <public-appformats@w3.org>
On Thu, 31 Jan 2008 15:19:36 +0100, Thomas Roessler <tlr@w3.org> wrote: > 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). In what case would the origin comparison fail here? Resolving the path (and then appending a / if not present) does make more sense to me, but I can't think of a scenario where origin comparison would be needed after a path is resolved against a URI. I mean, what path can change the origin of said URI? > (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. -- Anne van Kesteren <http://annevankesteren.nl/> <http://www.opera.com/>
Received on Monday, 4 February 2008 13:22:51 UTC