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
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.
