RE: Host header issue

> -----Original Message-----
> From: Larry Masinter [mailto:masinter@parc.xerox.com]
> Sent: Monday, September 06, 1999 1:15 PM
> To: Josh Cohen (Exchange); Albert-Lunde@nwu.edu
> Cc: http-wg@hplb.hpl.hp.com
> 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 
absoluteURIs.
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