255741 - XMLHTTPRequest POST includes CRLF in the beginning of the postdata packet

Status: RESOLVED WORKSFORME

(Core :: XML, defect)

Description

[Loune]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040626 Firefox/0.9.1

When POSTing data, a normal request would have the headers in one packet and
then the post data in the second packet. The header packet should end with two
CRLFs signifying the end of the HTTP headers.
When using XMLHTTPRequest to POST, XMLHTTPRequest puts one CRLF in the end of
the header packet and another in the post data packet. This confuses some web
servers, making the request fail.

These dumps are courtesy of bug 246651

Using POST in XMLHTTPRequest

00000000  50 4f 53 54 20 2f 20 48  54 54 50 2f 31 2e 31 0d POST / H TTP/1.1.
00000010  0a 48 6f 73 74 3a 20 6c  6f 63 61 6c 68 6f 73 74 .Host: l ocalhost
00000020  3a 38 30 38 30 0d 0a 55  73 65 72 2d 41 67 65 6e :8080..U ser-Agen
00000030  74 3a 20 4d 6f 7a 69 6c  6c 61 2f 35 2e 30 20 28 t: Mozil la/5.0 (
00000040  58 31 31 3b 20 55 3b 20  4c 69 6e 75 78 20 78 38 X11; U;  Linux x8
00000050  36 5f 36 34 3b 20 65 6e  2d 55 53 3b 20 72 76 3a 6_64; en -US; rv:
00000060  31 2e 37 72 63 31 29 20  47 65 63 6b 6f 2f 32 30 1.7rc1)  Gecko/20
00000070  30 34 30 35 32 38 0d 0a  41 63 63 65 70 74 3a 20 040528.. Accept: 
00000080  74 65 78 74 2f 78 6d 6c  2c 61 70 70 6c 69 63 61 text/xml ,applica
00000090  74 69 6f 6e 2f 78 6d 6c  2c 61 70 70 6c 69 63 61 tion/xml ,applica
000000A0  74 69 6f 6e 2f 78 68 74  6d 6c 2b 78 6d 6c 2c 74 tion/xht ml+xml,t
000000B0  65 78 74 2f 68 74 6d 6c  3b 71 3d 30 2e 39 2c 74 ext/html ;q=0.9,t
000000C0  65 78 74 2f 70 6c 61 69  6e 3b 71 3d 30 2e 38 2c ext/plai n;q=0.8,
000000D0  69 6d 61 67 65 2f 70 6e  67 2c 2a 2f 2a 3b 71 3d image/pn g,*/*;q=
000000E0  30 2e 35 0d 0a 41 63 63  65 70 74 2d 4c 61 6e 67 0.5..Acc ept-Lang
000000F0  75 61 67 65 3a 20 65 6e  2d 75 73 2c 65 6e 3b 71 uage: en -us,en;q
00000100  3d 30 2e 35 0d 0a 41 63  63 65 70 74 2d 45 6e 63 =0.5..Ac cept-Enc
00000110  6f 64 69 6e 67 3a 20 67  7a 69 70 2c 64 65 66 6c oding: g zip,defl
00000120  61 74 65 0d 0a 41 63 63  65 70 74 2d 43 68 61 72 ate..Acc ept-Char
00000130  73 65 74 3a 20 49 53 4f  2d 38 38 35 39 2d 31 2c set: ISO -8859-1,
00000140  75 74 66 2d 38 3b 71 3d  30 2e 37 2c 2a 3b 71 3d utf-8;q= 0.7,*;q=
00000150  30 2e 37 0d 0a 4b 65 65  70 2d 41 6c 69 76 65 3a 0.7..Kee p-Alive:
00000160  20 33 30 30 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  300..Co nnection
00000170  3a 20 6b 65 65 70 2d 61  6c 69 76 65 0d 0a 43 6f : keep-a live..Co
00000180  6e 74 65 6e 74 2d 54 79  70 65 3a 20 74 65 78 74 ntent-Ty pe: text
00000190  2f 78 6d 6c 0d 0a 43 6f  6e 74 65 6e 74 2d 4c 65 /xml..Co ntent-Le
000001A0  6e 67 74 68 3a 20 38 31  0d 0a 50 72 61 67 6d 61 ngth: 81 ..Pragma
000001B0  3a 20 6e 6f 2d 63 61 63  68 65 0d 0a 43 61 63 68 : no-cac he..Cach
000001C0  65 2d 43 6f 6e 74 72 6f  6c 3a 20 6e 6f 2d 63 61 e-Contro l: no-ca
000001D0  63 68 65 0d 0a                                   che..
000001D5  0d 0a 3c 3f 78 6d 6c 20  76 65 72 73 69 6f 6e 3d ..<?xml  version=
000001E5  22 31 2e 30 22 3f 3e 3c  6d 65 74 68 6f 64 43 61 "1.0"?>< methodCa
000001F5  6c 6c 3e 3c 6d 65 74 68  6f 64 4e 61 6d 65 3e 74 ll><meth odName>t
00000205  65 73 74 2e 71 75 65 72  79 3c 2f 6d 65 74 68 6f est.quer y</metho
00000215  64 4e 61 6d 65 3e 3c 2f  6d 65 74 68 6f 64 43 61 dName></ methodCa
00000225  6c 6c 3e 0d 0a                                   ll>..

A normal POST request

00000000  50 4f 53 54 20 2f 20 48  54 54 50 2f 31 2e 31 0d POST / H TTP/1.1.
00000010  0a 43 6f 6e 6e 65 63 74  69 6f 6e 3a 20 63 6c 6f .Connect ion: clo
00000020  73 65 0d 0a 48 6f 73 74  3a 20 6c 6f 63 61 6c 68 se..Host : localh
00000030  6f 73 74 3a 38 30 38 30  0d 0a 55 73 65 72 2d 41 ost:8080 ..User-A
00000040  67 65 6e 74 3a 20 6c 77  70 2d 72 65 71 75 65 73 gent: lw p-reques
00000050  74 2f 32 2e 30 31 0d 0a  43 6f 6e 74 65 6e 74 2d t/2.01.. Content-
00000060  4c 65 6e 67 74 68 3a 20  38 32 0d 0a 43 6f 6e 74 Length:  82..Cont
00000070  65 6e 74 2d 54 79 70 65  3a 20 61 70 70 6c 69 63 ent-Type : applic
00000080  61 74 69 6f 6e 2f 78 2d  77 77 77 2d 66 6f 72 6d ation/x- www-form
00000090  2d 75 72 6c 65 6e 63 6f  64 65 64 0d 0a 0d 0a    -urlenco ded....
0000009F  3c 3f 78 6d 6c 20 76 65  72 73 69 6f 6e 3d 22 31 <?xml ve rsion="1
000000AF  2e 30 22 3f 3e 3c 6d 65  74 68 6f 64 43 61 6c 6c .0"?><me thodCall
000000BF  3e 3c 6d 65 74 68 6f 64  4e 61 6d 65 3e 74 65 73 ><method Name>tes
000000CF  74 2e 71 75 65 72 79 3c  2f 6d 65 74 68 6f 64 4e t.query< /methodN
000000DF  61 6d 65 3e 3c 2f 6d 65  74 68 6f 64 43 61 6c 6c ame></me thodCall
000000EF  3e 0a                                            >.

addresses 000001D0 and 0000009F are the start of a new packet, hence a new line.

Reproducible: Always
Steps to Reproduce:

Comment 1

[william]

How did you determine that it's the packets sequencing that makes the request
fails instead of the wrong content-length computation (bug 246651) ?
Can you give more details about the server you use ?

Comment 2

[Loune]

Closing the bug...

I found a typo in the post data of my code that caused the percieved failing of
the POST request. After some investigation and correspondence with William, I
have determined that this bug is a non-issue.