[prev in list] [next in list] [prev in thread] [next in thread]
List: lucene-dev
Subject: [jira] Commented: (SOLR-2389) Default HTTP caching hurts developer
From: "Hoss Man (JIRA)" <jira () apache ! org>
Date: 2011-02-28 21:38:37
Message-ID: 900702064.3000.1298929117282.JavaMail.tomcat () hel ! zones ! apache ! org
[Download RAW message or body]
[ https://issues.apache.org/jira/browse/SOLR-2389?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13000535#comment-13000535 \
]
Hoss Man commented on SOLR-2389:
--------------------------------
bq. 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.
bq. 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.
> 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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic