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.
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
almost forgot : this report is based on 1.3alpha, but the problem also occurs with version 1.2.1 (i upgraded before submitting this)
nice bug report, does it also happen with latest nightly build ? http://ftp.mozilla.org/pub/mozilla/nightly/latest-trunk
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.
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
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...
Attachment #111866 - Attachment mime type: application/octet-stream → text/plain
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.
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
Reporter: Is this still an issue ?
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.