Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Fri, 3 Apr 2015 21:14:53 +0000 (UTC)
From: "Daniel Robert (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12788100.1428094616000.121548.1428095693195@Atlassian.JIRA>
In-Reply-To: <JIRA.12788100.1428094616000@Atlassian.JIRA>
References: <JIRA.12788100.1428094616000@Atlassian.JIRA>
 <JIRA.12788100.1428094616502@arcas>
Subject: [jira] [Updated] (HTTPCLIENT-1638) cookie validation does not honor
 virtual host
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/HTTPCLIENT-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Robert updated HTTPCLIENT-1638:
--------------------------------------
    Description: 
There does not seem to be an end-to-end means of specifying a virtual host that's honored throughout the pipeline. 

Assume the following:
* HttpClientContext with context.setTargetHost(new HttpHost("some.vhost.com")) called before the request pipeline
* the request, an HttpUriRequest, has Host header specified equal to "some.vhost.com" (more on this below)
* an HttpClient build via HttpClientBuilder.create().build()

When the request is initiated, execution eventually falls to org.apache.http.impl.execchain.ProtocolExec.execute()
Within this method:
* a virtual host *may* be specified using the notably deprecated api of HttpParams. if so, the 'target host' is set to this value. if not, the target host is programmatically constructed using the requested uri.
* at this point, the context's target host is overwritten with this value

Note: This phase appears to be the first bug, as ProtocolExec is ignoring a defined context.targetHost() value, which should be the preferred mechanism since HttpParams has been deprecated. It then overwrites the desired value, regardless if one was already set. Aside from that, it does so using the direct setAttribute() method rather than the presumably preferred setTargetHost() mechanims.

Moving on, there are two interceptors which eventually hook into the flow:
* the RequestAddCookies request interceptor
* the ResponseProcessCookies response interceptor

In both interceptors, the CookieOrigin object is instantiated by using a host name as extracted from the context's "target host", which as previously mentioned has been overwritten. The net effect is that cookie hostname validation is done against the network host rather than the Http 1.1 "Host", causing false failures.

To put this more clearly, when executing against http://some.otherhost.com/:
GET /some/path HTTP/1.1
Host: some.vhost.com

Cookies end up being validated against domain 'some.otherhost.com' rather than the expected 'some.vhost.com'.

I have not yet had time to produce a patch, but seems the fix should be something like:
* ProtocolExec should check for the context's target host first, then falling back to HttpParams, then finally falling back to the programmatic approach.
* ProtocolExec should not overwrite the context's target host if the value was previously set
* Optionally: RequestAddCookies should allow the context creator to supply a pre-defined CookieOrigin rather than constructing and supplying its own, regardless if one was preexisting.

  was:
There does not seem to be an end-to-end means of specifying a virtual host that's honored throughout the pipeline. 

Assume the following:
* HttpClientContext with context.setTargetHost(new HttpHost("some.vhost.com")) called before the request pipeline
* the request, an HttpUriRequest, has Host header specified equal to "some.vhost.com" (more on this below)
* an HttpClient build via HttpClientBuilder.create().build()

When the request is initiated, execution eventually falls to org.apache.http.impl.execchain.ProtocolExec.execute()
Within this method:
* a virtual host *may* be specified using the notably deprecated api of HttpParams. if so, the 'target host' is set to this value. if not, the target host is programmatically constructed using the requested uri.
* at this point, the context's target host is overwritten with this value

Note: This phase appears to be the first bug, as ProtocolExec is ignoring a defined context.targetHost() value, which should be the preferred mechanism since HttpParams has been deprecated. It then overwrites the desired value, regardless if one was already set. Aside from that, it does so using the direct setAttribute() method rather than the presumably preferred setTargetHost() mechanims.

Moving on, there are two interceptors which eventually hook into the flow:
* the RequestAddCookies request interceptor
* the ResponseProcessCookies response interceptor

In both interceptors, the CookieOrigin object is instantiated by using a host name as extracted from the context's "target host", which as previously mentioned has been overwritten. The net effect is that cookie hostname validation is done against the network host rather than the Http 1.1 "Host", causing false failures.

To put this more clearly, when executing against http://some.otherhost.com/:
GET /some/path HTTP/1.1
Host: some.vhost.com

Cookies end up being validated against domain 'some.otherhost.com' rather than the expected 'some.vhost.com'.

I have not yet had time to produce a patch, but seems the fix should be something like:
* ProtocolExec should check for the context's target host first, then falling back to HttpParams, then finally falling back to the programmatic approach.
* ProtocolExec should not overwrite the context's target host if the value was previously set


> cookie validation does not honor virtual host
> ---------------------------------------------
>
>                 Key: HTTPCLIENT-1638
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1638
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>    Affects Versions: 4.3.5, 4.3.6
>            Reporter: Daniel Robert
>
> There does not seem to be an end-to-end means of specifying a virtual host that's honored throughout the pipeline. 
> Assume the following:
> * HttpClientContext with context.setTargetHost(new HttpHost("some.vhost.com")) called before the request pipeline
> * the request, an HttpUriRequest, has Host header specified equal to "some.vhost.com" (more on this below)
> * an HttpClient build via HttpClientBuilder.create().build()
> When the request is initiated, execution eventually falls to org.apache.http.impl.execchain.ProtocolExec.execute()
> Within this method:
> * a virtual host *may* be specified using the notably deprecated api of HttpParams. if so, the 'target host' is set to this value. if not, the target host is programmatically constructed using the requested uri.
> * at this point, the context's target host is overwritten with this value
> Note: This phase appears to be the first bug, as ProtocolExec is ignoring a defined context.targetHost() value, which should be the preferred mechanism since HttpParams has been deprecated. It then overwrites the desired value, regardless if one was already set. Aside from that, it does so using the direct setAttribute() method rather than the presumably preferred setTargetHost() mechanims.
> Moving on, there are two interceptors which eventually hook into the flow:
> * the RequestAddCookies request interceptor
> * the ResponseProcessCookies response interceptor
> In both interceptors, the CookieOrigin object is instantiated by using a host name as extracted from the context's "target host", which as previously mentioned has been overwritten. The net effect is that cookie hostname validation is done against the network host rather than the Http 1.1 "Host", causing false failures.
> To put this more clearly, when executing against http://some.otherhost.com/:
> GET /some/path HTTP/1.1
> Host: some.vhost.com
> Cookies end up being validated against domain 'some.otherhost.com' rather than the expected 'some.vhost.com'.
> I have not yet had time to produce a patch, but seems the fix should be something like:
> * ProtocolExec should check for the context's target host first, then falling back to HttpParams, then finally falling back to the programmatic approach.
> * ProtocolExec should not overwrite the context's target host if the value was previously set
> * Optionally: RequestAddCookies should allow the context creator to supply a pre-defined CookieOrigin rather than constructing and supplying its own, regardless if one was preexisting.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

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