[
https://issues.apache.org/jira/browse/HTTPCLIENT-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395713#comment-14395713
]
Oleg Kalnichevski commented on HTTPCLIENT-1638:
-----------------------------------------------
Daniel
The 'virtual host' parameter is an ugly legacy of HC3 days when all sorts of
silly parameters had to be introduced because there was no other way to
customize HttpClient behavior. It should have never been created in the first
place. The authority element of the request URI should be one and only true
source of target host info and is what should ultimately end up in the 'Host'
request header. While the target host is settable in the context prior to
request execution, this option was mostly intended for HttpCore users. The
reason the attribute gets overwritten in ProtocolExec because the target host
can change as a result of request redirect.
Oleg
> 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-unsubscr...@hc.apache.org
For additional commands, e-mail: dev-h...@hc.apache.org
