Re: About that Host: header....

> The issues list has the text:
> 
>  Full URL must be accepted by server, may be sent by client.
> 
> Since JG seems to think that uncontroversial, I'll assume that's settled too.

Hmmmm, not quite.  It is okay for the WG to propose an incompatible change
to the HTTP protocol for the proposed standard.  It is not okay to do so
without indicating it through a change to the HTTP major protocol version
number.  The ability of a client to send a full URL to the origin server 
is an incompatible change, even when it is optional.

The HTTP version number is not some vague token indicating an arbitrary
revision of the specification; it has a specific set of semantics designed
to communicate the protocol capabilities and requirements of the sender.
It is a significant aspect of the protocol and is designed to maintain
coherence among the family of protocols that can be used to access services
identified by the "http" URL.

This means that the most we can say for anything called HTTP/1.x is

   a) Host header field must be supplied by client
   b) Full URL must be accepted by server

We can bypass this issue by changing the proposed version number to HTTP/2.0.
However, doing so will cost us greatly in terms of deployment.  In fact,
I will go on record for the following:

   I am not willing to make any incompatible protocol upgrades to my
   client and server software until I can include multiplexing support
   within the protocol.

In other words, I would rather have any valid HTTP/1.1 than a proposed
standard HTTP/2.0, unless the latter includes a multiplexed
session layer (which is 6-12 months away).  Even if the WG decides that an
incompatible protocol is the way to go, it must be called HTTP/2.0
so that I can define a meaningful subset for HTTP/1.x which is not
incompatible and thus can be used as a stepping-stone for deployment.
If HTTP/2.0 does not include multiplexing, then I will continue to
use HTTP/1.x until HTTP/3.0 is defined to include multiplexing.

This opinion is not mine alone -- I have received the same or similar
input from many vendors since the start of the WG.

In any case, such a decision would make my careful design of the protocol
transition irrelevant.  As such, I think the proponents of such a change
must provide significant proof that the change is necessary -- just saying
that you think it is an issue is not sufficient.

Host already provides a technical solution for the problem being discussed.
The only objection I have heard is that "people may implement it wrong".
Since that is also true of any other solution we may try, I do not
consider it to be a valid argument.  More importantly, the Host header
field can be implemented in HTTP/1.0 -- the solution does not depend
on the version number and thus anybody can implement it today.

There is nothing new about the Host issue.  We have been planning this
phased solution for almost two years now -- only the details have changed
in terms of the name of the 1.x header field.  We do intend to have
full URIs sent in HTTP/2.0 (regardless of what else is in that protocol)
because it is precisely at that point in which we can do all sorts of
message translation necessary for a variety of known extensions to the
protocol.  The reason for not doing it ALL RIGHT NOW is because the
existing HTTP/1.0 protocol was not sufficiently defined to provide a
basis for HTTP/2.0 and did not include the mechanisms necessary to
deploy an incompatible protocol.

> The questions before the WG seems to be:
> 
> - Should full URLs be mandatory to send for all HTTP/1.1 clients when
>   they don't know that they are talking to a HTTP/1.0 server?

Impossible without violating the protocol design -- this can only be done
in HTTP/2.0.

> - Should the host: header be deleted from the spec?

Not if we want a solution that can be deployed with existing practice.
If we can't deploy it, then we are wasting our time.  That is why the
Host header field is the preferred solution.

The following is an updated section on the Host header (updated to
reflect Lou's comments on the default port number). 

========================================================================
10.22  Host

   The Host request-header field specifies the Internet host and port
   number of the resource being requested, as obtained from the original
   URL given by the user or referring resource (generally an http URL,
   as described in Section 3.2.2).  The Host field value must represent
   the network location of the origin server or gateway given by the
   original URL.  This allows the origin server or gateway to
   differentiate between internally-ambiguous URLs, such as the root "/"
   URL of a server harboring multiple vanity hostnames on a single IP
   address.

       Host = "Host" ":" host [ ":" port ]    ; see Section 3.2.2

   A "host" without any trailing port information implies the default
   port for the service requested (e.g., "80" for an http URL).  For
   example, a request on the origin server for
   <http://www.w3.org/pub/WWW/> must include:

       GET /pub/WWW/ HTTP/1.1
       Host: www.w3.org

   The Host header field must be included in all HTTP/1.1 request
   messages on the Internet (i.e., on any message corresponding to a
   request for a URL which includes an Internet host address for the
   service being requested).  If the Host field is not already present,
   an HTTP/1.1 proxy must add a Host field to the request message prior
   to forwarding it on the Internet.  All Internet-based HTTP/1.1
   servers must respond with a 400 status code to any HTTP/1.1 request
   message which lacks a Host header field.

========================================================================

Additions to the spec regarding the requirement that all servers must
accept a full URI would be put in the section on Request-URI (5.1.2).
I think someone else is working on that.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92717-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Saturday, 23 March 1996 23:57:08 UTC