[
https://issues.apache.org/jira/browse/SOLR-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-2389.
----------------------------
Resolution: Fixed
Fix Version/s: 4.0
3.1
dealt with in SOLR-2397, example solrconfig.xml no longer has HTTP cache
headers/validation configured.
> Default HTTP caching hurts developer experience.
> ------------------------------------------------
>
> Key: SOLR-2389
> URL: https://issues.apache.org/jira/browse/SOLR-2389
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 1.4.1
> Environment: Solr's example config
> Reporter: David Smiley
> Priority: Minor
> Fix For: 3.1, 4.0
>
>
> The default configuration in example/solr/solrconfig.xml for HTTP caching can
> easily result cached responses (304) to a change configuration that would
> result in a different response. This results in a bad user (developer)
> experience, especially for the novice Solr user. It bit me several times when
> I was getting started. Hopefully I don't need to further convince committers
> that the default configuration is a problem. So as a consequence, I've
> always added never304="true" when starting new work with Solr and I recommend
> that readers of my book do the same. I'd like to see this rectified.
> The lastModifiedFrom="openTime" attribute should not be a problem. The
> openTime is "safe" and should not introduce bad cached responses, except when
> the query response uses "NOW"; but there's little that can be done about that.
> The etagSeed is a problem because it uses IndexReader.getVersion() which is
> the commit version and does not take into consideration the possibility of a
> configuration change. I hoped that not specifying etagSeed would result in no
> ETag but that did not occur -- I consider that a bug. Similarly, I would
> expect not specifying lastModifiedFrom would not result in a Last-Modified
> header but I haven't checked what happens.
> I'm not an expert in caching headers but it seems a little redundant to use
> both Last-Modified & ETag (& potentially Expires) when just one of these
> would suffice. Would it not?
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
