Reading your reply, I get the feeling that you do not know the exact
semantics of a Location: <absolute URL> cgi-header. The description
on http://hoohoo.ncsa.uiuc.edu/cgi/out.html is indeed a bit vague
about this (I determined the semantics myself by reading the NCSA 1.2
source).
Qouting the description:
|* Location
|
| This is used to specify to the server that you are returning a
| reference to a document rather than an actual document.
|
| If the argument to this is a URL, the server will issue a redirect
| to the client.
What this means is that the server will send a response with a 302
status code to the client with the Location cgi-header given as one of
the response headers.
What the client does next is defined by HTTP 1.x. Basically, if a
client gets a 302 status on a request, it must repeat the same request
(with the same method) on the URI redirected to.
Thus, with this use of Location, your T2 script will get a POST
request with exactly same content as sent originally to T1.
| 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.
Hm, there are lots of ambiguities in the above sentence. I guess it
was not written with the possibility of POSTs in mind.
| ? directives will work in here, but # directives must
| be redirected back to the client.
Dave Kristol:
>
>[email protected] (Koen Holtman) wrote:
> [...]
> > That said, I agree with you that local redirection processing, if you
> > do want to provide it at all, should borrow semantics from user agent
> > redirection processing.
>
>Yes, 303 looks useful, except that it requires another request. So maybe
>having a new header that mimics 303 would be good. But the question of
>which method to use remains.
If you want to mimic 303, you should always use the GET method.
> > >2) If the method should indeed be POST, where does the content come from?
> > >(POST requires Content-Type and Content-Length headers.)
> >
> > The content should be identical to the content that was offered to T1.
>
>I think that's debatable, at least.
T2 will get identical content if the redirection had been handled by
the user agent. If you have decided that you want to mimic that, there
is no room for debate on 2) anymore.
[....]
> > For user agent processed redirection, you can already specify the
> > method by using either 302 or 303 in the Status: cgi-header (at least
> > under NCSA 1.2 you could, I don't know if this is a universal CGI
> > feature).
>I don't see that in the current CGI spec. You can specify status code
>and comment, but not method.
You specify the method indirectly, by using either 302 or 303.
By specifying a 302 status, you cause the user agent to use the POST
method again. This is what the script would output:
--- start of output ---
Status: 302 Moved Temporarily
Location: http://blah/bin/blebber
--- end of output ---
By specifying a 303 status, you cause a HTTP 1.1 user agent to switch
to the GET method. This is what the script would output:
--- start of output ---
Status: 303 See other
Location: http://blah/bin/blebber
--- end of output ---
I hope this clears matters up a bit. In my opinion, it would be best
to make the Location header obsolete in future CGI specifications, and
to define a new cgi-header
Include: <virtual path>
that causes the server to emulate a GET request, and maybe also
Moved-temporarily: <absolute URL>
See-other: <absolute URL>
as short hands for a Status 30[23] header followed by a Location header.
>Dave Kristol
Koen.