[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579761#action_12579761
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
{quote}
It seems there is no way to disable caching on a per-handler basis.
{quote}
True. And we should work to a point where we can configure this per handler.
{quote}
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.
{quote}
I have no problem with disabling caching headers by default. We might need a
functionality where some back-end module can veto on emitting cache headers or
can tell the cache header code to emit cache headers that avoid caching of the
response. This is not too hard to implement. I have a look into this tonight.
We can simply add two methods to the SolrQueryResponse class (like _void
setAvoidHTTPCaching(boolean)_ and _boolean isAvoidHTTPCaching()_ - the default
for the value would be _false_). The update request handlers should set this to
_true_ all the time. The partial response stuff can set this to _true_ as well.
Another way of getting around emitting cache headers on a _per request_ basis
is to use POST requests. For POST requests we do not emit cache related headers
or _Not Modified_ responses completely following the W3C specs here.
And while thinking about that I realize that we need to extend the tests as
well that we make sure that we never emit cache related headers in case of
errors.
And still you can already disable caching header related functionality by adding
{noformat}
<httpCaching never304="true">
{noformat}
to your solrconfig.xml.
bq. 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.
In my world caching proxies and loadbalancers are the default. This might
influence my view on that stuff. ;-)
> 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.
