|Cannot Get Image Redirect or Rewrite to Work|
| 8:01 pm on Feb 4, 2014 (gmt 0)|
I have spent hours upon hours (yes, really) trying to solve this myself and nothing is working for me.
I'm messing around with my (free) website before I actually build it to make sure everything is going to work the way I want. So I have this particular image and when it's accessed or loaded in the browser, it redirects to a php tracker to obtain user info for security purposes (this will be a family reunion site).
I have two images set up and each one goes to a different tracker. The first tracker is located on another website (one of those free tracking websites). When it redirects, the transparent gif image displays as it should (nothing shows up). The other tracker is on my website, and when the image redirects to it, a broken image icon (or whatever it's called) shows up instead of the image. I can't have that happen and don't know why it's happening or how to correct it. It doesn't happen with the first image, so why is this one doing it?
I've tried to figure out why it's happening, but I'm still a novice so I'm not getting anywhere. So then I thought maybe I could "fix" it by somehow using htaccess to replace the broken image with another image. That's not working for me either. I used some code that I found here in these forums, but I can't get it to work. I've tried looking for other htaccess code and tweaking it to suit my needs and I can't get anything to work without disabling the tracker.
So does anyone know how to correct either of my two problems? I either need to figure out why the second image won't display or I need to figure out how to replace the broken image with another image without disabling the tracker. I'm beginning to think this is impossible. Or maybe htaccess is not the way to go.
| 9:09 pm on Feb 4, 2014 (gmt 0)|
Welcome to WebmasterWorld, lbblu78!
what have tried so far?
What status code did you get for each of the response cases?
| 10:33 pm on Feb 4, 2014 (gmt 0)|
I know what you're describing. The <noscript> branch of piwik does the same thing, using a php file inside <img> tags, and I use it myself for some personalized tracking. To this day I get several requests a month for an image file that hasn't been used for tracking since late 2012. (It's some kind of archiver. Canadian, so I leave them alone.)
The main thing that's happening is: the page is trying to display the image, and can't find it, so it shows the "can't load the image" icon instead. The size of this icon is fixed, so even if the image is 1x1 pixel, the icon is 16x16 or whatever the browser says.
Now, when you're using an administrative gif (not the correct technical term, sorry) it's hardly ever necessary to have a collection of physical image files. Instead, each host's htaccess will have something like this--here cutting and pasting from my own version--
RewriteRule ^pictures/(hotlink|smallgifs/onedot) - [L]
RewriteRule ^smallgifs/dot\d+\.png /pictures/smallgifs/onedot.png [L]
RewriteRule ^smallgifs/dot[\w-]+\.gif /pictures/smallgifs/onedot.gif [L]
The first rule is your "the buck stops here" rule-- same thing you'd have with error documents. The second pair collapses all requests to a single physical file. (In my rule, the gif and png are separately rewritten because they tracked different information and therefore had different caching times. These follow the physical file, not the request.)
I'm a little worried about this. Who's redirecting and why? Trackers should happen invisibly in the background; a redirect is by definition visible.
The one thing you don't make clear in your first post is: Does the image on your own site physically exist? If you're rewriting, look only at the target of the rewrite.
:: detour to test site to confirm something ::
Well, ###. I didn't see what I expected to see. In webkit-based browsers (Safari, Chrome, new Opera) and in MSIE 5, the bad-image icon shows up if there's a problem with the image file. (I tested both ways: using a bum filename, and explicit 403.) Don't know about newer MSIE. In Mozilla-based browsers (Firefox, Camino) and in Opera <=12 the alt text is used instead. This strikes me as a far better solution; does webkit reserve the alt for when the user has expressly chosen not to display images?
In your case the browser-specific behavior is useful because it alerts you to a problem. A different browser would display the alt text (for admistrative gifs, it should be "" the empty string) and you wouldn't see that there's an issue.