hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Kalnichevski <ol...@apache.org>
Subject Re: ClientPNames.VIRTUAL_HOST parameter behaviour - code or docn bug?
Date Tue, 17 May 2011 19:34:54 GMT
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

>  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.



To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org

View raw message