[ 
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]

Reply via email to