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.
On 11/20/06 10:51 AM, "Chris Hostetter" <[EMAIL PROTECTED]> 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 These can be mapped from internal error types. > the problem gets even more complicated when you try to answer the > question: what should Solr do if an OutputWriter encounters an error? ... > we can't generate a valid JSON response dnoting an error if the > JSONOutputWriter is failing :) Write the response to a string before sending the headers. This can be slower than writing the response out as it is computed, but the response codes can be accurate. Also, it allows optimal buffering, so it might scale better. If you really want to handle failure in an error response, write that to a string and if that fails, send a hard-coded string. wunder -- Walter Underwood Search Guru, Netflix
