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

RESOLVED INCOMPLETE

Status

()

--
major
RESOLVED INCOMPLETE
15 years ago
9 years ago

People

(Reporter: festival, Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Comment 2

15 years ago
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)

Comment 3

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

Comment 4

15 years ago
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.

Comment 5

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

Comment 6

15 years ago
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.

Comment 7

15 years ago
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

Comment 9

14 years ago
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?

Comment 10

14 years ago
See bug 272990 for a similar issue.

Comment 11

14 years ago
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.

Comment 12

12 years ago
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: networking.http → networking

Comment 13

9 years ago
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

Comment 14

9 years ago
Zook is also gone and 212.1.43.17/moz17bug.html isnt' available
=> incomplete
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.