hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Joseph Walton (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1542) Caching HttpClient uses absolute URIs for validation
Date Sat, 16 Aug 2014 03:57:19 GMT

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

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

Good point. The simplest way to avoid a new method is to copy-and-paste, rather than reusing,
that method. Perhaps copying and pasting it for the 4.3.x branch, then refactoring in trunk
to move to a single implementation?

> Would committing the patch to trunk be good enough?

My main concern is getting a build with that fix in; I can work with it whether it's 4.3.6
or 4.4-beta1.


> 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
>         Attachments: HTTPCLIENT-1542-rewrite-uris-before-validation
>
>
> {{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


Mime
View raw message