Re: [cors] Redirects

On Thu, 23 Apr 2009 12:35:30 +0200, Jonas Sicking <jonas@sicking.cc> wrote:
> I think this is important since we should in general try to follow the
> letter and spirit of the HTTP spec.

I tend to agree. I've requested review of the HTTP WG in the past and mnot  
has just done that again to make sure they're aware of our work. Though  
maybe it requires going to Last Call before we get better comments.


> Here I was referring to the HTTP spec. OPTIONS requests are intended
> to get the capabilities for a given URI. A 303 means that you should
> issue a GET request to another URI to get the response for the given
> URI. Does this mean that you are expected to get a capabilities
> response from a GET request? This seems strange to me.

I think 303 is not intended for OPTIONS requests.


> So my understanding is that 303 unambiguously means that action has
> been taken for the current request, but that the resource returned
> should be fetched from another URI. Fetching resources is done using
> GET, thus a new GET request is created.

Ok, I don't think it matters much either way what it is for.


>>> A) How is 301 different from 302. For example can the UA cache the
>>> fact that a redirect is occuring in addition to treating it as a 302?
>>
>> Yes.
>
> Where does it say this in the HTTP spec? And what does this mean for a
> POST or DELETE request?

"and any future references to this resource SHOULD use one of the returned  
URIs"

I don't think it matters much what it means for POST or DELETE requests  
since browsers universally change the request method. I believe changing  
that at this point would break sites.


>>> B) If you get a 303 response from a OPTIONS request, are you allowed
>>> to make an OPTIONS request to the redirected URI. Would it make sense
>>> to?
>>
>> This is not allowed by CORS.
>
> My question was in the context of what the HTTP spec says.
>
> Why does the CORS spec treat 303 different from 302 and 301 here?

Because 301 and 302 preserve the method at least for safe methods  
(including OPTIONS).


>>> C) If the answer is 'no' to the question above, if you make an OPTIONS
>>> request to uri X, which 303 redirects to uri Y. Should the UA then
>>> make a GET request to uri Y and assume that the response to that
>>> describes the capabilities of Y? In other words, does a 303 response
>>> to an OPTIONS request basically mean "The resource at Y describes my
>>> capabilities"?
>>
>> It doesn't matter, the redirect is prohibited.
>
> Again, the question was asked in the context of what HTTP says.
>
> CORS currently answer 'yes' to question B, so question C doesn't apply.

CORS currently says 'no' to question B.


>>> D) If you get a 307 response from an OPTIONS request to a URI, does it
>>> make sense to assume that a 307 would be returned for other methods,
>>> such as a POST, DELETE or XMYMETHOD request?
>>
>> I don't understand this question. If you follow the 307 (only possible  
>> if it
>> opts in itself) the final URI still has to say whether it allows
>> POST/DELETE/XMYMETHOD.
>
> (sorry to repeat myself) This question was intended as what does the
> HTTP spec say on the matter.
>
> The CORS spec currently assumes two things:
>
> * If a CGI handling requests to URI X receives a OPTIONS request and
> 307 redirects it to URI Y, it will also do the same for a DELETE
> request to URI [X] and 307 redirect it to URI Y.

I think I see what you're saying, but that's not what CORS assumes. The  
CORS protocol does not assume anything per se. Note that the server needs  
to opt in for the redirect explicitly and can refuse to do so.


> * It also assumes that the DELETE request will have no side effects.
> I.e. it assumes that the CGI will take no action upon receiving the
> DELETE request other than returning the 307 response.

The DELETE request is not made to URI X.


> Are this a valid assumption according to HTTP spec? My gut feeling is
> that they are not, at least not the first bullet.

I agree, but your assumptions do not match the CORS specification.


> A CGI that returns a 307 for a OPTIONS request, but not for a DELETE
> request would behave differently for a XMLHttpRequest from same-origin
> than for different-origin. This seems like a bad thing to me, unless
> such a CGI request is violating the letter or spirit of the HTTP spec,
> in which case I think it is ok to blame the CGI author.

There are tons of  things that behave differently for same-origin and  
cross-origin requests. That's the whole reason of having CORS...


> 1. It treats 301/302 redirects as 307 redirects. This is good
> according to the HTTP spec, however it goes against how UAs handle 302
> redirects everywhere else. IMHO we should treat 301/302 as 303 (with
> the exception of caching) since that is what UAs normally do.

UAs handle 301 and 302 as 307 for safe HTTP methods. I.e. HEAD, GET, and  
OPTIONS, which are the only one that matter for CORS. (HTTP has errata on  
that mentioning HEAD and GET for 301/302 is wrong.)


> 2. It assumes that a 307 response to an OPTIONS request also means
> that the server will respond with a 307 response to a
> DELETE/POST/XMYMETHOD request. It also assumes that it'll *just*
> respond with that and take no other actions.

It does not.


> 3. It treats a 303 response to an actual request as an error. If we
> support any form of redirects I think this is the most obvious and
> simple one to support. A 303 response to a POST means that the POST
> has been processed and that the result can be fetched at a different
> URI. This is probably the most common type of redirects that we'll run
> into when it comes to preflighted requests since this is the proper
> way to deal with responses to POST requests. It's also one we can do
> safely assuming no custom headers have been added.

The most common? I believe hardly any site uses 303 currently. Anyway,  
since custom headers etc. _can_ be added this does not seem like the most  
obvious and simple one to support. I also do not see <form> scenarios  
directly map to the kind of things you'd expect CORS to be used for.


> So my suggested actions are as follows:
>
> Either make all redirects of the preflight request an error, or get
> review from the IETF or someone that knows HTTP better to make sure
> that our treatment of them are correct (specifically the answers to
> questions B-D with regards to the HTTP spec). It is clear to me that
> no one with sufficient knowledge of HTTP has reviewed the spec
> currently.

You claim to not understand the HTTP spec so I'm not sure how this is  
clear to you, but review from the HTTP WG has been requested and I'm sure  
we'll do it again when we go to Last Call.


> Either add support for 303 (and thus 301/302) redirects of the
> response to the actual request when the list of custom headers is
> empty, or drop support for all redirects when making non-simple
> requests.

It seems better to be consistent and not support redirects here at all.


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Thursday, 23 April 2009 11:59:20 UTC