Re: About that Host: header....

My other problem with Host: and keeping partial URLs is that the partial URL
hack will get into the way of most serious things we can do where we
divorce the URL format from the HTTP protocol (like fetching things by
other locators).
And it encourages caches to continue breaking things they should have no
business breaking.
The Host: header is putting half the information in the wrong place.

Strawman proposal:

- HTTP/1.1 servers MUST respond correctly to full URLs.
  HTTP/1.1 servers MUST also serve partial URLs that come in with a
  HTTP/1.0 version field, MAY do so on HTTP/1.1 requests and SHOULD NOT
  do so on HTTP/1.2 requests.

- HTTP/1.1 clients MUST be able to be configured to send full URLs, for
  compatibility with HTTP/1.2 servers.
  If so configured, they SHOULD implement a per-server fallback strategy
  to partial URLs for compatibility with old servers.
  They MAY implement a configuration option to send partial URLs first,
  and provide per-server fallback to full URLs.

- Advance warning: Partial URLs will not be part of the HTTP/1.2 spec.

This gets us a clear statement that the future is full URLs, labels
1.1 clearly as a transition spec, and gets the software out there (I HOPE!)

What it doesn't get you is service bureau compatibility in minimal
implementations of 1.1 configured for speed over sanity.

BTW, the fallback from full to partial URL has exactly the same roundtrip
timing as fallback from http://host/~home to http://host/~home/ on NCSA
servers (other servers may be more optimized).
Given people's carelessness in specifying trailing slashes, do we have
clear evidence that they care about one more RTT, especially if it is
only once per server?

                               Harald A

Received on Thursday, 21 March 1996 01:00:44 UTC