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?xy z
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 misunderstandin g 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).
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?xy z
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 misunderstandin g 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).
Comment