On Tue, 2011-05-17 at 21:35 +0100, sebb wrote: > On 17 May 2011 20:34, Oleg Kalnichevski <[email protected]> wrote: > > 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. > > JMeter users have asked for this where they don't have the ability to > define DNS entries for the virtual hosts. > > > Using HttpHost as the parameter type was the most flexible solution to > > the problem. > > +1. > > >> 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. > > Indeed, it does allow the virtual host and port to be completely > unrelated to the target URL. > > >> 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. > > Seems to me that the virtual host port generally ought to agree with > the URL port (as it does for non-virtual requests). > > But I suppose there may be servers that support virtual ports as well > as virtual hosts. > > The code could be changed to calculate the port number from the URL - > but only if it has not been provided. > > I think that would support just about every eventuality, as well as > being easier to use than the current code. > > Does that make sense? >
It does. +1 Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
