On Tue, 2011-05-17 at 18:05 +0100, sebb wrote: > The documentation for ClientPNames.VIRTUAL_HOST says it: > > defines the virtual host name to be used in the <literal>Host</literal> > header instead of the physical host name. This parameter expects a value of > type <classname>HttpHost</classname>. > > In HC3.1, AFAICT the equivalent to this parameter is the method > HttpMethodParams.setVirtualHost(String hostname), which only accepts a > String for the hostname. The HC3.1 code automatically appends the > appropriate port for the connection if required (it does not append > :80 for http requests). Which is fine. > > However in HC4, AFAICT the HttpHost is used exactly as is when > generating the Host header - the correct port has to be provided in > the HttpHost instance (or omitted in the default case). Also the > documentation of the VIRTUAL_HOST parameter does not mention anything > about needing to set the port - it only mentions the hostname. > > So is the documentation correct?
In the past a number of people asked for an option to set a virtual port parameter in addition to a virtual hostname. This never made sense to me but admittedly I have no experience with web hosting and virtual hosts. Using HttpHost as the parameter type was the most flexible solution to the problem. > i.e. should the code automatically > add the correct port number to the generated Host header? The ClientPNames.VIRTUAL_HOST parameter is needed for some truly extreme situations as in most cases virtual hosts with a DNS entry do not require any special configuration. Therefore I tend to lean towards the option of taking ClientPNames.VIRTUAL_HOST value as it without any adjustment. > Or is the > code correct, in which case the documentation needs to be updated. If > the existing code is correct, then I think it would make sense to > provide a helper method to create an HttpHost instance with the > correct port value. > I would just update the documentation but will not object if you choose the change the behavior of the parameter instead. Cheers Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
