lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Walter Underwood <wunderw...@netflix.com>
Subject Re: Cocoon-2.1.9 vs. SOLR-20 & SOLR-30
Date Mon, 20 Nov 2006 21:29:50 GMT
On 11/20/06 12:37 PM, "Ken Krugler" <kkrugler_lists@transpac.com> wrote:

>> One way to think about this is to assume caches, proxies, and load balancing
>> in the HTTP path, then think about their behavior. A 500 response may make
>> the load balancer drop this server from the pool, for example. A 200 OK
>> can be cached, so temporary errors shouldn't be sent with that code.
> 
> What are pros/cons to using the Cache-Control:no-cache response
> header to avoid this problem?

Clients can override that. Also, it is invisible to spiders and load
balancers. A spider will just keep fetching the error because we are
saying that it is a success. A load balancer will keep sending
traffic to the busted server.

Cold Fusion used to send errors with a 200 response code. Our search
spider happily indexed each one of those error documents. Every
time a record was deleted, the error message would stay in the
search index.

FUndamentally, when a server sends a failure with success response code,
it is not a legal HTTP implementation.
 
> I haven't tracked the entire thread - is the proposal that you'd use
> these response codes along with an XML body?

Right.

> ... If so, how would the
> client deal with a 500 or 404 from the servlet container (where the
> response would be typically HTML) versus a 500 from the actual
> service?

Check for a content type of XML and a document that matches the
Solr error format.

On the other hand, the client would do the same thing with a 500
regardless of which layer generated it. That is the advantage of
using HTTP response codes properly. Otherwise, you end up with
code that parses the response, finds the error, then calls the
routine to deal with a 500.

wunder
-- 
Walter Underwood
Search Guru, Netflix



Mime
View raw message