[
https://issues.apache.org/jira/browse/SOLR-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000018#comment-13000018
]
Yonik Seeley commented on SOLR-2389:
------------------------------------
bq. This results in a bad user (developer) experience
I think I agree - I was bit by this a lot when the HTTP caching feature was
added, until I trained myself to hold shift whenever I sent test queries to
Solr.
> 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
>
> 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: [email protected]
For additional commands, e-mail: [email protected]
