lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ken Krugler <kkrugler_li...@transpac.com>
Subject Re: Cocoon-2.1.9 vs. SOLR-20 & SOLR-30
Date Mon, 20 Nov 2006 20:37:20 GMT
>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?

>On 11/20/06 10:51 AM, "Chris Hostetter" <hossman_lucene@fucit.org> wrote:
>>
>>  ...there's kind of a chicken/egg problem with this discussion ... the egg
>>  being "what should the HTTP response look like in an 'error' situation"
>>  the chicken being "what is the internal API to allow a RequestHandler to
>>  denote an 'error' situation" ... talking about specific cases only gets us
>>  so far since those cases may not be errors in all RequestHandlers.
>
>We can get most of the benefit with a few kinds of errors: 400, 403, 404,
>500, and 503. Roughly:
>
>400 - error in the request, fix it and try again
>403 - forbidden, don't try again
>404 - not found, don't try again unless you think it is there now
>500 - server error, don't try again
>503 - server error, try again

I haven't tracked the entire thread - is the proposal that you'd use 
these response codes along with an XML body? 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?

Thanks,

-- Ken
-- 
Ken Krugler
Krugle, Inc.
+1 530-210-6378
"Find Code, Find Answers"

Mime
View raw message