OK, yes, I see now. Even though the etags change when the swap
happens, the last modified date on the server may be earlier than what
the client has from the request prior to the swap.

thank you.
Tim


On Tue, May 4, 2010 at 12:30 PM, Erik Hatcher <erik.hatc...@gmail.com> wrote:
> The issue is that browsers (apparently not Safari?) will send the
> last-modified/etag headers to Solr and get back a 304 and your browser will
> simply display the last response it got.  Use the force reload option from
> the browser (it's a habit for me now) to ensure you're actually getting a
> current response from Solr, or turn off the HTTP 304 capability of Solr
> altogether.
>
>        Erik
>

Reply via email to