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

RE: Decision about Host?

From: Paul Leach <paulle@microsoft.com>
Date: Thu, 5 Oct 95 11:51:24 PDT
Message-Id: <9510052006.AA08206@netmail2.microsoft.com>
To: efrank@ncsa.uiuc.edu, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Some info:

1. There is a way to get the domain search path info in Windows and Windows/NT
2. AFAIK, it's only used by the Microsoft TCP/IP stack *today* -- but 
any PC stack could use it
3. In order to be the same for all stacks, it has to be agreed to by 
the WinSockets WG (an open WG formed from most/all of the Windows 
TCP/IP stack vendors)
4. They haven't seen that as a priority in the past
5. If we make it needed in order to support Host:, they will see the priority.


The domain search path it is stored in different registry locations on 
nt and win95.

List is a REG_SZ that contains a blank-delimited list of domain names.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSTCP\SearchList, also
a blank-delimited REG_SZ

Also: it is easy for there to be a portable way  for PCs -- put it in 
the browsers config file, entered as a preference. This requires extra 
work on the part of whoever sets up the browser. Or, we could collect 
where the information is for any stack vendor who wants to volunteer 
that info, and browsers should iteratively try each of those places.

Any and all cruft that mihgt be required in the short run to handle the 
problem could be hidden behind an API something like:
	HttpGetDnsSearchList(char ** pszSearchList)
which can in turn be in a DLL that can easily be replaced to call the 
Winsock routine when it gets standardized.

All the above leads me to say that we should take the high road -- 
require fqdn, because it won't be long or hard to have "the right 
thing" happen.

] From: Beth Frank  <efrank@ncsa.uiuc.edu>
] To: http WG  <netmail!http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>
] Subject: Decision about Host?
] Date: Thursday, October 05, 1995 11:21AM
] I need to give an answer to our browser implementors.
] My understanding of the situation is:
] 1) In HTTP/1.1  HOST will be a required header field for
] 	http: URI's.
] 2) There is not portable way to easily guarantee that a
] 	client (on all platforms) can get a fully qualified
] 	domain name (fqdn) to place in HOST.
] So, is it acceptable for the client to place whatever it
] 	finds between the // and the first / in the HOST
] 	field, with the understanding it may not be a
] 	fqdn?  If we can get a resolution on this soon,
] 	the addition of the HOST header will make the next
] 	Mosaic release.
] --
] 		Elizabeth(Beth) Frank
] 		NCSA Server Development Team
] 		efrank@ncsa.uiuc.edu
Received on Thursday, 5 October 1995 12:06:05 UTC

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