58318 - image downloaded twice when size not specified

Status: VERIFIED DUPLICATE of bug 57730

(Core :: Graphics: ImageLib, defect, P3)

Description

[Andrew McMillan]

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.

Comment 1

[Jerry Baker]

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?

Comment 2

[Andrew McMillan]

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.

Comment 3

[Andrew McMillan]

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.

Comment 4

[Doron Rosenberg (IBM)]

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

Comment 5

[pnunn]

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 ***

Comment 6

[Terri Preston]

Verified duplicate

Comment 7

[Andrew McMillan]

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?

Comment 8

[Jerry Baker]

Mass removing self from CC list.

Comment 9

[Jerry Baker]

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