lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <j...@apache.org>
Subject [jira] Commented: (SOLR-453) Solr may send invalid HTTP error responses on exceptions
Date Wed, 09 Jan 2008 17:26:35 GMT

    [ https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12557343#action_12557343
] 

Ryan McKinley commented on SOLR-453:
------------------------------------

but response.setStatus(int sc, java.lang.String sm) is deprecated
{panel}
Deprecated. As of version 2.1, due to ambiguous meaning of the message parameter. To set a
status code use setStatus(int), to send an error with a description use sendError(int, String).
Sets the status code and message for this response.
{panel}

using sendError(code,error) is supposed to format the message in HTML for you.  There are
no restrictions on \n... 

but it looks like you are saying Tomcat does not format the message as HTML?

One advantage of using sendError is that it lets you configure the error page formatting in
web.xml.  With SOLR-141, I will still want to optionally allow the webapp container to format
the error.  



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


Mime
View raw message