> What I would be concerned with is the fact that Greg's solution
> hardcodes the protocol in ("http://";) which would break if the
> server was running HTTPS, but then you wouldn't be doing
> software virtual-hosting anyway, so maybe it's a moot point.There is a possibility of a server running https using a different host name than the specified server name. In that case wouldn't a request for https://productA.bna.com/AAAA redirect to https://xyz.bna.com/AAAA/ (different domain name) under the current scheme and http://productA.bna.com/AAAA/ (not ssl) with Greg's solution? Neither of which are desirable outcomes. (My tcl version of this is running on a secure server that uses 5 domain names for http and 1 domain name for https.) Granted, since only one secure server domain name is possible per instance (for now anyhow) one could just set the server name to that name. I don't see the host header being any greater a security risk than the requested url. (With multiple dns names attached to a single IP it practically is part of the requested url). If you treat it with the same kind of caution it should be usable for this purpose. On Friday 07 December 2001 06:59 pm, you wrote: > On 2001.12.07, Peter M. Jansson <[EMAIL PROTECTED]> wrote: > > The only concern I have is a security concern > > I looked at security as a possibility as well and since his solution > uses DStrings (which are growable, right?) then you don't have to > necessarily worry about buffer overflow. > > However, resource starvation/denial of service is a serious > potential problem. Fire up a couple hundred connections where > you feed a very large Host: string ... > > What I would be concerned with is the fact that Greg's solution > hardcodes the protocol in ("http://";) which would break if the > server was running HTTPS, but then you wouldn't be doing > software virtual-hosting anyway, so maybe it's a moot point. > > -- Dossy
