W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > September to December 1999

RE: Host header issue

From: Josh Cohen (Exchange) <joshco@Exchange.Microsoft.com>
Date: Mon, 6 Sep 1999 17:40:43 -0700
Message-ID: <BFF90FB6CF66D111BF4F0000F840DB850BCBBA69@LASSIE>
To: "'Larry Masinter'" <masinter@parc.xerox.com>, Albert-Lunde@nwu.edu
Cc: http-wg@hplb.hpl.hp.com
> -----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 
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 Tuesday, 7 September 1999 07:49:25 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:24 UTC