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? [In any case, the docs need expanding a bit; I'll do that.] > Cheers > > Oleg > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
