W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1995

Re: original host name in request/header

From: Jim Seidman <jim@spyglass.com>
Date: Mon, 13 Feb 95 08:54:22 -0600
Message-Id: <9502131454.AA26448@hook.spyglass.com>
To: Henrik Frystyk Nielsen <frystyk@w3.org>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Henrik Frystyk Nielsen writes:
>The problem is that in this case, the client not sending a host[name]
>header also are the clients which only support one URL in a redirection
>status code - or am I missing something?

Sorry, my message must have been poorly phrased after a long Sunday at work.
My intent was that as a migration strategy, redirection would occur if (and
only if) a Hostname field was present and the client was retrieving the root
document.  For example:

GET / HTTP/1.0
Hostname: megacorp.com

HTTP/1.0 302 Moved Temporarily
URI: <http://megacorp.com/megacorp/index.htm>

But when the client requested any other URI, the server could ignore the
Hostname field:

GET /megacorp/index.htm
Hostname: megacorp.com

HTTP/1.0 200 OK
...

A client which didn't support the Hostname field would never receive the 302
response, but would instead just get a document listing the different hosts
for that address.  (Of course this same strategy could be applied to a
Original-URI or similar scheme.)

As a transitional scheme, this is nice because all of the URIs for all of
the hostnames, with the exception of the root document, would be unique.  If
someone told someone, "Hey, look at the great content at
http://megacorp.com/megacorp/cool.htm" it wouldn't matter whether or not
their browser supported the Hostname field, or even if it handled redirects
properly.  The URI would just work.

--
Jim Seidman, Senior Software Engineer, Spyglass Inc.
Received on Monday, 13 February 1995 07:01:25 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:31:14 EDT