Re: what's a CGI to do?...

Dave Kristol:
>
>A user of my server software writes:
>
>	1.  I have a method=post form whose action is T1, a cgi script.
>	2.  T1 reads the post data, does some stuff, and then emits
>		"location: /T2" back to the server.  T2 is a script.
>	3.  T2 seems to get the POST information in its environment,
>		even though T1 already read it.
>	4.  If T2 tries to read the POST information, it fails (of course).
>	
>	This doesn't happen with NCSA [httpd].

I don't quite get how exactly T2 fails (does the it get METHOD=POST
but no form contents from the server on its standard input?), but that
does not really matter to what I am going to say below.

>Let me paraphrase the problem.  NCSA httpd (and my server) allow a CGI
>to give a "local" Location: header that causes the server to process
>the resulting redirection without first sending anything to the
>client.

I never liked this feature of the Location: cgi-header, because local
processing of redirection will _not_ in general produce the same end
result as processing of redirection by the user agent would.

In particular, with local processing the user agent at the other side
will, when displaying the result, show the URL of T1 in its location
window (and use T1 for hotlists etc.).  But with user agent
redirection the URL shown is most likely to be that of T2.

So local redirection processing is not just a transparent
optimization: the Location header lets you do two sublty different
things.

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.

The HTTP 1.1 draft actually defines 2 forms of dynamic user agent
redirection: 302 Moved Temporarily and 303 See Other.  HTTP 1.0 only
has 302, so Location should presumably emulate 302 semantics.

(By the way, 302 semantics is almost never useful for scripts that
handle POSTs.  Server authors may want to consider adding a second
kind of Location: header that borrows semantics from 303 redirection.)

>Beyond that I think the "correct" behavior is undefined.  So I'm trying
>to define it.
>
>Some questions that come up are:

I'll answer these question working from the 302 semantics in the 1.1
draft spec.

>1) What should the method be for the redirected request?

POST (or whatever other method T1 got).

>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.

>3) Should there be a way for a CGI to specify the method to use with a
>redirection?  If yes, only for local URLs, or for full ones, too?

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

For locally processed redirection, see my comments above.

>4) What environment should be passed to a CGI (like T2 above) that is
>reached via a redirection?
>(Here again, I think it should be the same as if a full URL got sent
>back to the client, and the client made a new request.)

I agree.

>Dave Kristol

Koen.

Received on Tuesday, 28 November 1995 14:41:23 UTC