58397 - POST submission sends extra \n when submitting data to other webserver than apache.

Status: VERIFIED WORKSFORME

(Core :: DOM: Core & HTML, defect, P3)

Description

[tobi]

While working on a cgi script under Roxen webserver I discovered that I got an
extra \n in my POST submission and I thought it was a problem with roxen but
trying the site out in an other browser show that it works. Apperently mozilla
sends \n\r\n instead of \n\r as a end to POST submissions (or something)

Comment 1

[Fabian Guisset]

Reporter, is this still an issue with the latest build
(http://ftp.mozilla.org/pub/mozilla/nightly)? Also please make a query in
bugzilla and see if you can find a duplicate, it sounds familiar. Please provide
the buildID with which you test(ed) this.
Thank you!
Fabian.

Comment 2

[rods (gone)]

reassigning

Comment 3

[Eric Pollmann]

Hm, pretty sure we send \r\n as the final characters - it would be quite strange
if a browser was ending with \n\r since the network linebreak character is \r\n.
 Can you provide information such as what platform you are running the client
web browser on (Mac, Windows, Un*x) and what platform you are running the web
server on?  Also, what method are you using to grab the raw data sent to the web
server?


Relevant code in nsFormFrame.cpp (line 1188, in ProcessAsURLEncoded):
  aData += buf;
  // Need to append CRLF to end of stream for compatability with Nav and IE
  if (isPost) {
    aData.AppendWithConversion(CRLF);
  }

Comment 4

[tobi]

Here are some more information. The client platform is Linux 2.2.17 debian 2.3
and the mozilla I am using has build id: 2000120808 and the server platform is
FreeBSD 4.0 with roxen webserver 2.0. You can check it out at :
http://www.debian.as/home/tobi/testmoz.html in both netscape and mozilla to see
the diffrence. 

Comment 5

[Keyser Sose]

I am going to mark this NEW, since i see it as well as the fact it may or may
not be unintentional. Can someone please look at this and if were not going to
fix it mark it as WONTFIX or INVALID.

Comment 6

[Hugh Kennedy]

[e-mail], do you still see this behavior with the nightlies?
i was unable to duplicate it with 2001010904 on winNT,
2001010909 on Solaris or 2001011021 on i686-pc-linux.

verified the correct (CRLF) behavior with an octal dump from netcat,
which showed the final two characters as 0d 0a (as expected)

Comment 7

[Marek Z. Jeziorek]

per previous comment: WORKSFORME

Comment 8

[Vladimir Ermakov]

verifying per hugh's comments.