Re: About that Host: header....

> The things that are wrong with the Host: solution, to my mind, are:
> - It STILL leaves us with a protocol where URLs are things that protocol
>   entities have to break into little pieces and chew upon.

Yes.  URLs are things that protocol entities have to break into little
pieces and chew upon.  That is true of all URL schemes.  It will remain
true even with full URLs since intermediary caches will break them
into pieces prior to internal canonicalization and key matching.

> - It STILL leaves us with an UA-to-cache protocol that is incompatible with
>   the UA-to-server and cache-to-server protocol.

On the contrary, the UA-to-cache protocol is identical to the UA-to-proxy
protocol, even when the cache is internal to the proxy.  It is true that
the client-to-proxy protocol is different than the client-to-server
protocol, but that is something which cannot be fixed in a timely fashion
because it requires the origin servers to change first.

> - It STILL loses the method information.

I don't understand this one -- the method is still there.  The only thing
that is lost is the original URL scheme and that information is inherent
in the connection to the origin server or gateway.

> - It STILL gives us no path to where it seems everyone wants to be, namely
>   with full URLs, until we throw out HTTP/1.x altogether

We have a path.  HTTP/1.0 now --> HTTP/1.1 on May 1 --> HTTP/2.0 as soon
as multiplexing + PEP + cookies have a solid, agreed-upon syntax.
HTTP/1.1 contains the mechanisms necessary to make deployment of HTTP/2.0

> These aren't "nothing". The question is which pain is lesser.

As I said, I think that the question is which one will solve the problem.
No matter what we decide, we cannot solve the problem if the solution
cannot be deployed.

 ...Roy T. Fielding
    Department of Information & Computer Science    (
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056

Received on Monday, 25 March 1996 00:20:36 UTC