[
https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley reassigned SOLR-453:
----------------------------------
Assignee: Ryan McKinley
> 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.