[
https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557376#action_12557376
]
Hoss Man commented on SOLR-453:
-------------------------------
i don't have tomcat handy to test this with at the moment, but if the
description is accurate, it seems like a clear cut tomcat bug ... the javadocs
for HttpServletREspose.sendError(int,String) are very clear -- we're using it
correctly.
Jetty seems to handle newlines *a* right way (i'm not impling there is only one
right way) ...by stripping out newlines (and any characters remotely
questionable) when building up the HTTP Status line.
Someone may want to followup on the tomcat list and see what they have to say
about it (it would be easy to create a non-solr test case ... a four line
servlet could demonstrate this problem...
{code}
import javax.servlet.http.*;
public class BrokenHttpStatusLineServlet extends HttpServlet {
public void doGet (HttpServletRequest req, HttpServletResponse res) {
sendError(500,"This\nmesg\ncontains\nUNSAFE\ncharacters\n\n\n\n\n"); } }
{code}
> 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.
