hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel Robert (JIRA)" <j...@apache.org>
Subject [jira] [Created] (HTTPCLIENT-1638) cookie validation does not honor virtual host
Date Fri, 03 Apr 2015 20:57:52 GMT
Daniel Robert created HTTPCLIENT-1638:

             Summary: 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.6, 4.3.5
            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()

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

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

This message was sent by Atlassian JIRA

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

View raw message