Return-Path: 
 <dev-return-23926-apmail-hc-dev-archive=hc.apache.org@hc.apache.org>
X-Original-To: apmail-hc-dev-archive@www.apache.org
Delivered-To: apmail-hc-dev-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
	by minotaur.apache.org (Postfix) with SMTP id E828D40A2
	for <apmail-hc-dev-archive@www.apache.org>;
 Tue, 17 May 2011 19:35:32 +0000 (UTC)
Received: (qmail 51938 invoked by uid 500); 17 May 2011 19:35:32 -0000
Delivered-To: apmail-hc-dev-archive@hc.apache.org
Received: (qmail 51897 invoked by uid 500); 17 May 2011 19:35:32 -0000
Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:dev-help@hc.apache.org>
List-Unsubscribe: <mailto:dev-unsubscribe@hc.apache.org>
List-Post: <mailto:dev@hc.apache.org>
List-Id: <dev.hc.apache.org>
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Delivered-To: mailing list dev@hc.apache.org
Received: (qmail 51888 invoked by uid 99); 17 May 2011 19:35:32 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 May 2011 19:35:32 +0000
X-ASF-Spam-Status: No, hits=0.7 required=5.0
	tests=SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (nike.apache.org: local policy)
Received: from [92.42.190.144] (HELO ok2cons2.nine.ch) (92.42.190.144)
    by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 17 May 2011 19:35:23 +0000
Received: from [192.168.1.111] (77-57-197-206.dclient.hispeed.ch
 [77.57.197.206])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by ok2cons2.nine.ch (Postfix) with ESMTPSA id E047D245E41F
	for <dev@hc.apache.org>; Tue, 17 May 2011 21:35:03 +0200 (CEST)
Subject: Re: ClientPNames.VIRTUAL_HOST parameter behaviour - code or docn
 bug?
From: Oleg Kalnichevski <olegk@apache.org>
To: HttpComponents Project <dev@hc.apache.org>
In-Reply-To: <BANLkTimNcpAKG56ouuWx50RucRu9EPy4aw@mail.gmail.com>
References: <BANLkTimNcpAKG56ouuWx50RucRu9EPy4aw@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
Date: Tue, 17 May 2011 21:34:54 +0200
Message-ID: <1305660894.12638.19.camel@ubuntu>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.3 
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org

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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org