[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563315#action_12563315 ]
Hoss Man commented on SOLR-127: ------------------------------- If we allow cacheHeaderSeed to be an arbitrary string, and only fold it into the ETag then what mechanism do we use to support the use case of lastModFrom="dirLastMod" when we eed the Last-Modified header to change because the solrconfig.xml changed? bq. 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. Right, but like you say: that's a solvable problem by maxing LastMod out with the current system time. bq. When I remember right XML attributes don't need a value. So we can do the following: But we would still have the problem of knowing to output unquoted values for certain directives (max-age, s-maxage, etc...) and quoted values for others. If we have to hardcoded all the directive names in code, they might as well be separate options. Taking in a single literal Cache-Control header string and using a regex to pull out the Expires is definitely appealing to me, but ... bq. A regex solution should work as well (but should fail gracefully with a warning logged to the logfile) ...what kind of failure/warning are you worried about? I'm assuming that the Cache-Control string will be written verbatim, and if it matches "\bmax-age=(\d+)" we'll also output an Expires; if the regex doesnt' match, we won't (no warning either way ... it seems perfectly normal for people to have a Cache-Control header without a max-age. > 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.