[ https://issues.apache.org/jira/browse/SOLR-127?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12527664 ]
Hoss Man commented on SOLR-127: ------------------------------- 1) it's not a good idea to assume the indexVersion can be used as a timestamp ... Lucene does not guarantee that. To be safe we should record the timestamp we opened the index at. (using the lastModified on files in the Directory is a bad idea as well ... someone could swap out an index with a backup and get "older" files that represent a "newer" index from Solr's perspective) 1) isn't the header named "ETag" (not "Etag") ? 2) I'm not an expert on all this new fangled HTTP/1.1 stuff ... but is an ETag based on the URI and the indexVersion/timestamp really that useful? wouldn't the Last-Modified header in that case be just as useful? I thought the value add of an ETag was that even if the content has been modified, if that modification results in no real changes, old cached values can still be useful. with Solr specificly in mind, the index may have changed, but if the results of a query are identicle to the results before the change, those cna have the same ETag right? wouldn't a hash of the URI and the SolrQueryResponse make more sense in that regards? > 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 > Attachments: 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.