redirect model for non-GET requests (Re: OPTIONS and redirects (was: Re: Review of 22 Jan editor's draft))

On 2008-01-30 23:01:31 +0100, Anne van Kesteren wrote:

>>> - Why does the specification follow redirects upon OPTIONS?  If I
>>>   read RFC 2616 correctly, then redirects for HTTP methods other
>>>   than GET and HEAD shouldn't happen without user intervention.

> Euh. This is actually an acknowledged bug in HTTP and part of the HTTP 
> errata:

>   http://skrb.org/ietf/http_errata.html#saferedirect

> So we're good. I was already wondering why redirects on a safe
> method would be prohibited.

That actually makes sense for OPTIONS itself.  Thanks for pointing
it out.

So, re-reading the redirect processing again...  

I take it that "curent request URI" is a global variable; therefore,
the generic redirect steps will have side effects into "invoking"
chapters of the specification, including the one about cross-site
non-GET access requests.

That means that the result of a chain of redirects encountered in
response to an access request is translated into a redirect for the
originally intended non-GET request; neither the originally planned
request, nor any intermediate requests are placed:  instead, the
request is directly sent to the end point of the redirection chain.

Am I reading that correctly?

If so, that creates an inconsistency between HTTP semantics for
cross-site requests and any other HTTP requests that I, for one,
find worrisome.  (I have no issues with servers sending different
responses to cross-site requests -- the difference on the protocol
level is what makes me nervous.)

It would seem simpler and more consistent to not accept redirects in
response to an access request: If the access request's result is a
200 and the access check succeeds, then the originally planned
request is performed.  If the result of the originally planned
request is a redirect, report that back to the hosting specification
and let it deal with it in whatever way it deals with other
redirects.

Note that this would at the same time remove the current special
casing for cross-site requests that are redirected back to
same-origin requests.

If that's not acceptable, I'd like to understand what the motivation
for the current design is.

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

Received on Thursday, 31 January 2008 10:14:40 UTC