[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562848#action_12562848
]
Thomas Peuss commented on SOLR-127:
-----------------------------------
The cacheHeaderSeed is a good idea. It is like the version number on DNS
zonefile entries. The downside of such a thing is that you have to change it
manually (but Solr users are clever guys ;-) ). I would see no special meaning
in the seed - just a string that we mix with the version number of the index.
The user can choose whatever he wants there as long as he changes it when the
config changes substantially. Something like _cacheHeaderSeed="20080126123300"_
should be as good as _cacheHeaderSeed="version23"_. As we are caching the ETag
now we can use an MD5 or SHA1 hash for the Etag as well. We simply throw the
cacheHeaderSeed and the index version number into the hashing function and
Base64-encode the result of the hash. With that we obfuscate the index version
as well for the paranoid ones and always have an ETag of the same size
independent of the length of the seed. Additionally the Etag changes completely
if only one bit has changed. This makes the _equals_ check for the Etag a bit
faster as well.
The problems I see with cacheHeaderVersion beeing a timestamp is that you can
really break your caching headers if you put a future time stamp in there. This
is not allowed by the RFC. Of course we can check for a future time stamp and
give a warning and use the current time instead.
When I remember right XML attributes don't need a value. So we can do the
following:
{code}
<cacheControl max-age="23" no-cache no-store must-revalidate private="Foo"
qwert="666" />
...becomes...
Cache-Control: max-age="23", no-cache, must-revalidate, private="Foo", asdf,
qwert="666"
{code}
But again a very good idea to be flexible here. But the named list syntax might
be easier to handle in the code. A regex solution should work as well (but
should fail gracefully with a warning logged to the logfile). max-age is the
only value that is of interest for the code.
> Make Solr more friendly to external HTTP caches
> -----------------------------------------------
>
> Key: SOLR-127
> URL: https://issues.apache.org/jira/browse/SOLR-127
> Project: Solr
> Issue Type: Wish
> Reporter: Hoss Man
> Assignee: Hoss Man
> Fix For: 1.3
>
> Attachments: CacheUnitTest.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch, HTTPCaching.patch,
> HTTPCaching.patch
>
>
> an offhand comment I saw recently reminded me of something that really bugged
> me about the serach solution i used *before* Solr -- it didn't play nicely
> with HTTP caches that might be sitting in front of it.
> at the moment, Solr doesn't put in particularly usefull info in the HTTP
> Response headers to aid in caching (ie: Last-Modified), responds to all HEAD
> requests with a 400, and doesn't do anything special with If-Modified-Since.
> t the very least, we can set a Last-Modified based on when the current
> IndexReder was open (if not the Date on the IndexReader) and use the same
> info to determing how to respond to If-Modified-Since requests.
> (for the record, i think the reason this hasn't occured to me in the 2+ years
> i've been using Solr, is because with the internal caching, i've yet to need
> to put a proxy cache in front of Solr)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
