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/