[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579728#action_12579728
]
Shalin Shekhar Mangar commented on SOLR-127:
--------------------------------------------
It seems there is no way to disable caching on a per-handler basis. I've read
through the comments on this issue but I'm still not convinced as to why we
need to enable HTTP Caching by default. The way I see it is that using a HTTP
Caching Proxy in front of SOLR is a very rare use case and people using it in
their deployments can always go and enable caching in solrconfig. The downside
of enabling this by default is that there is no way right now to disable it on
a per-handler basis and even if there was a way, everyone would have to
explicitly do it in their configuration and is something that we would have to
educate users unnecessarily.
Our use case is the SOLR-469 DataImportHandler, which should not have responses
cached at any time. But there is no way for me to do it currently. I'm sure
there will be other use cases too e.g. SOLR-502 for which partial results are
also cached right now.
I appreciate the work you all have put into this issue and all I'm trying to
say is that a feature used very rarely should not be enabled by default. I'd
like to vote to go back to Solr 1.2 compatibility by default.
> 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, 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, 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.
