[ https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557375#action_12557375 ]
Ryan McKinley commented on SOLR-453: ------------------------------------ so what error do you actually see? Does the reason phrase with a '\n' break something in particular? Unless this has real functional consequences, I'm tempted to say this should be fixed with SOLR-141, and that SOLR-141 needs to leave an option for sendError() > 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.