[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561920#action_12561920
]
Hoss Man commented on SOLR-127:
-------------------------------
Thomas: first off .. thanks a lot for putting so much effort into this.
Looking over your patch, and seeing the hoops you had to jump through to get
per request handler configuration, i feel bad for ever even suggesting it.
We definitely shouldn't make a backwards incompatible change like you needed
with the getDefaults() to deal with the caching. I think for now, we should
stick with your earlier approach of putting the configuration in the
<requestDispatcher> block ... perhaps down the road we will have an easier
mechanism for per-handler overrides (maybe using the new components stuff?) but
even if we do, having some default configs in <requestDispatcher> will be good.
I've got a modified version of your patch that moves back in this direction
(but keeps some of the other good stuff you've added recently) that i'll attach
in a moment.
At a higher level, i have few broader questions/concerns that we should
probably think about...
1) it occurs to me that the etag value needs to include some kind of hashCode
for the solrconfig.xml -- otherwise someone could bounce their server (without
changing the index) and continue to get identical ETag headers, even if the new
config options cause entirely different results to be generated (ie: new
default handler params)
(We probably ought to be including the getVersion() info from both Solr and the
specified request handler as well -- just in case they deploy new code that has
new behavior without modifying the index, or their configs .. but i'm not
really as worried about this ... i'm OK with a FAQ saying you have make a small
change to your solrconfig.xml to force new ETags
2) currently, even if the configs say "don't be cache friendly" an etag is
still computed, and requests are tested for validation headers (it's even
possible to get a 304 if you guess the etag or pick a really old
If-Modified-Since header) ... this seems like a bad idea (and i believe it
violates the RFC) .. so we should make sure no special work is done relating to
cache headers if the solrconfig.xml says to disable it completely.
> 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: 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.
