283428 - xmlhttprequest sends an incorrect Content-length header

Status: RESOLVED DUPLICATE of bug 246651

(Core :: XML, defect)

Description

[jfg]

User-Agent:       Opera/7.54 (Windows NT 5.1; U)  [en]
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040910


The problem
===========
xmlhttprequest add "\r\n" to the end of the buffer send with xmlhttp.
send(buffer) but put only the length of the buffer in "Content-length" header.

I notice a differed response when I send such a request to an Apache server and 
I suspect this could be the problem. The same test with IE is OK.

IE sends just the buffer    and Content-lenth = length of the buffer

Remark 1
========
RFC 2616 says:

        generic-message = start-line
                          *(message-header CRLF)
                          CRLF
                          [ message-body ]
        start-line      = Request-Line | Status-Line

   ....

   Certain buggy HTTP/1.0 client implementations generate extra CRLF's
   after a POST request. To restate what is explicitly forbidden by the
   BNF, an HTTP/1.1 client MUST NOT preface or follow a request with an
   extra CRLF.

Remark 2
========
The problem seems to be in nsXMLHttpRequest.cpp / GetStreamForWString



Reproducible: Always

Steps to Reproduce:

For example:
xmlhttp = XMLHttpRequest(); 
xmlhttp.open("POST", url, false); 
xmlhttp.send("abc");

gives ...

POST http://10.99.99.51/jfg/test_xmlrpc_srv.py HTTP/1.0\r
Host: 10.99.99.51\r
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/
20040910\r
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/
plain;q=0.8,image/png,*/*;q=0.5\r
Accept-Language: en-us,en;q=0.5\r
Accept-Encoding: gzip,deflate\r
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7\r
Connection: close\r
Proxy-Connection: close\r
Content-Type: text/plain\r
Content-Length: 3\r
Pragma: no-cache\r
\r
abc\r


(the cgi server just ping stdin in Body:<...stdin stream...>)


HTTP/1.1 200 OK\r
Date: Thu, 24 Feb 2005 08:23:21 GMT\r
Server: Apache/1.3.29 (Win32) mod_webkit/0.5 PHP/4.3.4\r
Connection: close\r
Content-Type: "text/plain"\r
\r
Body:<abc>

Comment 1

[Christian :Biesinger (don't email me, ping me on IRC)]

this has since been fixed in bug 246651... but, only for 1.8-based releases.
maybe it should also be fixed on the 1.7 branch

Comment 2

[Christian :Biesinger (don't email me, ping me on IRC)]

*** This bug has been marked as a duplicate of 246651 ***

Comment 3

[jfg]

> this has since been fixed in bug 246651... but, only for 1.8-based releases.
> maybe it should also be fixed on the 1.7 branch

Sorry not to have find the original bug.
As this bug prevents usign Mozilla with Apache/XMLRPC servers, it should be nice 
to fix it in 1.7 branch.
Thank's.

Comment 4

[Mark Glines]

This is definitely not fixed in the 1.7 branch.  I am seeing the problem in Mozilla 1.7.12: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20060207

An empty POST request is not really empty, it consists of a CRNL.  But the Content-length is 0, not 2.  This causes confusion in the cheesy little web server I've been using (Catalyst::Engine::HTTP), and results in a truncated response.  (The first response packet gets through, followed immediately by a TCP RST.)  Removing either the CRNL or fixing the Content-length results in a successful fetch.

Please reopen this bug, and port the fix over from 1.8.

I'll attach a file, orig_fetch.txt, which was captured from mozilla 1.7.12, generated by the AJAX code in Prototype 1.4.0.  It can be submitted to a web server for testing, with the following linux shell command: "cat orig_fetch.txt | nc -v <server> <port>".  But the important thing is the Content-length: 0 header, and the extra CRNL (2 bytes of request body total).

Comment 5

[Mark Glines]

Attachment: HTTP request with mismatch between body-size (2 bytes) and Content-length header (0).

Hopefully uploading this as text won't convert CRNL to NL, or anything like that.