W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1994

Re: Two proposals for HTTP/2.0

From: Chuck Shotton <cshotton@oac.hsc.uth.tmc.edu>
Date: Thu, 17 Nov 1994 12:23:05 -0600
Message-Id: <aaf14dc403021004352f@[129.106.30.2]>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>According to Chuck Shotton:
>>
>> Relying on something as weak as a domain name for differentiating the roles
>> a server is to perform is an extreme hack. There are MUCH better ways to
>> accomodate this that won't be subject to the whims, vagueries, and failures
>> of DNS. Path arguments, header fields, and any number of other techniques
>> can be used already to help a server determine its "role".
>
>Everything you say is true from a technical point of view.  However,
>the issue here is a political/commercial one.  When a company
>contracts with a service provider to create a WWW presence they want
>the URL for their company to be something like
>
>        http://company_name.com/

This is an apples and oranges discussion. An alias name in the DNS for a
computer has very little to do with Web servers or HTTP. There is NO change
needed to HTTP request syntax to accomodate this. As I said before, clients
are going to need to send the info to the server one way or another. My
proposal is that they adopt a standard HTTP header field that specifies the
complete remote URL used to access the server.

Since there will be a mix of clients, some supporting host name reporting
and some not, it just doesn't matter how this info gets to the server.
Since it doesn't matter, the easier to implement solution is a new HTTP
request header field. It allows all clients and servers to operate as they
do now with NO code changes. Clients and servers that actually need host
name information can have tiny mods made to send the extra header field
containing the URL and process it.

Leave the standard alone on this issue. It is robust enough to do what you
want using the mechanisms built into it now without completely convoluting
the syntax of a request.

Companies will still be able to use whatever domain name they want and
servers will get a LOT more info than just the host name with this scheme.
In any case, the client must conform to a new standard, whatever it is, or
this won't work. All I'm suggesting is that there is a better way to
implement the delivery of host name info to the server that doesn't involve
hacking the request syntax and can be backwards compatible with ALL clients
and servers.

From-URL: http://host.name/file/path/info.html

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
Chuck Shotton                             \
Assistant Director, Academic Computing     \   "Shut up and eat your
U. of Texas Health Science Center Houston   \    vegetables!!!"
cshotton@oac.hsc.uth.tmc.edu  (713) 794-5650 \
_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-\-_-_-_-_-_-_-_-_-_-_-_-_-
Received on Thursday, 17 November 1994 10:25:50 EST

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