[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12579808#action_12579808
]
tpeuss edited comment on SOLR-127 at 3/18/08 4:23 AM:
------------------------------------------------------------
bq. This is indeed a useful feature for those who use a caching proxy in front.
But those users are educated enough to configure it in solrconfig.xml if they
need it .( BTW , We use Solr extensively and we have no caching in front of
Solr )
True. We should disable the cache header stuff by default. Please open a new
JIRA issue for that.
bq. In an ideal situation the 'select' handler must have it enabled by default.
For all other handlers keep it off by default and provide an option to enable
it (if needed)
Exactly. We need to get a bit more specific here. I have opened SOLR-505 for
that.
was (Author: tpeuss):
bq. This is indeed a useful feature for those who use a caching proxy in
front. But those users are educated enough to configure it in solrconfig.xml if
they need it .( BTW , We use Solr extensively and we have no caching in front
of Solr )
True. We should disable the cache header stuff by default. Please open a new
JIRA issue for that.
bq. In an ideal situation the 'select' handler must have it enabled by default.
For all other handlers keep it off by default and provide an option to enable
it (if needed)
Exactly. We need to get a bit more specific here. I opened SOLR-505 for that.
> 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.
