Solr
  1. Solr
  2. SOLR-2389

Default HTTP caching hurts developer experience.

    Details

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

      Solr's example config

      Description

      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

          Activity

          Hide
          Yonik Seeley added a comment -

          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.

          Show
          Yonik Seeley added a comment - 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.
          Hide
          Bill Bell added a comment -

          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.

          Show
          Bill Bell added a comment - 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.
          Hide
          Hoss Man added a comment -

          i'v made some related changes in my patch to SOLR-2397 so the example config there won't use HTTP Caching by default (but still has good commented out examples of how to enable it)

          Show
          Hoss Man added a comment - i'v made some related changes in my patch to SOLR-2397 so the example config there won't use HTTP Caching by default (but still has good commented out examples of how to enable it)
          Hide
          Hoss Man added a comment -

          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.

          when http cache headers are enabled, and solr is checking for validation requests (to response with a 304 if applicable) then solr will always output Last-Modified and ETag (per the specs) using sensible defaults – those params just let you override those defaults.

          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?

          It's intentional redundancy and part of the spec for HTTP Caching. naive caches can use only the Last-Modified, while more sophisticated caches can use the ETag to recognize when the content has changed i na way that doesn't actually invalidate the cache.

          Show
          Hoss Man added a comment - 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. when http cache headers are enabled, and solr is checking for validation requests (to response with a 304 if applicable) then solr will always output Last-Modified and ETag (per the specs) using sensible defaults – those params just let you override those defaults. 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? It's intentional redundancy and part of the spec for HTTP Caching. naive caches can use only the Last-Modified, while more sophisticated caches can use the ETag to recognize when the content has changed i na way that doesn't actually invalidate the cache.
          Hide
          Hoss Man added a comment -

          dealt with in SOLR-2397, example solrconfig.xml no longer has HTTP cache headers/validation configured.

          Show
          Hoss Man added a comment - dealt with in SOLR-2397 , example solrconfig.xml no longer has HTTP cache headers/validation configured.
          Hide
          Grant Ingersoll added a comment -

          Bulk close for 3.1.0 release

          Show
          Grant Ingersoll added a comment - Bulk close for 3.1.0 release

            People

            • Assignee:
              Unassigned
              Reporter:
              David Smiley
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development