[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566865#action_12566865
]
Fuad Efendi commented on SOLR-127:
----------------------------------
This is an alternative to initially proposed HTTP-caching, and it is extremely
easy to implement:
Simply add request parameter http.header="If-Modified-Since: Tue, 05 Feb 2008
03:50:00 GMT" (better is to use other names, do not use http.header parameter;
see below...)
Let SOLR to respond via standard XML message "Not Modified", and avoid using
304 response code
What do you think? We can even encapsulate MAX-AGE, EXPIRES, and other useful
stuff (like as additional UPDATE-FREQUENCY: 30 days) into XML, and all those
staff can depend on internal Lucene statistics (and not on hard-coded values in
SOLR-CONFIG).
We should not use HTTP-Protocol response headers such as 304/400/500 to
describe SOLR's external API.
Sample: Apache HTTPD front-end, Tomcat (Struts-based middleware), and SOLR
(backend). With your initial proposal different users will get different data.
Why? Multithreading at Apache HTTPD. At least, there are some possible
fluctuations, cache is not shared in some configurations, etc. Each thread may
get own copy of "last-modified", and different users will see different data.
It won't work for most business cases.
Without HTTP:
"is modified?"
"when is next update of BOOKS category?"
- all caches around the world have the same timestamp for BOOKS category
... ... ...
> 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, 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, 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.
