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

While the working group was wasting time arguing over the precise wording 
of the ex post facto requirements, something to which I would like to 
formally object but can't, since formal objections in the W3C process are 
only allowed when the group publishes something and the whole point of my 
objection is that these ridiculous discussions are preventing progress 
towards publication, I discussed a proposal with Anne and Jonas which I 
would like to put forward here.

Problem: Some HTTP-based protocols, like AtomPub, require the use of a 
large number of distinct URIs. For example, adding a tag or category to a 
series of posts on a blog using AtomPub requires one non-GET request per 
blog post. While this is prohibitively expensive anyway when done from a 
high-latency network like GSM or EDGE, it is still somewhat painful to 
require two round trips per non-GET request in cases like this even on 
low-latency high-bandwidth connections, and therefore deserves further 
consideration.

Proposed Solution: The proposed solution allows one new optional header 
for OPTIONS responses. The header contains a path.

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.

Otherwise, if the 200 OK OPTIONS response has this header, but the path in 
the header, with a slash added at the start if it doesn't have one 
already, is not an exact match for the path of the 200 OK OPTIONS response 
itself, then apply the generic network error steps. (The header can only 
point to ancestors of the current path.)

Otherwise, if the 200 OK OPTIONS response has this header, and the path in 
the header, with a slash added at the start if it doesn't have one 
already, is an exact match for the URI of the 200 OK OPTIONS response 
itself, then continue as currently specified, except that the 
Access-Control allow and deny rights must be applied to all paths that 
have the path of this 200 OK response, with a trailing slash added if not 
already present, as a prefix, and that, if sent, the non-GET request must 
be sent to the URI of the first 200 OK response for this invocation of the 
Cross-site Non-GET Access Request algorithm (not to the final location of 
the policy).

Otherwise, the 200 OK OPTIONS response doesn't have this header. If this 
is the first 200 OK OPTIONS response for this invocation of the Cross-site 
Non-GET Access Request algorithm, then continue as currently specified. 
Otherwise, apply the generic network error steps. (Once the header is 
specified, it must be specified at all points in the chain.)

When a 200 OK OPTIONS response has this header with a path that doesn't 
match its own URI (as defined above), any Access-Control headers, 
<?access-control?> PIs, and Method-Check-Max-Age headers are ignored.


Possible names for the HTTP header:

   Access-Control-Policy-Path
   Method-Check-Policy-Path
   Method-Check-Redirect

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 30 January 2008 22:10:15 UTC