Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@lucene.apache.org
Date: Tue, 1 Mar 2011 19:00:36 +0000 (UTC)
From: "Hoss Man (JIRA)" <jira@apache.org>
To: dev@lucene.apache.org
Message-ID: 
 <358205915.5731.1299006036932.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: <1626770999.0.1298828617038.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] Resolved: (SOLR-2389) Default HTTP caching hurts developer
 experience.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/SOLR-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Hoss Man resolved SOLR-2389.
----------------------------

       Resolution: Fixed
    Fix Version/s: 4.0
                   3.1

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

> 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
>             Fix For: 3.1, 4.0
>
>
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org