W3C home > Mailing lists > Public > www-talk@w3.org > September to October 1995

Re: Browser Interpretation of Location: Header

From: lilley <lilley@afs.mcc.ac.uk>
Date: Fri, 1 Sep 1995 11:43:31 +0100 (BST)
Message-Id: <2277.9509011043@afs.mcc.ac.uk>
To: jkillian@access.digex.net (Jim Killian)
Cc: www-talk@w3.org, http-wg@cuckoo.hpl.hp.com

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)?


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

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

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.


[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 06:43:54 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:32:57 UTC