Location header question

Do you have a question? Post it now! No Registration Necessary.  Now with pictures!

Threaded View

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

Re: Location header question

"G*rd*n" wrote:

Quoted text here. Click to load it

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 /

Re: Location header question

Quoted text here. Click to load it

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.

Quoted text here. Click to load it

Re: Location header question

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

Quoted text here. Click to load it

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

Quoted text here. Click to load it

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:

  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.

Quoted text here. Click to load it

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

Re: Location header question

Philip Ronan wrote:

Quoted text here. Click to load it

HTTP Location header, yes.

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

Confusing?  Exactly:-)

Nick Kew

Re: Location header question

Nick Kew wrote:

Quoted text here. Click to load it

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

Re: Location header question

Quoted text here. Click to load it

Philip Ronan wrote:
Quoted text here. Click to load it

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

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.

Site Timeline