[
https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557343#action_12557343
]
Ryan McKinley commented on SOLR-453:
------------------------------------
but response.setStatus(int sc, java.lang.String sm) is deprecated
{panel}
Deprecated. As of version 2.1, due to ambiguous meaning of the message
parameter. To set a status code use setStatus(int), to send an error with a
description use sendError(int, String). Sets the status code and message for
this response.
{panel}
using sendError(code,error) is supposed to format the message in HTML for you.
There are no restrictions on \n...
but it looks like you are saying Tomcat does not format the message as HTML?
One advantage of using sendError is that it lets you configure the error page
formatting in web.xml. With SOLR-141, I will still want to optionally allow
the webapp container to format the error.
> Solr may send invalid HTTP error responses on exceptions
> --------------------------------------------------------
>
> Key: SOLR-453
> URL: https://issues.apache.org/jira/browse/SOLR-453
> Project: Solr
> Issue Type: Bug
> Affects Versions: 1.2
> Environment: Apache Tomcat 6.0.14 (on Windows Vista Business x86)
> Reporter: Tomer Gabel
> Assignee: Ryan McKinley
> Attachments: SolrErrorHandling-1.2.0.patch
>
>
> Solr sends error messages to the client via HttpServlet.sendError, with the
> message parameter comprised of both the error message and the stack trace.
> I don't know if this is an issue with other servlet containers, but when
> Tomcat generates the response it uses the message parameter for both the HTTP
> 500 status line and the generated error message itself; the problem with this
> is that, according to the HTTP 1.1 RFC
> (http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1), the "reason
> phrase" cannot contain CRs or LFs. The stack trace does.
> I suspect the reason this wasn't reported earlier is that the Java library's
> HTTP client (URL.openConnection) appears to be lax when parsing the HTTP
> response and will accept the error message without flinching. Contrariwise
> the .NET HttpWebRequest object will, unless configured for unsafe header
> parsing, throw an exception ("The server committed a protocol violation.
> Section=ResponseStatusLine"). Wireshark also does not recognize this as an
> HTTP response and will show the packets as "TCP segment[s] of a reassembled
> PDU".
> I'm attaching a patch that uses HttpServlet.setStatus instead and then writes
> the stack trace to the response stream, but I think a longer-term solution is
> to have the response formatters handle the body formatting (similar to the
> work done by Hoss Man on SOLR-141 here:
> http://issues.apache.org/jira/browse/SOLR-141). At any rate, I suppose that
> whether or not to write the stack trace should be a configurable option for
> security reasons.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
