hc-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jon Moore (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (HTTPCLIENT-1515) Caching responses to HEAD requests
Date Thu, 12 Jun 2014 14:33:01 GMT

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

Jon Moore commented on HTTPCLIENT-1515:
---------------------------------------

[~fx.bonnet]: I'm curious: what part of the spec are you referring to? Variant cache entries
(e.g. due to content negotation) are an example of someplace we get multiple cache entries
per URI.

That said, you did remind me of another factor here, which is that certain events require
cache invalidations (e.g. a POST to the URI in question) of all related cache entries. Using
the method as part of the cache key wouldn't let us do that unless we treated it as a variant
and registered it in the root/parent cache entry. There's already an open issue because variant
handling requires multiple round trips through the cache (possibly requiring I/O) even when
only one variant is cached. So I'm not sure that's great either.

So perhaps I'm back to leaning towards the current patchset again, if we can:

1. Only turn on HEAD caching via an opt-in configuration parameter (this would include not
populating or reading the new method field on HttpCacheEntry unless it was on).
2. Add a note in the release notes that cache entries are not serialization compatible anymore
(I can do that when the patchset is merged).
3. If HEAD caching is turned on, treat a cache entry without a filled-in request method as
a cache miss for a GET unless it has an entity attached (in which case we can assume it was
a GET) or if it is a 204 No Content response (in which case the responses to HEAD and GET
were equivalent). It should be safe to use a cache entry with a missing method to satisfy
a HEAD request (all other normal caching rules aside).

How does that sound?

> 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: dev-unsubscribe@hc.apache.org
For additional commands, e-mail: dev-help@hc.apache.org


Mime
View raw message