- From: Josh Cohen (Exchange) <joshco@exchange.microsoft.com>
- Date: Mon, 6 Sep 1999 17:40:43 -0700
- 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 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