You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@hc.apache.org by "Jon Moore (JIRA)" <ji...@apache.org> on 2018/05/04 17:33:00 UTC
[jira] [Comment Edited] (HTTPCLIENT-1920) Cached HEAD requests
without response body
[ https://issues.apache.org/jira/browse/HTTPCLIENT-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16464174#comment-16464174 ]
Jon Moore edited comment on HTTPCLIENT-1920 at 5/4/18 5:32 PM:
---------------------------------------------------------------
Ok, as I understand it, the bug occurs when we have a cached reply to a prior {{HEAD request, and we are now considering how to serve a GET}}. An HttpCacheEntry has a .getRequestMethod() method that will indicate what HTTP method was on the request that created the cache entry.
An unconditional {{GET request (i.e. where the incoming request does *NOT* have any conditional request headers like If-Match, If-None-Match, If-Range, If-Modified-Since, or If-Unmodified-Since}}) should never be served by a cache entry that was created by a HEAD.
A conditional GET _could_ be served by a cached HEAD request if the validation logic passes, where httpclient-cache would generate and return a 304 response. If validation fails on the cache entry, though, then we must make an _unconditional_ request to the origin instead of a revalidation request.
That's probably the full desired behavior.
The minimum acceptable behavior would just be to just check if the incoming request is a GET but the cache entry is a HEAD, and if so, to just forward the GET request on to the origin, completely ignoring the cache entry.
was (Author: jonm):
Ok, as I understand it, the bug occurs when we have a cached reply to a prior {{HEAD }}request, and we are now considering how to serve a {{GET}}. An {{HttpCacheEntry }}has a {{.getRequestMethod() }}method that will indicate what HTTP method was on the request that created the cache entry.
An unconditional {{GET }}request (i.e. where the incoming request does *NOT* have any conditional request headers like {{If-Match, If-None-Match, If-Range, If-Modified-Since, }}or {{If-Unmodified-Since}}) should never be served by a cache entry that was created by a HEAD.
A conditional GET _could_ be served by a cached HEAD request if the validation logic passes, where httpclient-cache would generate and return a 304 response. If validation fails on the cache entry, though, then we must make an _unconditional_ request to the origin instead of a revalidation request.
That's probably the full desired behavior.
The minimum acceptable behavior would just be to just check if the incoming request is a GET but the cache entry is a HEAD, and if so, to just forward the GET request on to the origin, completely ignoring the cache entry.
> Cached HEAD requests without response body
> ------------------------------------------
>
> Key: HTTPCLIENT-1920
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1920
> Project: HttpComponents HttpClient
> Issue Type: Bug
> Components: HttpClient (classic)
> Affects Versions: 4.4.1, 4.5
> Reporter: Tobias Gesellchen
> Priority: Major
> Labels: pull-request-available
>
> Since httpclient-cache 4.4 {{HEAD}} requests can be cached with a {{null}} response body. Subsequent {{GET}} requests to the same target then use the headers "If-None-Match" and "If-Modified-Since" to leverage caching via HTTP protocol. In that case a server can respond with status code 304 and an empty response body, which leads to an invalid cache entry.
> The GitHub PR #101 proposes a fix, which I have tested locally. The PR is based on httpclient-cache 4.5, but should easily be backported to 4.4. I haven't looked into the upcoming 5.x sources, yet.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org