Re: HTTP redirects: MUST follow?

2009/4/8 Florent Georges wrote:

>  But from the top of my head, I think the HTTP spec carefully
> use MUST, SHOULD, MUST NOT, etc. to qualify whether a client
> should follow or not a redirect.  I think for instance that a
> client cannot follow a redirect in response to a POST or a PUT,
> if I am right.

  FYI I went through the HTTP/1.1 spec to have a look at
redirects: http://tools.ietf.org/html/rfc2616#section-10.3.  Here
is an adaptation to XProc of what's in there (first some notes in
pseudo algorithm notation, then in plain text):

    if method != (GET, HEAD)
        no redirect at all (unless 303: even if POST, GET is used
        to follow the redirect)

    if 300
        if Location header -> SHOULD follow it
        step MAY automtically follow one URI
        300 MAY be returned

    if 301 302 303 307
        if Location header -> MUST follow it
          (any header to add redirect info to the final response?)
        else it is returned as is

    if 304
        MUST NOT follow: 304 is returned

    if 305
        Location MUST be there
        step MUST send request again, through the proxy in Location

    if 306
        not sure, think best is return as is (or throw an error?)

  Redirects can be followed only if the method is GET or HEAD,
except for 303 (in this case, a new GET request is automatically
sent to retrieve the redirected to resource if any, even if the
initial request used another method.)

  If status is 300, there can be a Location header, and a list of
URIs may be in the response body.  If Location is there, this URI
SHOULD be followed.  But another URI from the list MAY also be
used, of the 300 response MAY also be returned as is.

  If status is 301, 302, 303 or 307, there can be a Lcoation
header.  If it is, this URI MUST be followed, if it is not, the
3xx response is returned as is.  I am not sure we should include
(or allow on implementation to include) the redirect info in the
response (for instance in c:response.)  I guess allowing that
could be useful.

  If status is 304, any other request MUST NOT be followed (304
is a response to a conditional request, when the condition is not
met, so the user explicitely said she does not want anything in
this case.)

  If status is 305, there MUST be a Location header (what is
not?)  This URI MUST be used as a proxy URI through which the
step MUST issue the initial request again.

  Status 306 is not used.  Either return as is or throw an error,
not sure which is better.

  I think this is clear the current sentence:

    The p:http-request step must follow redirect requests (3xx
    status codes) if they are returned by the server.

is confusing against the HTTP spec.  The rules above are just an
abstract of the rules in HTTP/1.1, sometimes stronger (like MUST
follow Location header if present...)

  Also, I think an attribute @follow-redirect (by default true)
would be useful on c:request, so the user can always explicitely
disable redirects and handle them herself.

  Hope that helps,

-- 
Florent Georges
http://www.fgeorges.org/

Received on Wednesday, 8 April 2009 10:35:22 UTC