0

I'm generating dynamic images with PHP and using .htaccess to redirect to the PHP-script to use those images in HTML-img-tags, e.g. "/path/something.jpg".

Here's my .htaccess:

RewriteEngine On
RewriteBase /
RewriteRule ^/?([a-z]+)/(.*)$ /?a=$1&b=$2 [L,NC]

Which will have my index.php receive "path" in $_GET['a'] and "something.jpg" in $_GET['b']. This works as expected.

Now, after creating the image with PHP, the output of the image is done like this:

header('Content-type: image/jpg');
header('Content-Disposition: filename="something.jpg"');
echo $binary;
exit;

This also works, I receive an image, the browser displays it.

BUT: When writing a log whenever index.php is called to generate a picture, I see that it's called TWICE for every image that's being created and I can't figure out why. It seems that using header() will make the script start again, because removing header() from the script (and just printing $binary) will result in the script to be executed only once.

The apache-access.log shows the second call as well:

127.0.0.1 - - [18/Sep/2014:12:17:46 +0200] "GET /path/something.jpg HTTP/1.1" 200 19148 "-" "USER_AGENT"
127.0.0.1 - - [18/Sep/2014:12:17:46 +0200] "GET /path/something.jpg HTTP/1.1" 200 19148 "-" "USER_AGENT"

I've been experimenting with .htaccess-settings to prevent this using:

RewriteCond %{ENV:REDIRECT_STATUS} 200
RewriteRule ^ - [L]

in my .htaccess-file (as found here: Apache mod_rewrite REDIRECT_STATUS condition causing directory listing), but to no avail.

I also wonder why this behavior won't result in an endless loop: if .htaccess sends the request to index.php, which executes a header() that will call itself again, why wouldn't this go on forever, but only twice? (on rare occasions even three times, but I wasn't able to reproduce this)

Any hint about why this is happening (and how to fix it!) is very much appreciated. The script works so far, but I'd like to prevent it from generating each picture twice as I'm expecting a lot of serverload once the application is finished.

Community
  • 1
  • 1
Select0r
  • 12,234
  • 11
  • 45
  • 68

1 Answers1

1

You didn't specify which is the browser you tested this in, but my guess is that it's Chrome as others have encountered similar issues with it. There's this bug report on the Chromium bug tracker and this answer on StackOverflow.

Try to remove only the Content-Disposition header and see if it works correctly without that set. You can also try to specify INLINE inside your content disposition header like this:

header('Content-Disposition: INLINE; FILENAME= "something.jpg"');

and see if that fixes anything.

If these don't help, try to use a web debugging proxy tool (like Fiddler or Charles) and post the complete request / response headers for both requests.

Community
  • 1
  • 1
dcro
  • 13,294
  • 4
  • 66
  • 75
  • Removing "Content-Disposition" didn't help, also "inline" didn't change anything. There are differences between browsers, that I didn't notice before: IE will issue only ONE request, Firefox will make two requests with parameters while Chrome will also make two requests, but the second one is missing the parameters ($a an $b are empty)! I found out that this is because Chrome is requesting favicon.ico (which wasn't there), so the problem remains only in Firefox - and only if I request the image directly, if I use a HTML-page and use the same URL in the img-tag, there's only one request! – Select0r Sep 18 '14 at 12:38
  • Is there any difference between the two requests that FF sends in? Are they both identical? As for Chrome, you might want to alter your rewrite rules to avoid the current `catch-all` and only rewrite the requests you're interested in. – dcro Sep 18 '14 at 13:29
  • Yes, the requests are completely identical. As I found out, they only occur in Firefox (even will all addons deactivated) and only if calling the image-URL directly, I get only one request when using the same URL in the src-attribute of the image-tag. I'm starting to think that this is some very strange Firefox-bug ... – Select0r Sep 18 '14 at 14:13