[
https://issues.apache.org/jira/browse/SOLR-453?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559082#action_12559082
]
Tomer Gabel commented on SOLR-453:
----------------------------------
Sorry for the delay, but I wanted to check this properly and had to download
and build curl for that.
I verified the behavior described against my own machine (standard
apache-tomcat-6.0.14.zip as downloadable from
http://tomcat.apache.org/download-60.cgi, running on Windows Vista Business
32-bit) and against our demo server:
{quote}{{
[EMAIL PROTECTED]:~$ cat /proc/version
Linux version 2.6.22-14-server ([EMAIL PROTECTED]) (gcc version 4.1.3 20070929
(prerelease) (Ubuntu 4.1.2-16ubuntu2)) #1 SMP Sun Oct 14 22:09:15 GMT 2007
}}{quote}
The Tomcat version running on the Linux server is apache-tomcat-6.0.14.tar.gz
downloadable from the same location.
curl does not exhibit the symptoms I mentioned (indeed newlines are replaced
with tabs), however any HttpWebRequests sent from a .NET program will fail as
outlined above. I'll try and capture the TCP traffic with curl but it'll take a
while (you can't capture localhost traffic with Windows and I don't have a
spare machine at the moment), but I'll hazard a guess that the behavior is
similar to Java's URL.openConnection...
Can one of the Linux guys around here try and capture localhost traffic
generated using curl? I wonder what the returning TCP packets contain.
> 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.
