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] [Commented] (HTTPCLIENT-1638) cookie validation does not honor virtual host
Date Sat, 04 Apr 2015 16:27:33 GMT

    [ 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()
> 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
> * 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

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

View raw message