[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12561974#action_12561974
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
{quote}
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
{quote}
Good point. You can get around that problem by using the openTime for the ETags
as well.
{quote}
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.
{quote}
True. I missed that one.
What do you expect from me now? Should I have a look at the testcase?
> 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, 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.
