[
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: [email protected]
For additional commands, e-mail: [email protected]
