Mailing-List: contact dev-help@hc.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "HttpComponents Project" <dev@hc.apache.org>
Date: Fri, 15 Aug 2014 02:59:18 +0000 (UTC)
From: "Joseph Walton (JIRA)" <jira@apache.org>
To: dev@hc.apache.org
Message-ID: <JIRA.12734044.1408019221526.4569.1408071558450@arcas>
In-Reply-To: <JIRA.12734044.1408019221526@arcas>
References: <JIRA.12734044.1408019221526@arcas>
Subject: [jira] [Commented] (HTTPCLIENT-1542) Caching HttpClient uses
 absolute URIs for validation
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HTTPCLIENT-1542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098087#comment-14098087 ] 

Joseph Walton commented on HTTPCLIENT-1542:
-------------------------------------------

bq. I suspect we just need to un-relativize the validation request when we construct it in the caching module.

Agreed, I think this would fix it.

The last time I hit this issue in HTTPCLIENT-1447 the fix was also to apply {{rewriteRequestURI}} in more places -- should it move to a more general utility class, just to share the implementation? Having three separate paths that know about this case seems like there might be a more general fix.

> Caching HttpClient uses absolute URIs for validation
> ----------------------------------------------------
>
>                 Key: HTTPCLIENT-1542
>                 URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1542
>             Project: HttpComponents HttpClient
>          Issue Type: Bug
>          Components: HttpCache
>    Affects Versions: 4.3.5
>            Reporter: Joseph Walton
>
> {{HttpClient}} instances constructed through {{CachingHttpClients}} use absolute URIs when validating a resource.
> I'm constructing a caching {{HttpClient}} and requesting a resource that has a {{Cache-Control}} allowing for caching. Subsequent requests are served from the cache. On the first attempt to validate it, the absolute URI is passed rather than the relative URI that appeared in the original request.
> As with HTTPCLIENT-1447, this absolute URI is forbidden by the current HTTP RFC (RFC 7230, 5.3.1). (The spec also states that this only causes problems for a non-compliant server. I have one of those.)
> The example here uses {{Cache-control: max-age=0}} to force immediate validation.
> {noformat:title=Request}
> GET /resource HTTP/1.1
> Host: localhost:50732
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.3.5 (java 1.5)
> Accept-Encoding: gzip,deflate
> Via: 1.1 localhost (Apache-HttpClient/4.3.5 (cache))
> {noformat}
> {noformat:title=Response}
> HTTP/1.1 200 OK
> Cache-control: max-age=0
> Content-type: text/plain
> Content-length: 16
> Date: Thu, 14 Aug 2014 09:17:46 GMT
> XXXXXXXXXXXXXXXX
> {noformat}
> {noformat:title=Request}
> GET http://localhost:50732/resource HTTP/1.1
> Host: localhost:50732
> Connection: Keep-Alive
> User-Agent: Apache-HttpClient/4.3.5 (java 1.5)
> Accept-Encoding: gzip,deflate
> Via: 1.1 localhost (Apache-HttpClient/4.3.5 (cache))
> {noformat}
> {noformat:title=Response}
> HTTP/1.1 200 OK
> Cache-control: max-age=0
> Content-type: text/plain
> Content-length: 16
> Date: Thu, 14 Aug 2014 09:17:46 GMT
> XXXXXXXXXXXXXXXX
> {noformat}
> The {{rewriteRequestURI}} method in {{ProtocolExec}} would fix this, but this is added after {{decorateMainExec}} adds the caching layer, so the {{CachingExec}}'s backend, used for validation, doesn't include that processing step.
> As a simple fix, renaming {{decorateMainExec}} to {{decorateProtocolExec}} in {{CachingHttpClientBuilder}} ensures that the underlying backend carries out this transformation.
> However, this means that the validation requests will also participate in content decoding and cookie handling. A better fix may be to move {{rewriteRequestURI}} into {{MainClientExec}}.


--
This message was sent by Atlassian JIRA
(v6.2#6252)

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