[
https://issues.apache.org/jira/browse/HTTPCLIENT-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14481901#comment-14481901
]
Daniel Robert commented on HTTPCLIENT-1638:
-------------------------------------------
My apologies, and thank you. It seems the Spring layer abstraction I was using
was hiding this interface from me; I was unaware I could pass a separate
HttpHost from an HttpUriAction.
> 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: [email protected]
For additional commands, e-mail: [email protected]
