[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562286#action_12562286 ]
Hoss Man commented on SOLR-127: ------------------------------- Incidentally, the config syntax i'm thinking might work best is something like... {code} <requestDispatcher handleSelect="true" > ... <!-- Set HTTP caching related parameters (for proxy caches and clients). (These are the defaults) <httpCaching lastModifiedFrom="openTime"> <cacheControl max-age="30" must-revalidate="" private="Foo" /> </httpCaching> --> <!-- to prevent Solr from doing any HTTP Cache related work uncomment this... --> <!-- <httpCaching never304="true" /> --> <!-- to prevent Solr work, and to be really unfriendly to caches, uncomment this... --> <!-- <httpCaching never304="true"> <cacheControl max-age="0" no-cache="" no-store="" must-revalidate="" private="Foo" /> </httpCaching> --> ... </requestDispatcher> {code} ...the idea being that any attribute under <cacheControl> becomes an option in the Cache-Control header .. if it has a non-empty value, then that value is echoed as well. Expires header will also be output if max-age is specified. > 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: 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.