W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2009

Scope of redirection

From: Mark Nottingham <mnot@mnot.net>
Date: Wed, 3 Jun 2009 11:20:32 +1000
Message-Id: <65CF91C2-B298-4D78-B785-7791F2636466@mnot.net>
To: HTTP Working Group <ietf-http-wg@w3.org>
In discussing how redirects are handled in CORS with a few of the  
folks there, it's become apparent that 2616 is perhaps a little too  
silent about the scope of a redirection.

In other words, people are interpreting a redirect to mean "only for  
this request", "for all requests with this method to this URI", or  
"for all requests to this URI, no matter what the method."

For example, can a client infer that getting a 301 in response to an  
OPTIONS request means that a future GET will be redirected to the same  
URI?

301 says
> The requested resource has been assigned a new permanent URI and any
>    future references to this resource SHOULD use one of the returned
>    URIs.
Similarly, 302 says
> The requested resource resides temporarily under a different URI.
>    Since the redirection might be altered on occasion, the client  
> SHOULD
>    continue to use the Request-URI for future requests.
Finally, 307 says
>    The requested resource resides temporarily under a different URI.
>    Since the redirection MAY be altered on occasion, the client SHOULD
>    continue to use the Request-URI for future requests.  This response
>    is only cacheable if indicated by a Cache-Control or Expires header
>    field.


Note the "requested resource" language. From this, I think it's pretty  
clear that 301, 302 and 307 apply to all methods (i.e., they're scoped  
to the resource).

Proposal:

* Add a qualifying clause to each of 301, 302 and 307 to clarify  
(e.g., "(regardless of request method"), and
* Clarify that 302 and 307 do not require future requests to use the  
original request-URI during the period when the redirection response  
is fresh in cache (if any).


--
Mark Nottingham     http://www.mnot.net/
Received on Wednesday, 3 June 2009 01:21:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:03 GMT