On 11/20/06, Fuad Efendi <[EMAIL PROTECTED]> wrote:
Here, we are passing 'Empty Query' error message with a full stack trace as an entity body of HTTP 404 response.
It's actually returning 400: $ curl -i http://localhost:8983/solr/select/ HTTP/1.1 400 Bad Request Date: Tue, 21 Nov 2006 03:56:34 GMT Server: Jetty/5.1.11RC0 (Windows XP/5.1 x86 java/1.5.0_09 Content-Type: text/plain; charset=UTF-8 Content-Length: 1377 org.apache.solr.core.SolrException: Missing queryString at org.apache.solr.request.StandardRequestHandler.handleRequest(Standard RequestHandler.java:105) at org.apache.solr.core.SolrCore.execute(SolrCore.java:587) at org.apache.solr.servlet.SolrServlet.doGet(SolrServlet.java:92)
Imagine that instead of 'Incorrect ZIP Code' we will see Java stack trace in some web-sites...
As an aside, as I pointed out in an earlier message, it's debatable if we should include a stack trace for user errors (as opposed to server errors). I guess it depends if it ever helps with debugging or not. Anyway, the Solr interface isn't meant as a user GUI. It's a back-end system like a database.
I am sure that mixing XML-based interface with HTTP status codes is not an attractive 'architecture', we shold separate conserns and leave HTTP code handling to a servlet container as much as possible...
That gets further away from REST. Not that Solr is purely REST, but it's not web-services either... it's about being practical. On the update side of things, I think it would be nice if one could check the HTTP status code and if it's OK (200), don't bother XML parsing the body. -Yonik
