- From: Roy T. Fielding <fielding@avron.ICS.UCI.EDU>
- Date: Sat, 23 Mar 1996 23:51:46 -0800
- To: Harald.T.Alvestrand@uninett.no
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> 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