[
https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557381#action_12557381
]
Tomer Gabel commented on SOLR-453:
----------------------------------
You're probably right about this being a Tomcat bug, but the servlet API is
anything but clear about this. See
http://java.sun.com/products/servlet/2.3/javadoc/javax/servlet/http/HttpServletResponse.html#sendError(int,%20java.lang.String):
{quote}Sends an error response to the client using the specified status
clearing the buffer. The server defaults to creating the response to look like
an HTML-formatted server error page containing the specified message, setting
the content type to "text/html", leaving cookies and other headers unmodified.
If an error-page declaration has been made for the web application
corresponding to the status code passed in, it will be served back in
preference to the suggested msg parameter.{quote}
It doesn't say _anything_ about what's allowed or not inside the message. I
guess deprecating setStatus didn't really clear up the ambiguity :-(
> 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.
