- From: lilley <lilley@afs.mcc.ac.uk>
- Date: Fri, 1 Sep 1995 11:43:31 +0100 (BST)
- To: Jim Killian <jkillian@access.digex.net>
- Cc: www-talk@w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Problem ------- 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 | +-------------------------------------------------------------------+
Received on Friday, 1 September 1995 03:48:49 UTC