ID:               26546
 Updated by:       [EMAIL PROTECTED]
 Reported By:      rcoles at hotmail dot com
 Status:           Bogus
 Bug Type:         GetImageSize related
 Operating System: all
 PHP Version:      4.3.3
 New Comment:

We are not mind readers. Unfortunately. So unless you can come up with
self-contained example script, we have to ASSUME..



Previous Comments:
------------------------------------------------------------------------

[2003-12-07 21:32:01] rcoles at hotmail dot com

In response to my bug report I get this reply:
<--begins-->
Always check that getimagesize() actually succeeded..
(I assume it fails now due the fact that you do a remote request from
the same server to the same server)

And as RewriteCond %{REMOTE_ADDRESS} !^xxx\.xxx\.xxx\.xxx$,
makes it work, there is no bug here.

Hint: Try putting 'error_reporting(E_ALL);' or set it in your php.ini
and you'll see the actual error message..
<--ends-->

Perhaps I should apologies now for the fact that I couldn't cram my
report into a 2 line "sound bite". The original report appears to have
"taxed" the attention span of some.

Please read and read again - inserting the "RewriteCond
%{REMOTE_ADDRESS} !^xxx\.xxx\.xxx\.xxx$" DOES NOT make this application
work. Repeat - DOES NOT.

In order to get this application using getimagesize() to work I have to
remove the RewriteCond blocking blank referrers and UA's.

As for the part about "same server to the same server". I guess its all
in the code. Its also in the report. 

I wrote the app as part of copy and paste operation. As for the
workflow and the way it works, it wasn't really a concern until now.
All I now know, is that if I put in the RewriteCond affecting blank
referrers/UA's the app doesn't work. Take it out and it works. How and
why isn't my problem, that's for the powers that be at PHP. Sorry I
can't be more helpful.

------------------------------------------------------------------------

[2003-12-07 12:08:19] [EMAIL PROTECTED]

Always check that getimagesize() actually succeeded..
(I assume it fails now due the fact that you do a remote request from
the same server to the same server)

And as RewriteCond %{REMOTE_ADDRESS} !^xxx\.xxx\.xxx\.xxx$,
makes it work, there is no bug here.

Hint: Try putting 'error_reporting(E_ALL);' or set it in your php.ini
and you'll see the actual error message..


------------------------------------------------------------------------

[2003-12-06 22:38:56] rcoles at hotmail dot com

BTW this issue is not specific to the particular PHP version as
mentioned in the report. It first cam to my attention while the web
hosting was using 4.2.3 and thought the issue was related to an earlier
getimagesize() issue. My test rig is running 4.3.3 and the web host has
just upgrade to 4.3.4. The results are the same.

------------------------------------------------------------------------

[2003-12-06 22:26:22] rcoles at hotmail dot com

Description:
------------
It appears that certain settings in the htaccess file will produce
unexpected results if an app is using getimagesize(). This issue may
have a bearing on the zero height/width issues reported elsewhere.

The app I've been working on is a random picture gallery. The PHP code
using getimagesize() looks like this:

$maxwidth =180; //modify this figure to suit
$imagehw = getimagesize($image[$r]);
$imagewidth = $imagehw[0];
$imageheight = $imagehw[1];
if ($imagewidth>$maxwidth) {
   $imageprop = ($maxwidth*100)/$imagewidth;
   $imagevsize = ($imageheight*$imageprop)/100;
   $imagewidth = $maxwidth; 
   $imageheight = ceil($imagevsize);
}

[$r] is an image in an array. The rest of the code auto-resizes the
image and maintains a constant aspect ratio.

Looking over my web access logs in get this:

web host IP address - - [06/Dec/2003:02:14:52 -0600] "GET
/images_dir/some_sub_dir/IMG_2581.jpg HTTP/1.0" 403 - "-" "-"
ISP's IP address - - [06/Dec/2003:02:14:53 -0600] "GET
/images_dir/some_sub_dir/IMG_2581.jpg HTTP/1.0" 304 -
"http://www.xxx.com/some_dir/s0me_page.php"; "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0; Q312461)"

Note the "403 - access denied" in the first line.

In my htaccess file I have the following:

# Forbid if blank (or "-") Referer *and* UA
RewriteCond %{HTTP_REFERER} ^-?$
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F]

These lines forbid/ban blank referrers and UA's. 

As far as I can understand and thus, now assume, while using
getimagesize, the web host's server does a "GET" to get the image
before passing it to the code and then serving it to the browser. While
doing the "GET" - and because it's an "internal process" - there would
be no need for a UA. The htaccess file picks this up and issues a 403.
The image reference is then passed to the browser but no image appears.
Well, its does but appears as a pixel dot. No error warnings or notices
are produced with this error.

I have tried adding the following line to the htaccess file to try and
by-pass this issue:

RewriteCond %{REMOTE_ADDRESS} !^xxx\.xxx\.xxx\.xxx$

xxx being the host IP address. Have had NO success with this so far.

Expected result:
----------------
With these lines removed from my htaccess file:

# Forbid if blank (or "-") Referer *and* UA
RewriteCond %{HTTP_REFERER} ^-?$
RewriteCond %{HTTP_USER_AGENT} ^-?$
RewriteRule .* - [F]

this is what I get in my web access logs:

web host IP address - - [05/Dec/2003:22:11:10 -0600] "GET /images/some
sub_dir/IMG_2295.jpg HTTP/1.0" 200 49254 "-" "-"
ISP's IP address - - [05/Dec/2003:22:11:11 -0600] "GET /images/some
sub_dir/IMG_2295.jpg HTTP/1.0" 304 -
"http://www.xxx.com/some_dir/some_page.php"; "Mozilla/4.0 (compatible;
MSIE 6.0; Windows NT 5.0; Q312461)"

Note the "200" passed on each line. In other words, the app works as
designed

Actual result:
--------------
With the above htaccess RewriteCond in place, this is what I get at the
browser end:

<img src="http://www.xxx.com/images_dir/some_sub_dir/IMG_3235.jpg";
width="" height="" alt="This is a Random Image" />

Note the empty width and height parameters.


------------------------------------------------------------------------


-- 
Edit this bug report at http://bugs.php.net/?id=26546&edit=1

Reply via email to