[
https://issues.apache.org/jira/browse/SOLR-141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13037258#comment-13037258
]
Mike Sokolov edited comment on SOLR-141 at 5/21/11 3:55 AM:
------------------------------------------------------------
In this patch, SolrDispatchFilter.sendError() uses the ResponseWriter to format
an error response.
When the ResponseWriter is a BinaryResponseWriter, the response is written
directly to the servlet's output stream.
The error text is included in the response with key="error". Error responses
come back with HTTP status=200, although the status code in the SolrResponse is
as expected. I added a test to SolrExampleTests that shows this.
It would be a trivial change to set the proper HTTP status codes, but a
corresponding change in CommonsHttpSolrServer.request() would be needed so as
to return a usable response in that case, as the issue describes. For my part,
I think raising an exception might be better than returning a response that
seems to indicate success, but happens to include an error message. However
this goes against the idea of including partial data in a response, which was
mentioned as a goal, so I just made a minimal change.
was (Author: sokolov):
In this patch, SolrDispatchFilter.sendError() uses the ResponseWriter to
format an error response.
> Errors/Exceptions should be formated by ResponseWriter
> ------------------------------------------------------
>
> Key: SOLR-141
> URL: https://issues.apache.org/jira/browse/SOLR-141
> Project: Solr
> Issue Type: Wish
> Reporter: Hoss Man
> Fix For: 3.2
>
> Attachments: SOLR-141-sendError.patch, error-response.patch,
> solr-exception-writer-solr-1.2.diff, solr-exception-writer-v2.diff,
> solr-exception-writer-v3.diff
>
>
> Whenever possible, the Solr Dispatcher should to let the ResponseWriter
> format Exceptions using the format the user expects -- this should in no way
> change the fact that Exceptions currently generate non 200 HTTP status codes,
> nor should it prevent the Dispatcher from using the exception message as the
> HTTP status message -- but clients that want the full details of the error
> should be able to parse them in the format they expected based on the request.
> this would also give RequestHandlers the oportunity to return "partial"
> results - by adding both whatever results they have to the Response as well
> as the Exception they encountered.
> situations where this can't happen are obviously:
> * Exception thrown by ResponseWriter
> * Exception thrown so early in the request thta the DIspather doesn't know
> which ResposneWriter the client wanted.
> ...in those cases, plain text is a wise choice.
> thing that would probably need to be done to make this work:
> 1) if the Dispatcher catches an exception, it should call
> SolrQueryResponse.setException, set the HTTP status code/message as it
> currently does, but then hand off to the ResponseWriter.
> 2) Dispatcher needs to check SolrQueryResponse.getException and set the HTTP
> status code/message just like if it caught the exception itself.
> 3) all of the ResponseWriters should start looking at
> SolrQueryResponse.getException if they aren't already, and formatting it in a
> usefull way.
> 4) if the ResponseWriter throws an exception, Dispatcher needs to return a
> nice plain text error page
> extension to this idea... add a new method to ResponseWriter to generate a
> generic error message in the appropriate format that Dispatcher can use if
> the ResponseWriter throws an exception (as a backup before resorting to plain
> text)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
