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

Re: CGI scripts / Location header

From: <jkillian@access.digex.net>
Date: Fri, 13 Oct 1995 09:32:13 +0000
Message-Id: <199510131632.MAA11977@access5.digex.net>
To: www-talk@www0.cern.ch, Daniel DuBois <ddubois@rafiki.spyglass.com>

One thing that's being lost here is that the response from the CGI 
program and the GET requests are separate operations by the browser.  
Your questions assumes (or implies) that it is treated as a "single" 
operation, of which you have total control.  You don't!  Specifying the 
Location header merely instructed the server to return a redirect 
that point, you (i.e., your CGI program) is "out of the loop".  
If you actually want such control, your CGI program should at least check
for existence first and return a 500 on Not Found, else, issue the
Location header.  Of course, if you're industrious, you could also provide a
mechanism to contact the URL yourself and feed the contents directly back
to the user.  Most people avoid this because the Location header seems
convenient.  But...

This whole concept of redirects from CGI only works "reliably" for 
GET requests, not POSTs!  While this may not apply in your case (you 
didn't specify many specifics), others may not make this necessary

This technique is usually used to return some static response after 
successful forms submission, for example.  Clever, but you're really 
subverting the HTTP specification, which is why POST is problematic.

If you try this w/ POST, you'll find some browsers read this as "oh, 
the POST to X failed w/ a redirect, so I'll POST(!) to the new
URL".  Boom!  Your error log shows something like "POST 
to http://.../page.html failed".  Of course it did, that was not your 
intention.  Where it works seems to be more a case of the vendor 
being aware of this bastarization of the spec and taking preemptive 
action.  As I recall, Spry or maybe NCSA Mosaic had this problem.

The specification is somewhat fuzzy on all this, but the fairest and most 
reliable interpretation is to assume a redirect is a continuation of the "same 
operation", but just to another URL (e.g., it moved).  Changing the "context" of
the operation from CGI to HTML, for example, is not the intent and if it
works, should be considered coincidental.


>>> Jim

> Date:          Wed, 11 Oct 1995 11:14:04 -0500
> To:            www-talk@www0.cern.ch
> From:          Daniel DuBois <ddubois@rafiki.spyglass.com>
> Subject:       CGI scripts / Location header

> Scenario:  User requests a URL that points to an existant CGI script.  CGI
> script returns a "Location: localfile.html" header, indicating a
> 'server-side' redirect, and this file doesn't exist.
> Is it proper to send a 404 Not Found message?  The URL is found, but the
> output of the CGI script isn't.  Is it better to send a 500 Internal Error
> message?
> Does it really matter?
> -----
> Dan DuBois, Software Animal             http://www.spyglass.com/~ddubois/
> 		I absolutely do not speak for Spyglass.

Jim Killian
Transphere Interactive
Received on Friday, 13 October 1995 13:27:19 UTC

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