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 Wed, 18 May 2011 07:12:31 GMT
On Tue, 2011-05-17 at 21:35 +0100, sebb wrote:
> On 17 May 2011 20:34, Oleg Kalnichevski <olegk@apache.org> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message