Re: Two proposals for HTTP/2.0

>According to hallam@axal04.cern.ch:
>>
>> Re the first proposal, to incorporate the hostname somewhere. This
>> would be cleanest put into the URL itself :-
>>
>> GET http://hostname/fred http/2.0
>>
>> This is the syntax for proxy redirects.
>>
>
>The only thing objectionable about this is that it is a substantial
>change from the HTTP/1.0.  I suppose we could say the syntax is
>
>GET URL HTTP/??
>
>and that HTTP/1.0 only allows relative URLs (i.e. relative to the host
>being queried).

If the server needs to know its own name, it seems more appropriate that
the info be made part of the request header and not the request itself. If
you want to have any hope of easily maintaining backwards compatibility
with slack clients, the header is a much safer place to put this info.

A more general purpose solution might be to have clients send the complete
URL that they used to make their current query. Something like:

From-URL: http://some.host/some/path.html

Since there will be backwards compatibility issues with old and new
clients, it matters little where this information is passed as some clients
will send it and some won't. In order to prevent wholesale overhaul of HTTP
request processing, it seems much easier to add a new header field than to
substantially change the syntax of requests.

>>
>> This suggestion conflicts with the aims of the second I'm affraid. I
>> don't think that its a good thing for a server to not know its name.
>> Proxying is far too prevelant now and a server that doth not know
>> its name shall be called a LOOP.

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". Simply depending
on the DNS name of the server is not sufficiently robust.

>Obviously a proxy server would have to know its own name.  But a small
>gateway that speaks HTTP on one side and accesses a local service on
>the other side shouldn't need to.  (Am I wrong about this? How would
>that create a loop?).  The proposal was to make it possible for such
>a gateway to use file system names in URL's without being required
>to know its own name.
>
>Parenthetically, IMHO proxy servers and regular servers should be
>different programs.  Their purposes are quite different.

I agree! Proxy servers perform a completely different function from
"regular" servers and in my opinion, are more properly termed "proxy
clients". With the advent of caching clients like NetScape, making
allowances in HTTP for proxy servers may become less of requirement except
at sites where there are evil firewalls that only allow the proxy in and
out.

--_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-_\_-_-_-_-_-_-_-_-_-_-_-_-_-_-_-
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 07:19:53 UTC