lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Peuss (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-127) Make Solr more friendly to external HTTP caches
Date Sat, 26 Jan 2008 11:57:34 GMT

    [ 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.


Mime
View raw message