Jim Killian asked on www-talk what a client should do on receiving a 302
redirect from a POST operation. Should the client repost the data to
the new location (ie, 302 means the script has moved) or GET the new
Location (ie 302 means the result of POSTing is somewhere else)?
Analysis
--------
Currently many CGI programs return 302 from GET operations -
imagemapping programs for example) and it seems reasonable to allow POST
CGI programs to also specify a relocated result.
On the other hand, many pages have moved in the last 5 years and a 302
response is often used to indicate this: why should CGI scripts be any
different?
It strikes me that both of these situations should be catered for, and
the source of the confusion is using the same response code for both
situations. The language in the HTTP draft seems to recognise there is
a problem but punt resolving this onto the user.
The HTTP/1.0 draft <draft-ietf-http-v10-spec-02.txt> states:
If the 302 status code is received in response to a request using the
POST method, the user agent must not automatically redirect the
request unless it can be confirmed by the user, since this might
change the conditions under which the request was issued.
There are two ways that I see to resolve this:
A) Disambiguate two uses of 302 with an additional header
---------------------------------------------------------
So we have established long usage of 302 for both situations, meaning
that changing to a different response code for one of them might be a
problem.
One solution is the Allow: HTTP header. Although this is an entity
header not a response header, so I may get criticised for this.
To say a POST CGI has moved:
HTTP/1.0 302 Over there
Location: http://foo.edu/bar
Allow: POST
To say that the result of a POST operation is elsewhere:
HTTP/1.0 302 Over there
Location: http://bar.edu/foo.html
Allow: GET
B.1 Ah but...
-------------
OK so far, but here is a problem.
Suppose we have a GET CGI script called thing and we do this:
GET /cgi-bin/thing?a=x&b=y HTTP/1.0
and we get back
HTTP/1.0 302 Over there
Location: http://bar.edu/foo
Allow: GET
does that mean we should try http://bar.edu/foo?a=x&b=y or does it mean
the CGI script has moved?
This could be resolved in the following way. If the CGI program wishes
to return a redirected result, it issues a Location server directive
which (in the case of a full URL, see [q] causes the server to generate
a 302 status code, a Location header and an Allow: GET header as above.
If the CGI program has moved (and may no longer be there to generate
redirects) then this is indicated in some server-specific configuration file
such that the server should synthesise a new Location header from the new
URL and the original search string:
HTTP/1.0 302 Over there
Location: http://bar.edu/foo?a=x&b=y
Allow: GET
B) Use different response codes
-------------------------------
302 should explicitly state that form data or, rather, search strings
should not be used when resolving a 302 redirect. 302 means that the
result of the operation has moved (temporarily).
So if a POST operation returns a 302, the client should do a GET. If
a GET operation such as
GET /cgi-bin/thing?a=x&b=y HTTP/1.0
returns a 302, the client should do a GET (without appending any
search string)
Another unused response code should be defined to indicate a script has moved:
305 Resend data
The requested resource resides temporarily under a different URL. The
client should resend the data to the URL given in the Location header,
using the original method (POST or GET). In the case of GET, the
original search string, if any, should be appended to the URL in the
Location header.Since the redirection may be altered on occasion, the
client should continue to use the Request-URI for future requests.
The URL must be given by the Location field in the response.
Comments?
---------------------------------------------------------------------
[q] <URL:http://hoohoo.ncsa.uiuc.edu/cgi/out.html> which states:
If the argument to this is a URL, the server will issue a redirect to
the client.
If the argument to this is a virtual path, the server will retrieve
the document specified as if the client had requested that document
originally. ? directives will work in here, but # directives must be
redirected back to the client.
-- Chris Lilley, Technical Author +-------------------------------------------------------------------+ | Manchester and North HPC Training & Education Centre | +-------------------------------------------------------------------+ | Computer Graphics Unit, Email: Chris.Lilley@mcc.ac.uk | | Manchester Computing Centre, Voice: +44 161 275 6045 | | Oxford Road, Manchester, UK. Fax: +44 161 275 6040 | | M13 9PL BioMOO: ChrisL | | URI: http://info.mcc.ac.uk/CGU/staff/lilley/lilley.html | +-------------------------------------------------------------------+