Uploaded image for project: 'Solr'
  1. Solr
  2. SOLR-2389

Default HTTP caching hurts developer experience.



    • Type: Improvement
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.4.1
    • Fix Version/s: 3.1, 4.0-ALPHA
    • Component/s: None
    • Labels:
    • Environment:

      Solr's example config


      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?


          Issue Links



              • Assignee:
                dsmiley David Smiley
              • Votes:
                0 Vote for this issue
                0 Start watching this issue


                • Created: