Re: Two proposals for HTTP/2.0

>> >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
>
>The issue in question is not that of using CNAME aliases (which provide
>different names for the same service), but one of providing different
>services on the same machine, all with (vanity) addresses
>of the form above.

Yes, I understand the problem. It is identical to the technique used by
some C programs to examine argv[0] and perform different behaviors (serve
different home pages in the WWW case) based on the name, like
compress/uncompress or sendmail/newalias. But instead of using the name of
a program to determine behavior on a host, admins want to use the name of a
host to determine behavior of a single server (with multiple names).

This is a legitimate technique to use. I just question the logic behind
altering the syntax of HTTP requests when other mechanisms exist.

The real issue is that if clients don't send the name, servers have no way
of knowing which of many names was used to contact the server. SO, clients
ultimately have to support sending this info. Since clients need to change,
there will be a non-trivial period of time where some clients support the
new method (whatever that may be) and some don't. In order to ease the
transition (strictly from a software developers' perspective), the servers
should easily be able to accomodate requests from both types of clients.

The best way to do this is to try and leave the ways that clients
communicate with servers relatively untouched and enhance the amount of
info sent from client to server using features in the HTTP protocol
designed for this purpose. Namely, HTTP request header fields. New clients
will send the field, old clients won't. New servers will understand the
field, old servers won't. New clients will still be able to talk to old
servers with the SAME syntax, and old clients can talk to new servers, too.

Changing the request syntax to include a full URL will preclude NEW clients
being able to talk to OLD servers. The client has NO way of knowing whether
or not the server it is about to talk to can understand HTTP/2.0 until it
talks to it. This is the single biggest reason to avoid radical changes to
the syntax for the request. I don't know of any servers now that break if
they get a HTTP request header field that they don't understand. But I bet
every one of them will fail if they get a complete URL in a GET request.

>I _think_ this is currently done at a few sites with a feature of
>the BSD ifconfig that allows one interface to accept traffic on
>multiple IP addresses on one interface, then hacking the server
>to serve up different web pages for the different IP addresses.

This is different than using CNAMEs and doesn't present the same problem
since you DO know which ip address was contacted and can equate this
directly to a host name. It also isn't widely supported on many Unix
workstations. Another thing to consider is that a VAST majority of Web
servers aren't even being run on Unix servers. There are MANY, MANY more
servers running on PCs and Macs than Unix. So continuing to adopt a
Unix-centric approach to implementing new HTTP features is not necessarily
the best idea.

>It's an ugly hack, but there is a demand. I personally doubt this
>can be "fixed" in the HTTP protocol because of the problem of supporting
>old clients, and because this is, in effect, trying to subvert the meaning
>of the DNS in the context of URLs.

In so far as the HTTP protocol equates to the actual request/response
method syntax, I agree. However, there is an unlimited ability to modify
client and server interaction using other parts of the request/response
data (the header fields).

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
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 11:04:33 UTC