[
https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566869#action_12566869
]
Fuad Efendi commented on SOLR-127:
----------------------------------
Of course ETag etc. will synchronize caches; but anyway why do we need such
features of HTTP specs?
HTTP Caching is widely used to cache responces from HTTP Servers, content
(HTML, PDF, JPG, EXE) can be cached at coprorate proxy, and locally in Internet
Explorer's internal cache. That is the main idea.
*Are SOLR-XML responses roving the world and reaching internal cache of Mozilla
Firefox, or corporate caching proxies?*
-Not.
Clients of SOLR: Middleware. Do they need to act as "caching-proxy"? May be....
Just another use case: middleware publishes "current time" & "weather" together
with response from SOLR; middleware wants to cache responses from SOLR and do
not rely on requests coming from end users because of frequent weather changes
;) - it depends on implementation of such middleware, for sure, it will try
to cache SolrDocument objects instead of pure XML, and such kind of caching is
not HTTP-related.
> 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.
