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

Reply via email to