RE: Host header issue

> -----Original Message-----
> From: Larry Masinter []
> Sent: Monday, September 06, 1999 1:15 PM
> To: Josh Cohen (Exchange);
> Cc:
> Subject: RE: Host header issue
> You might be able to convince the IESG to drop the requirement
> in the case where an absolute URI is supplied, but it's
> my guess that the answer will depend on how successful the
> original attempt to change user behavior through requirements
> on server compliance has been. Are there sufficient 
> compliant HTTP servers around that users have upgraded
> their clients? My impression is 'no'.
For non-absoluteURI requests:

I would think that you would have to search alot to find
a real browser that doesnt send the host: header today.
So, the "user behavior" is pretty much done.

Im sure there are some scripts and stuff that dont, but
I dont think that they are going to change their behavior no
matter what.  Since they probably do http/1.0 requests, no matter
how many 1.1 web servers get deployed, those servers are not
going to require a host header from 1.0 requests.

this rule is not doing anything to cause these rare
script clients to be upgraded since servers will still support
1.0 without host:.

for the absoluteURI request case:

If an absoluteURI is supplied to an origin server by the client,
then that client is obviously a 1.1 client. (excluding the pathological
case where a 1.0 client mistakes an origin for a proxy)

This rule is adding no value in the 1.1 client case.

The end result is that a 1.1 client request must send redundant
info both in the host: header and absoluteURI if it wants to use 
To furthur complicate things, at "some point in the future", the
client will (perhaps in 1.2?) be able to stop sending both ?

In summary, IMHO, this MUST is a well intentioned addition to the spec
that in the end tries (but fails) to cover a legacy case and in the process,
complicates the mainstream/future case.   I think this is bad.

Received on Monday, 6 September 1999 23:53:20 UTC