Location header question

[G*rd*n]

I have been using the HTTP "Location" reponse header to direct
a symbolic request to a CGI program to an actual URL/file. For
example, let us suppose the CGI program's table indicates
xyz -> /this/that/the.other.thing.html, then redirect.cgi?xyz
results in the page /this/that... being sent. redirect.cgi
is usually in another directory than the page it is to supply.
This works fine as far as it goes.

A problem arises when the actual URL contains, for example,
image sources in its own directory. The file names are not
sought relative to the current URL (apparently) -- the one
supplied by the "Location:" header -- but (perhaps?) to the
previous URL. So the images can't be found and either a
blank or an error icon results, depending on the browser.
The browser in this case is either a recent Mozilla or
Firefox browser. I have not tried this with IE which under
interdiction in the client's office anyway.

The HTTP 1.1 specification says,

14.30 Location

The Location response-header field is used to redirect the
recipient to a location other than the Request-URI for
completion of the request or identification of a new resource.
For 201 (Created) responses, the Location is that of the
new resource which was created by the request. For 3xx
responses, the location SHOULD indicate the server's preferred
URI for automatic redirection to the resource. The field
value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

An example is:

Location: http://www.w3.org/pub/WWW/People.html

My usage (in the CGI program) has been to send the Location
response, e.g. "Location: /this/that/the.other.thing.html" in
response to "redirector.cgi?xyz" coming from an HREF. I
notice the example has the full site name. I would prefer
to avoid this since the names of the sites involved might
change from time to time, necessitating the change of
configuration files and the checking thereof. For the time
being I can assume the location target will be on the same
site as the CGI.

It seems to me that the specification implies that, once
the browser has begun reading the page, it should use its
virtual path (/this/that/) as a prefix for any relative
src or href targets in the file. But maybe I'm doing something
wrong, or misunderstanding the specification. Your comments
or ideas would be appreciated.

Clearly, there are schemes by which this problem can be
solved, such as reading the target page and rewriting the
href and src targets, but I would prefer not to go to all
that error-inviting trouble and just feed the location if
I can (and get the browser to read the relative links
correctly).

[Philip Ronan]

"G*rd*n" wrote:

The HTTP 1.1 specification says,

14.30 Location

... The field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI

My usage (in the CGI program) has been to send the Location
response, e.g. "Location: /this/that/the.other.thing.html" in
response to "redirector.cgi?xyz" coming from an HREF. I
notice the example has the full site name. I would prefer
to avoid this since the names of the sites involved might
change from time to time

So you realize that a partial URL is invalid content for a Location header,
but you still think you should carry on this way? This is just laziness on
your part.

I'm not aware of a single server scripting language that doesn't allow you
to find out the host name of the domain where the script is being executed.
(In PHP, fpr example, you can use $_SERVER["HTTP_HOST"]).

You've made a good start by reading the HTTP specification. Now try reading
the documentation of your server scripting language.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[G*rd*n]

> "G*rd*n" wrote:

The HTTP 1.1 specification says,

14.30 Location

... The field value consists of a single absolute URI.

Location = "Location" ":" absoluteURI
My usage (in the CGI program) has been to send the Location
response, e.g. "Location: /this/that/the.other.thing.html" in
response to "redirector.cgi?xyz" coming from an HREF. I
notice the example has the full site name. I would prefer
to avoid this since the names of the sites involved might
change from time to time

Philip Ronan <in*****@invalid.invalid>: So you realize that a partial URL is invalid content for a Location header,
but you still think you should carry on this way? This is just laziness on
your part.

Laziness is supposed to be a virtue in programmers. I have
managed some enthusiastic programmers in the past and they
can get you in a _lot_ of trouble, although not in as much
trouble as enthusiastic lawyers.

However, laziness notwithstanding, I do need stuff to work.
Scripting is not a problem; the problem is my too-lazy guess
about what I could get away with in using the Location header.
I suppose the relative addresses I supplied should not have
worked at all. In any case, I will concoct absolute URIs as
defined in the HTTP specs and see if that works.

Thanks for your help.

I'm not aware of a single server scripting language that doesn't allow you
to find out the host name of the domain where the script is being executed.
(In PHP, fpr example, you can use $_SERVER["HTTP_HOST"]).

You've made a good start by reading the HTTP specification. Now try reading
the documentation of your server scripting language.

--
phil [dot] ronan @ virgin [dot] net
http://vzone.virgin.net/phil.ronan/

[Nick Kew]

Philip Ronan wrote:

My usage (in the CGI program) has been to send the Location
response, e.g. "Location: /this/that/the.other.thing.html" in
response to "redirector.cgi?xyz" coming from an HREF. I
notice the example has the full site name. I would prefer
to avoid this since the names of the sites involved might
change from time to time

So you realize that a partial URL is invalid content for a Location header,

HTTP Location header, yes.

CGI Location header is different: there's no requirement to send the
full URL.

Confusing? Exactly:-)

--
Nick Kew

[David Dorward]

Nick Kew wrote:

CGI Location header is different: there's no requirement to send the
full URL.

Why? Does the CGI spec mandate munging of the header to an absolute URL? Do
the common CGI libraries do the munging for you?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is

[G*rd*n]

> >>My usage (in the CGI program) has been to send the Location

response, e.g. "Location: /this/that/the.other.thing.html" in
response to "redirector.cgi?xyz" coming from an HREF. I
notice the example has the full site name. I would prefer
to avoid this since the names of the sites involved might
change from time to time

Philip Ronan wrote: So you realize that a partial URL is invalid content for a Location header,

Nick Kew <ni**@asgard.webthing.com>: HTTP Location header, yes.

CGI Location header is different: there's no requirement to send the
full URL.

Confusing? Exactly:-)

According to http://cgi-spec.golux.com/issues-120-detailed.html:

# The "Location" header field and relative URIs

The Location response header field description doesn't conform to current practice as relative URLs
seem to be acceptable for redirects. (hmmm... I wonder if this is an HTTP/1.1 issue also). This
description limits the Location to use with GET/HEAD which is in conflict with HTTP/1.1.

[a reply:] Here's a grey area. The specification in this draft does not match that in the NCSA
documentation, which provides for limited local redirects internal to the server (they don't get
sent back to the client as a 'real' redirect). So that's a break with current practice that needs to
be fixed. On the other hand, the grey area starts forming because this is overloading an HTTP header
field (Location, which takes only an absoluteURI) with a CGI field that has different semantics
(Location, which can take an absoluteURI or a server-local URI [with some restrictions]). I'm not
sure how to handle this; perhaps define the CGI semantics but make a note that this is also the name
of an HTTP field with differing ones? Suggestions? I've discussed the overloading issue briefly with
Roy Fielding, and he remarked that it should be safe to avoid this sort of collision by naming CGI
header fields with a "CGI-" prefix.

Status:
Open

According to a great number of other pages purporting to tell
how to use the Location header from CGI, it's the same as the
HTTP Location header. W3C's page on CGI points to the above.

[Alan J. Flavell]

On Fri, 9 Dec 2005, G*rd*n wrote:

Philip Ronan <in*****@invalid.invalid>:

So you realize that a partial URL is invalid content for a
Location header, but you still think you should carry on this way?
This is just laziness on your part.
Laziness is supposed to be a virtue in programmers.

The Perl community has a rather good understanding of "laziness"
in this sense. It doesn't mean what many superficial commentators
suppose it to mean. I haven't worked out where you stand on that
question, so "no offence intended".
I have managed some enthusiastic programmers in the past and they
can get you in a _lot_ of trouble, although not in as much trouble
as enthusiastic lawyers.
The truly lazy programmer will save themself from unnecessary and
complicated debugging work by following the published specifications
whenever possible, instead of trying to "get away with it".

The original CGI spec has two defined variants of the *CGI* Location:
header:

1. an absolute external URL (leads to a 30x HTTP response and
a properly-specified *HTTP* Location: header)

2. an absolute URL path (i.e without any initial "http://"
part). This is required to be resolved internally by the
server, and will not result in any 30x response nor HTTP
Location: header.

Best place I know for current specification status is the
informational RFC http://www.ietf.org/rfc/rfc3875 , see section 6.3.2.

All else is a potential grey area - even if the spec were to be
clarified by trying to specify the behaviour of some subset of
that grey area, it wouldn't be binding on existing applications, so
the lazy programmer would do well to avoid pointless extra work by
confining themselves to the existing defined cases.
However, laziness notwithstanding, I do need stuff to work.

But first define "work", for cases where the interworking
specification does not say what's to happen. The usual sloppy answer
"does what I intended, with the software that I tried" would be
disqualified by any truly-lazy programmer.

IMHO, anyway