Re: a test result

>> If you generate a Location header, the server forces 302 status.
>
>Yes. That is what outputting the string Location: is supposed to do; it
>lets you issue a redirect from a program, without the hassle of creating
>all your own headers yourself.
>
>> Sounds like a patch is needed.  (maybe there are newer versions that
>> already have this fixed?)
>
>No, and no. Suppose this was patched. How would you ever issue a redirect?
>You would have to generate all your own headers. Imagemap would stop
>working. Etc.

No and no yourself.  If you want to issue a redirect, you output a Location
header without a Status header, and the server can fill in the 302 on the
status line.  But if you *explicitly* issue a Status line that asks for a
200 response (or a 301 response or whatever) and the server ignores that
directive, the server is broken.

>So here is the impossible program. As you can see it is not complicated:
[...]
>Save this out into your cgi-bin as nph-loc, telnet to your server and try it:
[...]
>HTTP 200 Hunky dory
>Server: NCSA 1.3 via nph script
>Location: http://some/location
>MIME-version: 1.0
>Content-type: text/html
[...]
>So, you have a location header and a 200 status. The client will of
>course do nothing with the Location header, because the status is not
>300 series.
>
>Happy now?  ;-)

Not in the slightest.  Your script is broken, too -- that's not a valid
Server: header, you're missing a Date: line, and the status line should
read 'HTTP/1.0 200 OK' [HTTP hasn't reached version 200 yet.  ;)].  I'm not
pointing out these nits to be a bastard; I'm pointing them out to
illustrate that it is unreasonable to expect CGI authors to suddenly
abandon the CGI spec, resort to nph scripts, and generate full and correct
HTTP headers....just to get around a server bug.

I'll say it again: a 'directive' is an _authoritative_ instruction.  The
server has no choice but to obey.  A server that ignores a Status directive
because a Location directive came with it is too clever by half.  Shel is
right.

It sounds like several of the respondants in this thread did not read the
parent thread, in which it was explained that under the new HTTP/1.0 draft,
a Location header should be sent with any 2xx response to identify "the URL
needed to retrieve that same resource again..."  In other words, the new
spec requires a 200 OK status to include a Location header.  If the server
unilaterally changes the status line to 302 whenever a location header
appears, then it is not conforming to the spec -- for which it should be
forgiven since the spec has changed.  However, servers should never ignore
directives, and that hasn't changed.

Marc Hedlund <hedlund@best.com>

Received on Wednesday, 9 August 1995 14:27:46 UTC