php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #16972 1 by1 pixel image problem
Submitted: 2002-05-02 14:56 UTC Modified: 2002-05-03 09:15 UTC
From: robtjenkins at email dot com Assigned:
Status: Not a bug Package: Output Control
PHP Version: 4.1.2 OS: Red Hat Linux 6.2
Private report: No CVE-ID: None
 [2002-05-02 14:56 UTC] robtjenkins at email dot com
Thank your for your help.

I have developed a PHP web tracker (ideal-tracker.com) which relies on a 1 by 1 pixel image placed on the html page being tracked.  I also have another web host for a second site and I run an identical version of the web tracker on this additional site for test purposes.  This second host recently upgraded to PHP 4.12 and now I am having problems with multiple counting of pages.

Basically, the browser requests the 1 by 1 pixel image over and over. I inserted code to kill the script should an identical request come within 15 seconds.  This works fine with IE.  However, Netscape continues to request the 1 by 1 pixel image, and every 15 seconds, a hit is recorded.  The process would basically go on forever unless the user hits the stop button or closes out the browser.

This did not happed in either 4.04 or 4.06.

Do you have any suggestions?

Thanks,

Robert Jenkins

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2002-05-03 00:48 UTC] robtjenkins at email dot com
The more I think about this problem, the more I believe it must be a configuration problem.  However, since I have shared hosting accounts, I am dependent on my web host to set the configuration.  If anyone can think of where the configuration may be set wrong, please let me know, so I can notify my web host (in this case, Linuxwebhost) where to look.

In the meantime, I have found a rather awkward solution to keep the web tracking system working with Netscape.  I have the PHP web tracking script check to see if it has received an identical request from an html page with the 1 by 1 pixel image in the last few seconds.  (Identical in terms of user IP and page visited.)  For IE, I can simply use the die command to stop the process.  However, Netscape will continuously try to call the  1 by 1 pixel image.  I had put in the command print "OK" hoping that would stop the browser.  I noticed that I could direct a 1 by 1 pixel at another PHP script, such as a form mail script which prints html to the screen, and Netscape would not make multiple requests for the image.  So I experimented, and placed the flush command ahead of the print command.  Flush and print together stop the Netscape browser.

However, as I said, that is a very awkward solution.  Hopefully, a better solution can be found, such as finding the source of a configuration error.

Thanks,

Robert Jenkins
 [2002-05-03 04:11 UTC] cynic@php.net
The bug system is not the appropriate forum for asking support
questions. For a list of a range of more appropriate places to ask
for help using PHP, please visit http://www.php.net/support.php
 [2002-05-03 09:05 UTC] robtjenkins at email dot com
But at first I thought it was a bug.  In fact, I'm only speculating that it is a configuration problem.  I would like some confirmation as to whether a bug truly exists which would cause this behavior or whether it is a problem in the configuration.  If it is a bug causing 4.12 to behave differently than earlier versions, then it should be addressed.
 [2002-05-03 09:15 UTC] cynic@php.net
how could anyone tell without seeing a *short* and *self-contained* script first?

I suggest you take this issue to php-general@, and if the conclusion on the list is that it's really a change NOT announced in ChangeLog or NEWS, take it (along with a short script) here.


 [2002-05-03 09:37 UTC] robtjenkins at email dot com
Basically, I have refined the solution mentioned above to successfully override the buggy behavior.  So I'm not going to take it to support.

As for giving a short script, I'm having trouble reproducing the bug with a short script.  In other words, taking an html file with a 1 by 1 pixel image leading to a php file which produces no output to the screen.  The web tracker of which I am speaking is a very lengthy script which I will not try to reproduce.  Suffice it to say, that it worked fine under versions of PHP 3, 4.04 and 4.06.  But under 4.12 it could not work with Netscape due to continuous calls for the 1 by 1 image.  It also had some trouble working with IE.  To trick the Netscape browser, it is necessary to complete the script by telling it to flush and then print something as short as "OK", even though the print output will never show up on the screen.
 [2002-05-03 12:02 UTC] robtjenkins at email dot com
I do intend to report back when my second web host updates to 4.12.  The second web host uses a Rackshack server and (the way I understand it) is waiting for the Ensim Appliance to be updated for the higher version of 4.12.

I want to see if the same error occurs.  If so, then it is more likely a result of quircky PHP 4.12 behavior.  If it does not, then the error is most likely a configuration problem with my first web host.
 [2002-07-05 07:30 UTC] robtjenkins at email dot com
I wanted to add a followup note.  It first appeared to me that a bug existed because the behavior of the script changed when my web host upgraded from 4.0.4 to 4.1.2.  When the upgrade occured, the problem of multiple counting began.

However, I was examining some of my scripts using the tool "Achilles".  I noticed that I was using a foreach statement on an empty array.  Between my two sites, the scripts were identical.  On one site, the array serves a purpose.  On the other, it is not needed and is empty.

The empty array was causing the problem with the script and the multiple counting.  This same array was also empty when the script was being run under 4.0.4 and for some reason was not causing a problem under the earlier version.
 
PHP Copyright © 2001-2022 The PHP Group
All rights reserved.
Last updated: Mon May 23 21:03:42 2022 UTC