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

Dave Kristol writes:
 > koen@win.tue.nl (Koen Holtman) wrote on Wed, 29 Nov 1995 13:38:25 +0100 (MET):
 >   > 
 >   > 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).
 > Well, I actually knew them better than you suspected, but not as well as I
 > should.  I, too, read the NCSA (1.3) code.  Anyway...
 > 
 >   [We discussed what happens if, in response to a POST request, a CGI
 >   issues a "local" redirect via a Location: header.  We agreed that the
 >   server should probably behave the same as if the user-agent made the
 >   redirected request.]
 > 
 > There is a problem with the behavior I have summarized, based on the
 > 22Nov95 HTTP/1.1 draft.  A user-agent is supposed to ask for user
 > confirmation of a redirected POST (9.3, under description of 302 Moved
 > Temporarily).  Obviously if the server handles the redirection
 > internally it isn't asking for confirmation.  Perhaps a server can/should
 > only handle internally GET and HEAD?
 > 
 > Dave Kristol
 > 
There's another problem.  Redirection is often used to control
caching, in that if the server wishes to respond to requests for 
a number of different URIs by sending the same resource, one of the few ways
to implement that behavior is to rely on redirection, so that all 
paths to the same returned resource ultimately go through the same request-URI.
This completely depends on the client to cache redirected requests
using the redirection-target URI as the key.

Although I think this is a pretty ugly kluge, it is actually one of
the few ways to prevent what I've come to think of as "doppelgangers"
(multiple copies of the same resource, under different URI's, some out
of date) in a cache, without resorting to disabling caching on those
resources altogether.  There are other potential solutions to this,
but they involve changes to the protocol, which don't seem to be
forthcoming (sigh).

--Shel Kaphan

Received on Thursday, 30 November 1995 14:34:10 UTC