Re: About that Host: header....

> 
> 
> >In any case -- whether the host is in the URL or the Host: header is a
> >mere matter of taste.  One of them breaks things, the other doesn't --
> >so which one do we pick?
> 
> I wouldn't say "mere" taste. If one has one wart on the spec thats OK.
> Ten or twenty and the thing will start to get raqged. As I see it we have
> two issues:
> 
> 1) Backwards compatiblility with installed server base.
> 
<snip>
> 
> 		Phill

I don't think people have adequately considered the impact of the installed
server base.  In a crawl last fall, we found several 1.1 & 1.2 version of the
NCSA server still out there, and a large number NCSA 1.3 out there despite
our efforts to get people to upgrade to either 1.4 or 1.5.  If it isn't 
broken, you aren't going to get alot of sites to upgrade.

So, the question I have is: Is it better to accomodate those old sites or
to intentionally break the software to force them to upgrade?

I think any response that is hidden from the users (ie handled automatically by
a client with a retry) will simply increase bandwidth without any noticable
noise from users.  Without noise from the users, I doubt alot of sites will
upgrade.  I oppose the retry idea.  I'm mildly in favor the Host header since
it has already been implemented by some of the browsers and clients, but we'll
support whatever is contained in the final specification.  

-- 
		Elizabeth(Beth) Frank
		NCSA Server Development Team
		efrank@ncsa.uiuc.edu

Received on Tuesday, 19 March 1996 07:35:04 UTC