I have been developing an application which refers to an image on an ad server, and the ad doesn't necessarily have the same dimensions each time. I noticed that sometimes the image would be scaled totally wrong, and upon investigation I find that Mozilla is hitting the ad twice, the first time (apparently) to get the dimensions of the image (because my IMG tag doesn't specify them), and then a second time to get the actual image data for display. Once I specified both height= and width= the reference was only being hit once.

I cannot duplicate this with 2000102905 trunk bits. Apache log for image with no dimensions: "GET /test.html HTTP/1.1..." "GET /download.png HTTP/1.1..." that's it. Reporter, do you see this with the latest builds from a directory ending in MTrunk?

A couple of points to also check: firstly, the images in question are negotiated content rather than static. Secondly, it was happening under Linux. The build I was using was just from the nightly/latest directory - I'm not sure if that's MTrunk or not. I'll download an MTrunk build now and take a look. I also wonder if this is a reason I get two "do you want to download images from this location" messages quite often.

I just downloaded MTrunk 2000-10-29-06 giving me: Mozilla/5.0 (X11; U; Linux 2.2.17 i586; en-US; m18) Gecko/20001029 and I am seeing the same problem. When I change my IMG tag to specify WIDTH=468 I only get one hit on my ad server, but when the tag has no WIDTH= specification I get two hits. The IMG tag does have a HEIGHT=60 attribute in both cases. Here's a cut from the HTML in the active document: <table border="0" width="100%" cellspacing="0" cellpadding="0"><tr> <td valign=middle bgcolor="#ffffff" align=center> <a href="http://myads/rd.php?s=c7420691eb6fb3a1a28adb3575dc0270" target=_new> <img src="http://myads/pool.php?s=c7420691eb6fb3a1a28adb3575dc0270;1;3" border="0" height="60" vspace="0"> </a> </td> </tr></table> And here's a cut from the server logs from my application at that point: Oct 30 12:51:57 heidegger apache: pcforum index: Displaying /var/www/forums.parentscentre.org.nz/inc/indexpage.php Oct 30 12:51:59 heidegger apache: adze A delivering: 19 >>c7420691eb6fb3a1a28adb3575dc0270<< ads/pcnz/watyellowsml.gif Oct 30 12:52:00 heidegger apache: adze A delivering: 18 >>c7420691eb6fb3a1a28adb3575dc0270<< ads/catalystbanner2.gif And here's a cut from the Apache logs at that point: 127.0.0.1 - - [30/Oct/2000:12:51:59 +1300] "GET /pool.php?s=c7420691eb6fb3a1a28adb3575dc0270;1;3 HTTP/1.1" 200 2504 "http://myforums/" "Mozilla/5.0 (X11; U; Linux 2.2.17 i586; en-US; m18) Gecko/20001029" 0 myads 127.0.0.1 - - [30/Oct/2000:12:52:00 +1300] "GET /pool.php?s=c7420691eb6fb3a1a28adb3575dc0270;1;3 HTTP/1.1" 200 18917 "http://myforums/" "Mozilla/5.0 (X11; U; Linux 2.2.17 i586; en-US; m18) Gecko/20001029" 0 myads Hope this helps a bit. Thanks.

--> imagelib and making major, if this is real, this is a big bug.

Dont get your shorts in a bunch. The imgcache stores scaled decompressed data. And so, for image requests of different scaled images, it makes separate requests. If you don't specify the image's dimensions, layout has to get the image header to get the dimensions. And, yes, this is a 2 pass process. The only pain occurs when we can't get the data again from the netlib cache. If everything works right, the imglib requests the compressed data from the necko cache. So the request shouldn't trigger a server request. But... here comes the bug.... the necko cache doesn't realize this image request is for the same image it just retrieved and therefore is still 'fresh'. Netlib (incorrectly) thinks it needs to verify this image is still fresh and the only way to do that is to ping the server. I'm making the assumption the server request was a 304.. not a 200. Please correct me if I'm wrong. This bug as described above is a duplicate of 57730. I'm marking this as a duplicate. -pn *** This bug has been marked as a duplicate of 57730 ***

Verified duplicate

Well, correct me if I am wrong, but don't my Apache logs show that this _is_ sending a 200 request in both cases, rather than a 304 the second time?

Mass removing self from CC list.

Now I feel sumb because I have to add back. Sorry for the spam.