Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 70392 invoked from network); 11 Feb 2010 03:10:55 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Feb 2010 03:10:55 -0000 Received: (qmail 30137 invoked by uid 500); 11 Feb 2010 03:10:51 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 30087 invoked by uid 500); 11 Feb 2010 03:10:51 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 30074 invoked by uid 99); 11 Feb 2010 03:10:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 03:10:51 +0000 X-ASF-Spam-Status: No, hits=-1998.5 required=10.0 tests=ALL_TRUSTED,WEIRD_PORT X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Feb 2010 03:10:48 +0000 Received: from brutus.apache.org (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id DB322234C052 for ; Wed, 10 Feb 2010 19:10:27 -0800 (PST) Message-ID: <113242768.199941265857827896.JavaMail.jira@brutus.apache.org> Date: Thu, 11 Feb 2010 03:10:27 +0000 (UTC) From: "Hoss Man (JIRA)" To: solr-dev@lucene.apache.org Subject: [jira] Updated: (SOLR-1765) HTTP Caching related headers are incorrect for distributed searches In-Reply-To: <1974704019.154321265737888040.JavaMail.jira@brutus.apache.org> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/SOLR-1765?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-1765: --------------------------- Component/s: (was: multicore) (was: search) Description: When searching across multiple shards with HTTP caching enabled, the Caching related headers (ETag, Cache-Control, Last-Modified) in the response are based on the "index" of the coordinating solr core, and are not influenced by the properties of the shards. For example, take the query http://localhost:8983/solr/core1/select/?q=google&shards=localhost:8983/solr/core2,localhost:8983/solr/core3 ETag should be calculated off of core2 and core3, instead it's being calculated from the index of core1. This results in index modificaitons to to core2 or core3 being "invisible" to clients which query this URL using "If-None-Match" or "If-Modified-Since" type requests was: When searching across multiple shards with HTTP caching enabled, the ETag value in the response is only using the searcher in the original request, not the shards. For example, take the query http://localhost:8983/solr/core1/select/?q=google&shards=localhost:8983/solr/core2,localhost:8983/solr/core3 ETag should be calculated off of core2 and core3, instead it's being calculated from core1. Summary: HTTP Caching related headers are incorrect for distributed searches (was: ETag calculation is incorrect for distributed searches) > HTTP Caching related headers are incorrect for distributed searches > ------------------------------------------------------------------- > > Key: SOLR-1765 > URL: https://issues.apache.org/jira/browse/SOLR-1765 > Project: Solr > Issue Type: Bug > Affects Versions: 1.4 > Reporter: Charlie Jackson > Priority: Minor > > When searching across multiple shards with HTTP caching enabled, the Caching related headers (ETag, Cache-Control, Last-Modified) in the response are based on the "index" of the coordinating solr core, and are not influenced by the properties of the shards. For example, take the query > http://localhost:8983/solr/core1/select/?q=google&shards=localhost:8983/solr/core2,localhost:8983/solr/core3 > ETag should be calculated off of core2 and core3, instead it's being calculated from the index of core1. > This results in index modificaitons to to core2 or core3 being "invisible" to clients which query this URL using "If-None-Match" or "If-Modified-Since" type requests -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.