329460 - XMLHttpRequest POST fails on second attempt

Status: RESOLVED INVALID

(Core :: Networking: HTTP, defect)

Description

[Stephen Augenstein]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060305 Firefox/1.5
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060305 Firefox/1.5

I created a webpage that uses XMLHttpRequest for my robotics team, and when I checked it today with the latest build, upon switching day, it will not actually receive new information, and the PHP script which it is communicating with complains that it didn't receive a date. In Opera though, it works fine.

Please e-mail me if you'd like a look at the PHP or would like me to change my javascript for further testing.

I should have a reduced test case tomorrow (hopefully).

Reproducible: Always

Steps to Reproduce:
1. Load page.
2. Click on any of the day buttons at the top
3. Wait for nothing to load

Also works if you click the refresh "button" on the page



Expected Results:  
Should have loaded several framsets with lists of students contained inside.

Comment 1

[Stephen Augenstein]

I created a test case which resides at www.lasguerrillas.com/testcase.xhtml (so that it has the privaleges to do an XMLHttpRequest).

Comment 2

[:Gavin Sharp [email: [e-mail]]]

What are the expected and actual results for your testcase?

Comment 3

[Stephen Augenstein]

Expected results are similar to when the page is loaded:
an alert with the text returned from the database should have
// SOME DATE
students.push("SOME NAME,SOME PHONE");
drivers.push("SOME NAME,SOME PHONE");

With several students.push() and drivers.push()

In reality, when the request is sent again, the server does not recieve the second http_request.send() so the alert contains just:
//

Comment 4

[:Gavin Sharp [email: [e-mail]]]

The responseText after each click is often different, it seems as though the server is returning the following string in some cases:

\n//\n</object></layer></span></div></table></body></html><!-- adsok-->\r\n<script language='javascript' src='https://a12.alphagodaddy.com/hosting_ads/gd01.js'></script>\r\n

while in other cases (when it works) it's sending the same string prefixed with the data you want to receive (students.push etc).

Are you sure this isn't a server side issue?

Comment 5

[Stephen Augenstein]

In Opera (and Firefox 1.5.1) at www.lasguerrillas.com/testcase.xhtml I get an alert when I load with:
//2006-02-26
drivers.push('Dan,');
students.push('Francois,');
students.push('Ling,248 346 5903');
students.push('Francois,');

If I click on any of the two buttons at the top, I get something like this:
//2006-02-27
drivers.push('Dan,');
drivers.push('Cathy Gilbert,248-320-3477');
students.push('trevor,2487093145');
students.push('Robert Liu,248-540-1647');
students.push('Robert Liu,248-540-1647');
students.push('Francois,');
students.push('Francois,');
students.push('Ling,248 346 5903');
students.push('Trevor,248-709-3145');
students.push('Ryan Gilbert,248-860-5627');

In this build though, clicking on any of the links returns:
//

Which means that the date for which it is retrieving data, which should be following the "//", is not being received by the php scrip ONLY in this build.

On top of that, I get errors every once in a while:
"Method Not Implemented
date=2006-02-28GET to /testcase.xhtml not supported.

Invalid method in request date=2006-02-28GET /testcase.xhtml HTTP/1.1

Apache/1.3.33 Server at www.lasguerrillas.com Port 80"

From the server, which suggests that SOMETHING in firefox is at fault.

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Those errors look like server errors to me, not Firefox errors.

Are you saying that you have a Firefox build that works, and one that doesnt? What are the build IDs of the two builds, if so?

Could you use the builds at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly and http://archive.mozilla.org/pub/firefox/nightly/ to narrow down a regression range?

Comment 7

[Stephen Augenstein]

The unworking one is contained in the original bug request and was a nightly (downloaded yesterday).

The working one is:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I'm running the nightly off my flash drive, and the working one is installed on my computer normally.

Comment 8

[Stephen Augenstein]

http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8/firefox-1.5.en-US.win32.zip

Is the build I downloaded yesterday around 2:30PM.

Comment 9

[Stephen Augenstein]

Occurs in http://archive.mozilla.org/pub/firefox/nightly/2006-02-05-06-trunk/ and not in http://archive.mozilla.org/pub/firefox/nightly/2006-02-04-06-trunk/

Comment 10

[:Gavin Sharp [email: [e-mail]]]

Great, thanks for finding a regression range! Are you able to reproduce this consistently? Could you possibly test the same code on another server? The only bug I see that could affect this and that landed in that range is bug 137155, and that might have affected certain server but not others.

Comment 11

[:Gavin Sharp [email: [e-mail]]]

Creating an HTTP log per the instructions at http://www.mozilla.org/projects/netlib/http/http-debugging.html and attaching it to this bug as an attachment might also be useful in finding the cause of the problem.

Comment 12

[Stephen Augenstein]

Attachment: libcap of several interactions with the server

Comment 13

[Stephen Augenstein]

I did some analysis, and it looks like in older versions, the http_request.send() is sent as a seperate packet, whereas in the newer builds, it's sent in the same packet.

Therefore, it may or may not be a result of confusing the server, although as an apache server, it should be able to handle what are appropriate transmissions.

Comment 14

[Darin Fisher]

This sounds like a server bug to me.  You cannot make any assumptions about how a TCP stream might be broken into packets.  The HTTP requests from the browser appear to be perfectly valid HTTP/1.1 requests, so I think bug is invalid.

Comment 15

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Closing this as invalid per above comment