- From: William Perry <wmperry@spry.com>
- Date: Sat, 7 Oct 95 13:17 PDT
- To: Paul Hoffman <ietf-lists@proper.com>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Paul Hoffman writes: > >No. The only server capable of changing the port number must already > >be under the control of the site for which disambiguation of the > >hostname is necessary. In this case, the server receiving the request > >may do a million different things to further disambiguate the request > >before passing it on, including adding additional headers or just > >changing the Request-URI, and thus including the port number is never > >necessary. > > This is true for present software: the server software had to be > listening to a particular port in order to even get the "Host" header, or > anything for that matter. My thought was, in the future, one copy of a > server might be watching more than one port number for requests. As far > as I know, none do that now. In that case, it could be useful for the > server to know which port the request came in on. This seems a bit > far-fetched, given that any 1.0-speaking client would never tell the > server, and thus it would be assuming way too much. The spry server can listen to more than one port (so that you can have SSL and HTTP/SHTTP within one incarnation of the server, sharing the same pool of proceses, etc). I plan on extending this so that you can have multiple configs for different interfaces all from one incarnation of the server. Its easy to keep all the fd's in an FD_SET, do a select(), and then determine the fd that the request is coming in on. To then look up the appropriate config is easy. > I think it's probably not worth adding the port for this very small > potential in the future since it might lead to some ambiguities. Agreed. -Bill P.
Received on Saturday, 7 October 1995 13:16:01 UTC