[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12535051
]
Hoss Man commented on SOLR-127:
-------------------------------
Okay, i've been learning a little more about HTTP Caching, and i looked over
the latest patch. a few comments...
1) do we really want this in all cases?...
+ resp.setHeader("Cache-Control",
+ "max-age=0, must-revalidate");
...that seems a little harsh. if we're going to do that it seems like it
should be optional. (NOTE: it's not backwards compatible if people already
have caches in front of Solr right now)
2) I've been reading about etags ... we need to make sure we don't
inadvertently output an etag with "w/" in front (indicating it's a week entity
tag) ... we should future proof against changes to IndexReader.getVersion() by
putting a prefix on the version when making an etag. also: should we obfuscate
the version (ie: hash it) so as not to risk disclosing info to people who
shouldn't have it?
3) all etags are the same until the reader is reopened ... shouldn't they also
hash on the URL? (is there a downside to multiple URLs having the same etag?)
4) are these semantics right? send PRECON_FAIL when "If-None-Match" tag matches
and request is not GET or HEAD? (what about a POSTed query?) ....
+ if(ifNoneMatchList.size()>0 && isMatchingEtag(ifNoneMatchList,etag)) {
+ if(isGETRequest || isHEADRequest) {
+ sendNotModified(resp);
+ } else {
+ sendPreconditionFailed(resp);
+ }
+ return true;
5) using SolrIndexSearcher.openTime() as last-modified for query requests makes
sense ... put what about updates? since RequestHandlers don't declare what
they are, should we use "now" for POSTs and openTime for GET/HEAD ?
> Make Solr more friendly to external HTTP caches
> -----------------------------------------------
>
> Key: SOLR-127
> URL: https://issues.apache.org/jira/browse/SOLR-127
> Project: Solr
> Issue Type: Wish
> Reporter: Hoss Man
> Fix For: 1.3
>
> Attachments: HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch
>
>
> an offhand comment I saw recently reminded me of something that really bugged
> me about the serach solution i used *before* Solr -- it didn't play nicely
> with HTTP caches that might be sitting in front of it.
> at the moment, Solr doesn't put in particularly usefull info in the HTTP
> Response headers to aid in caching (ie: Last-Modified), responds to all HEAD
> requests with a 400, and doesn't do anything special with If-Modified-Since.
> t the very least, we can set a Last-Modified based on when the current
> IndexReder was open (if not the Date on the IndexReader) and use the same
> info to determing how to respond to If-Modified-Since requests.
> (for the record, i think the reason this hasn't occured to me in the 2+ years
> i've been using Solr, is because with the internal caching, i've yet to need
> to put a proxy cache in front of Solr)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
