[
https://issues.apache.org/jira/browse/HTTPCLIENT-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14395803#comment-14395803
]
Daniel Robert commented on HTTPCLIENT-1638:
-------------------------------------------
At the risk of turning this ticket into a forum post, I'm afraid I don't
understand your assertion. There is a reason Http 1.1 introduced the concept of
applying a Host header independently of the authority component of the URI;
this is entirely how named virtual hosting works. My use case, is that I'm
making a request to a machine (or set of machines) running multiple sites and
it makes the distinction of which to serve by the incoming request's Host
header. That is, the following requests would result in entirely different
responses:
GET /some/path HTTP/1.1
Host: foo.example.com
GET /some/path/ HTTP/1.1
Host: bar.example.com
In both cases, let's say the Host name is websrvr01.mylan.com. I would not be
using bar.example.com in my URL string as the request is being made to an
internal ip, perhaps vip.websrvr.mylan.com. The URI component and the Host
request header are separate and serve separate purposes. This ticket is
outlining a case where I do not seem to be able to set these independently or
craft a named virtual host style request, which seems like a bug.
And I understand the HttpParams mechanism is undesirable; the code base is very
clear that it's been deprecated. But not clear that the concept of virtual
hosting is no longer supported. Unless I'm misunderstanding and there's a
separate approach for solving this; but the URL string alone is inadequate.
> 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]
