lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bill Bell (JIRA)" <>
Subject [jira] Commented: (SOLR-2389) Default HTTP caching hurts developer experience.
Date Mon, 28 Feb 2011 04:13:38 GMT


Bill Bell commented on SOLR-2389:

If we totally turn it off, I would add a comment on how to turn it back on, and add a note
to the WIKI.

I am not really sure how to totally turn it off.

> Default HTTP caching hurts developer experience.
> ------------------------------------------------
>                 Key: SOLR-2389
>                 URL:
>             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:


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message