[ https://issues.apache.org/jira/browse/SO
LR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:
comment-tabpanel#action_12536098 ]
Hoss Man commented on SOLR-127:
-------------------------------
In no particular order...
Ignore my question about weak etags (w/), this is what
happens when I review patches tired ... i forgot
getVersion() returns a long AND i missread how weak etags
work.
I wasn't saying that i think we need to do a hash to
"hide" the version, just pointing out that some
people might consider it divulging more info then we should.
if no one else cares, i don't care (especially if it's
prohibitively expensive)
I like the idea of not emiting caching headers in response
to POST requests ... the RFCs say that POSTs by default
aren't cachable right? that also seems like a reasonable
solution to the issues of typical "/update" urls
all having both identicle etags and urls, as well as
"If-None-Match" leading to PRECON_FAIL.
Having explicit config options for the Cache-Control header
seems good .. i wonder if we should make it a requestHandler
option (instead of a SolrCore option).
In regard to this comment...
"The default value is no-cache, no-store when the tag
is not there for backward compatibility."
...that's not really true. Total backwards compatibility
would be no new headers at all ... if someone has a surgate
proxy in front of Solr 1.2, it can use it's own configs or
hueristics to decide how long to cache. as soon as we
include Cache-Control header that stops working.
I think the default behavior can be "conservative"
headers (Last-Modified, ETag,and must-revalidate) that's
probably the best thing for new users. But ideally there
should be a way to turn it off completely (it's good to have
a mechanism for people upgrading to garuntee they get the
same behavior as before
> 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
> Fix For: 1.3
>
> Attachments: 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.
|
