XMLHttpRequest POST fails on second attempt

RESOLVED INVALID

Status

()

Core
Networking: HTTP
--
major
RESOLVED INVALID
12 years ago
10 years ago

People

(Reporter: Stephen Augenstein, Unassigned)

Tracking

({regression})

Trunk
x86
Windows XP
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
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.
(Reporter)

Comment 1

12 years ago
I created a test case which resides at www.lasguerrillas.com/testcase.xhtml (so that it has the privaleges to do an XMLHttpRequest).
What are the expected and actual results for your testcase?
(Reporter)

Comment 3

12 years ago
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:
//
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?
(Reporter)

Comment 5

12 years ago
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.
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?
(Reporter)

Comment 7

12 years ago
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.
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.
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.
(Reporter)

Comment 12

12 years ago
Created attachment 214252 [details]
libcap of several interactions with the server
(Reporter)

Comment 13

12 years ago
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.
Component: General → Networking: HTTP
Product: Firefox → Core
QA Contact: general → networking.http
Version: unspecified → Trunk
Keywords: regression

Comment 14

12 years ago
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.
Flags: blocking1.9a2?
Closing this as invalid per above comment
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.