[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-127:
--------------------------
Attachment: HTTPCaching.patch
(NOTE: in my last update where I listed the new options, I forgot about the
"never304" option .. obviously that's still important).
Before I made any changes, I attempted to merge the previous HTTPCaching.patch
with CacheUnitTest.patch, and ran into test failure in NoCacheHeaderTest ...
looking at it, i'm not sure what it's expectation was/is (seemed to expect a
Cache-Control header even when no caching options were specified in the config)
so i just left it alone for now.
I have a new unified patch (code+tests) that does everything we talked about,
but there's still some thing that need resolved...
* the test classes still need some work, both in terms of the current failure
mentioned above, and to cover more permutations of options. When we're all
said and done, we'll probably want at least 3 separate sets of test/configs:
*# default, no <httpCaching> section in config at all ... should generate
Last-Mod and Etag headers and do validation, stoping/starting port should make
Last-Mod change but not ETag.
*# never304="false", lastModFrom="dirLastMod" ... should generate Last-Mod and
Etag headers and do validation, no headers should change if we stop/start the
port.
*# never304="true" ... no Last-Mod of ETag headers, no 304 even if we send
crazy old If-Modified-Since
* there's also probably some refactoring that can still be done in the tests (i
noticed some duplicate code that can be moved up into the Base class)
* it occurred to me while adding the etagSeed that right now the etag caching
is a singleton, we'll need to make this core-specific (using a WeakHashMap i
guess? i'm not fond of that approach, but these are really tiny pieces of info
we are caching)
* calcLastModified and calcEtag currently assume they can get
requestDispatcher/httpCaching config options from SolrConfig ... but this need
to be reconciled with SOLR-350 where there is a plan to move all
requestDispatcher configs to multicore.xml (but i've pointed out in that issue
i'm not sure if that is necessary or makes sense.)
Thomas: Can you take a look at the current test failure and help me understand
why it's expecting a Cache-Control header? (if you want to take a stab at
expanding the test case permutations too that would be cool)
And of course, Thomas (and everyone else), please try out the code changes in
the patch and the comments in the example solrconfig.xml and let me know if
this looks good.
> 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
> Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: CacheUnitTest.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> 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.
