using http redirect (302) causes extra reload

RESOLVED DUPLICATE of bug 168215

Status

()

RESOLVED DUPLICATE of bug 168215
16 years ago
3 years ago

People

(Reporter: peter, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3a) Gecko/20021212

i'm building using php 4.3.0 on debian linux. to avoid problems with reloads, 
GET-requests are always put in the session first, after which the script 
redirects to itself. the session is then picked up, and the GET-request is 
handled.

however, with mozilla i'm seeing some strangeness. a normal request (server 
log) should look like this (it's IE6, btw) :

"GET /content.php?menu_load=3d5129b56b52b HTTP/1.1" 302 5 "-" 
"GET /content.php HTTP/1.1" 200 46852 "-" 

and the page displays correctly. with mozilla, i'm seeing this :

"GET /content.php?menu_load=3d5129b56b52b HTTP/1.1" 302 5 "-" 
"GET /content.php HTTP/1.1" 200 22782 "-" 
"GET /content.php HTTP/1.1" 200 5 "-" 

and the page is blank...

if i do not use the redirect, IE shows :

"GET /content.php?menu_load=3d5129b56b52b HTTP/1.1" 200 46852 "-" 

and mozilla :

"GET /content.php?menu_load=3d5129b56b52b HTTP/1.1" 200 25831 "-" 
"GET /content.php?menu_load=3d5129b56b52b HTTP/1.1" 200 46852 "-" 

and the page displays correctly. 
the problem seems to occur _only_ when the output is large (200K+, as in the 
case above). with smaller pages, everything works as expected.

unfortunately, the site in progress currently resides on an internal machine, 
so i can't give an URL.

Reproducible: Always

Steps to Reproduce:
1.load page, notice problem
2.clear sessions (serverside), restart apache, restart mozilla
Actual Results:  
problem re-occurs.

Expected Results:  
the page should display correctly, regardless of the use of the redirect. 
tested with IE6 and lynx, both give expected results.
(Reporter)

Comment 1

16 years ago
Created attachment 111866 [details]
http log created by mozilla when problem occurs

this is the log created after doing :

set NSPR_LOG_MODULES=nsHttp:5
set NSPR_LOG_FILE=c:\http.log

before starting mozilla
(Reporter)

Comment 2

16 years ago
almost forgot : this report is based on 1.3alpha, but the problem also occurs 
with version 1.2.1 (i upgraded before submitting this)

Comment 3

16 years ago
nice bug report, does it also happen with latest nightly build ?
http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk
(Reporter)

Comment 4

16 years ago
just tried the latest build as suggested, the problem remains the same.

one additional thing i discovered : it seems the problem is caused or aggravated
by my debug-output when testing. because the application uses an XSLT transfom
as the last step before outputting anything, this output comes _before_ the html
and body tags (which is sloppy, i know, but it's the easiest way). if i use a
lower level of debugging (i.e. : less output), the problem disappears. it seems
that the problem starts when more than a couple (say 10) lines of debug-output
are present . the real mystery to me is why the presence of the redirect has any
influence.

Comment 5

16 years ago
no dupes found, detailed bug report, marking NEW.

can you check bug 96536 and bug 168089 to see if it's not a dupe of one of these ?
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 6

16 years ago
did check the other bug-ids, but i think this needs reclassification. i spend a
couple of hours drilling down to the very bottom of this, and have come up with
a testcase that displays (i think) the same problem, but is far less complex
than my earlier experiences. it also shows that the 302 redirect was _not_ the
cause of the problem, although that really complicated matters for me and my
application.

i've duplicated the output (including debug statements _before_ the html and
body tags) to a static html-file. to keep the php-aspect in, i've also created a
dummy php-file that doesn't do anything but reading the static html-file and
prints it (for those who know php, the file does 

print implode("", file('test.html'));

and that's all)

the static-html is at :

http://tech-no-logical.demon.nl/mozbug/test.html

the php-version :

http://tech-no-logical.demon.nl/mozbug/test.php

(please be gentle, my dsl only has a 128Kbit upload).

when loading the static html-version, access-log shows :

"GET /mozbug/test.html HTTP/1.1" 200 33377
"GET /mozbug/test.html HTTP/1.1" 206 20854

(notice the 206 'partial content')

when loading the php-version :

"GET /mozbug/test.php HTTP/1.1" 200 33390
"GET /mozbug/test.php HTTP/1.1" 200 33390

(notice twice the exact same transfer)

other browsers (IE, lynx) correctly show : 

"GET /mozbug/test.html HTTP/1.1" 200 33377

and 

"GET /mozbug/test.php HTTP/1.1" 200 33390

(i've cut out all loglines about images not having to be reloaded, as that's not
important now).

also, and this is really weird, the problem disappears if the 'debug'-output
before the DOCTYPE declaration is shorter or absent. it seems to have something
to do with the length of that output.

so it's not the redirect, but i don't know what's going on here...

Updated

15 years ago
Attachment #111866 - Attachment mime type: application/octet-stream → text/plain

Comment 7

15 years ago
Related to bug 187612 or bug 168215?

Comment 8

15 years ago
Created attachment 147193 [details]
Shows an HTTP session manifesting this bug

Here is an HTTP session captured by the "Live HTTP headers" plugin for Firefox.

Comment 9

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Reporter: Is this still an issue ?
(Reporter)

Comment 11

7 years ago
amazingly, yes. i hadn't thought of this bug-report for almost 8 years (knowing the issue enabled me to work around it), but i just checked with a largish (x)html file that contains output before the xml declaration and doctype, and the extra load still occurrs...
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 168215
You need to log in before you can comment on or make changes to this bug.