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]
