Closed Bug 215948 Opened 22 years ago Closed 16 years ago

non-stopping (recursive?) transferring from server when refreshing html-called php-generated picture(s)

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED INCOMPLETE

People

(Reporter: festival, Unassigned)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3.1) Gecko/20030425 When I REFRESH a page where I call via html a picture generated by php (ie: img src ="picture_generating_php_page.php", the server keeps transferring to me, even after the refresh. Plus, the stop button (the cross-like one) is disabled. N.B. 1) not only the status bar indicates that the server is transferring : the server is really transferring (easily noticiable if you look at the free ressources on the server and what is actually taking all the ressources). 2) I do not have the same problem using Internet Explorer 6 and (some versions of) Netscape, which is why I dare contacting you. Reproducible: Always Steps to Reproduce: 1. I'll give a basic php picture-generating code,taken from a basic tutorial, but this code can be replace by any valid php picture-generating code. Let's name the file "test_image_string.php". <?php header("Content-type: image/png"); $width = 200; $height = 100; $image = imageCreate($width, $height); $transparent = imageColorAllocate($image, 255, 0, 0); $black = imageColorAllocate($image, 0, 0, 0); imageColorTransparent($image, $transparent); imageString($image, 1, 10, 10,"police 1", $black); imageString($image, 2, 10, 25,"police 2", $black); imageString($image, 3, 10, 40,"police 3", $black); imageString($image, 4, 10, 55,"police 4", $black); imageString($image, 5, 10, 70,"police 5", $black); imagePNG($image); imageDestroy($image); ?> 2.I'll give a very short html code to call the php (I know it's not W3C compliant but it's valid code nevertheless). Let's call the file "test.htm" <HTML> <BODY> <TABLE cellspacing="1" cellpadding="5" border="1"> <tr> <img src="test_image_string.php"> </tr> </BODY> </HTML> 3. call test.htm : you should see a picture with 5 strings printed in it refresh the page : you should refresh but also experience the side-effects I mention in this report. Actual Results: The server keeps transferring nearly endlessly which causes any other request/call to be slowed down. Moreover, the client is also (heavily) slowed down since the server keeps using the bandwith. Expected Results: Just refresh (once). And even the server's transferring couldn't be helped : the cross-like stop button should be enabled to enable forcing stopping the transfert. I'm not sure this is a bug, it is even possible (though I doubt it) that my code wasn't valid. Moreover, it could be due to the sheer php interpretation by the server. BUT : 1) The same phenomenon kept happening on 3 different servers (one running under a Debian (I don't know the build unfortunately), one under a Mandrake 9.0, and one under Windows 2000 Advanced Server. All servers were using PHP 4.3.1 Apache 1.3.28 2) As I told before, the problem didn't appear using IE 6 and (some versions of) Netscape. 3) I'm not sure of this but it seemed that setting all caches to zero nullified the harmful side-effects of the refresh. Still, I can't confirm this as I have no time left to make numerous experiments to isolate if the cache was indeed the cause or if it was another parameter that had changed at more or less the same time or the server and/or the client
Is it possible to make the testcase publicly available? What are your HTTP connection settings (protocol version, pipelining enabled?, etc)?
I wish I could, but I discovered this side-effect while working this summer in a computer-science lab and I don't have access to all the info you ask for and I'm very unlikely to obtain it. On the other hand, I've experienced this bug even at a friend's place where we develop using a small server running a Debian (with no advanced configuration)so I assume the side-effects are mostly configuration-independant (but I can be wrong in thinking that, after all I have no complete proof of this)
>The server keeps transferring nearly endlessly which causes any other >request/call to be slowed down. Moreover, the client is also (heavily) slowed >down since the server keeps using the bandwith. i'm curious... how did you determine that the browser was continuously transferring data from the server? i ask because we have had bugs that caused the browser to report that it was transferring data when indeed it was not. did you inspect packet traces or server logs?
Unfortunately, I'm not an expert in networks and most of all, I have very little time (with appropriate hardware) apart from my job time... which is dedicated to the job, so I didn't make any comprehensive tests about this. I'll tell you what I know since I didn't take the time to inspect server logs (and all the more so didn't trace the packets). From what I've just said, you can easily deduce that I can't establish that it was the browser that was continuously transferring data from the server. So it may indeed be just a cosmetic bug (which I hoped at the beginning and still hope though I'm doubtful). But, a few things annoy me if it's just a cosmetic bug : 1) The server was as far as I could notice indeed transferring (at least when I encountered the side-effects on a closed network while I was the only one connected to the server : I said I didn't inspect the logs but I had some little soft monitoring the bandwith and the bandwith was quite jammed on both sides. Plus, the activity level of the server daemons make me believe it was not a dream.) 2) If it is due to the server and not the client (which would be more logical since after all some php is quite in the center of the matter), why on earth did it happen only on refreshes, and only with mozilla and on some versions of netscape ? I'm ready to believe the bug is just a cosmetic one. I really wish it is so... but if it's just cosmetic somebody explain me ! Maybe I'm just dumb but (to the extent of my knowledge), something's not fitting. I realize I'm not able to provide with much valuable info but I beg you to understand that I already work about 11-12hrs each day since 2weeks and when i stop working, I'm unwilling to continue using any computer.
thanks for the additional info. it does indeed sound like something more than a cosmetic issue. when i get a chance, i will try to replicate your setup... i'm just not sure when that will happen because i'm pretty busy with other bugs at the moment.
Thanks your understanding and for making mozilla even better than it is now. Anyway, I will try to get myself a better understanding of the question and give you more precise details... but nevertheless I can't let you expect anything before at least 2 weeks.
Should this move to Neworking: HTTP? I'm marking this new since it has a thorough description of the problem, looks valid and needs to get out of the wasteland of Browser-General unconfirmed bugs. festival@graffiti.net, have you had a chance to play around with this again at all?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please select a component if you confirm a bug. Confiming means more than reproducing the bug, you must search for dupes and you must find the correct component if possible. Networking is indeed a good start for this.
Assignee: general → darin
Component: Browser-General → Networking: HTTP
QA Contact: general → httpqa
Hello, I've written a webcam Page and in the Bottomline there should be the time since the next Reload. Maybe its the same bug. After the first Reload the Text Transferring data is displayed and not hidden again. In older mozilla releases this works. Look at the Page 212.1.43.17/moz17bug.html to test this. Its Bug No2 on the Page.... Maybe you can confirm Bug No1 also?
See bug 272990 for a similar issue.
I can help you with that on Monday or Tuesday but I have not yet test it or confirm that this problem is still reproducable. I'm off from work for the weekend. Just tell me what kind of data do you need to gather and how. (Like tracing or something)... Reporter, can you tell me what php version was being used when you have this problem. You can find out by typing in "php -v" for Unix/Linux, as for Windows it might work but I haven't tried it myself.
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking
both festival and klaas' address bounce bug 272990 mentioned in comment 10 went expired => unco, perhaps more appropriate as incomplete?
Status: NEW → UNCONFIRMED
Ever confirmed: false
Zook is also gone and 212.1.43.17/moz17bug.html isnt' available => incomplete
Status: UNCONFIRMED → RESOLVED
Closed: 16 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.