- From: Shel Kaphan <sjk@amazon.com>
- Date: Sat, 7 Oct 1995 16:29:07 -0700
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
William Perry writes: > 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. > That's a nice touch. The thing that worries me about expecting a "server proxy" (or reverse proxy, or whatever we call it) running on a firewall or other gateway to sort out all the port number issues is that in a large net, the administration of the firewall (and the HTTP proxy running on it, if any) may be fairly independent of the administration of any HTTP servers running inside the network. The site administrator may just say that requests on ports N through M will be accepted, but will all be forwarded on port P. (Some sysadmins can be uncooperative, or overworked). Then the question of how to detect which port a request is on is deferred to the origin server. So, in this case, unless there were a way for the port number to be a part of the request, there would be no way for a server listening at a certain IP address to disambiguate. Since it seems a little unnatural to have the port number as part of the Host header, what about an optional "Port" header that would allow, for instance, proxies to pass information about the original request port, without having to forward the request on a given port or modify the request-URI? Shel Kaphan
Received on Saturday, 7 October 1995 16:35:08 UTC