[
https://issues.apache.org/jira/browse/HTTPCLIENT-1515?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14029230#comment-14029230
]
Francois-Xavier Bonnet commented on HTTPCLIENT-1515:
----------------------------------------------------
I was referring to this part:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.4
They don't say we must have only 1 cache entry for GET and HEAD but if we
don't, the 2 cache entries will be tightly linked together.
What I understand is that a GET and HEAD request to the same resource should
get exactly the same headers. We may use 2 distinct cache entries but the
specification is not quite clear about what to update when you receive a
response. It says that you may use it to update the previously cached entity
but in case of a change in the value of headers Content-Length, Content-MD5,
ETag or Last-Modified you must treat the cache entry as stale. Does it mean
only a previously cached HEAD request or also a previously cached GET request
with an entity ?
I think that in order to avoid issues, whenever we receive a response from a
GET or a HEAD request, we should check any existing cache entry (from GET or
HEAD) and update or invalidate it if necessary. For me it is more simple to
have only 1 cache entry not to have to do the same work twice (I mean 1 cache
entry per variant in case there is an ETag or Vary header).
> Caching responses to HEAD requests
> ----------------------------------
>
> Key: HTTPCLIENT-1515
> URL: https://issues.apache.org/jira/browse/HTTPCLIENT-1515
> Project: HttpComponents HttpClient
> Issue Type: Improvement
> Components: HttpCache
> Reporter: Tyrone Cutajar
>
> Our system retrieves metadata via HEAD requests using HTTP Client 4.x and
> would benefit immensely from having the headers in the response cached.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]