[
https://issues.apache.org/jira/browse/HTTPCLIENT-1920?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16490842#comment-16490842
]
Jon Moore commented on HTTPCLIENT-1920:
---------------------------------------
Well, I haven't looked at the codebase myself in years, so this is definitely
one of those situations where I am hopeful between the code and my memory we're
in good shape! In any event, the caching module has extensive tests, so we can
also rely on those to help us avoid breaking things.
The check hasUnsupportedCacheEntryForGet() is related, I believe, to the fact
that the caching module originally only cached responses to GET requests, and
hence did not record the request method on cache entires (because we could
assume it was a GET). Once we started caching HEAD requests as well, though, we
needed to start recording the request method, but an existing client might have
upgraded to that version while still having old cache entries without methods
on them sitting around (e.g. some of the CacheStorage implementations write to
disk). This check essentially says if we don't know what method created the
cache entry, and it doesn't have a body (and isn't a 204 response, which we
_expect_ not to have a body), then we better not use it to serve the request.
To answer your specific question, I think you are right that we want to
generalize this a little, but I think we still care about the request method on
the cache entry. I think we want to avoid using the cache entry if the recorded
request method is null _or_ if the recorded request method is not GET. As I was
writing this reply, I thought the check out to be "if the cache entry's method
is null or does not match the request method", but that might exclude the valid
case of serving a HEAD from a cached GET. So I think it's more conservative to
just exclude this specific case.
I definitely think you are on the right track though!
> 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: [email protected]
For additional commands, e-mail: [email protected]
