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()
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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
