74284 - Referer: not sent for <IMG>

Status: RESOLVED FIXED

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

Description

[Koike Kazuhiko]

http_referer isn't sent for CGI script specified in IMG element's
SRC attribute. See the following page.

http://www.mozilla.gr.jp/~kazhik/testcase/20010401.html


Source: <http://www.mozilla.gr.jp/~kazhik/testcase/20010401b.cgi>
**************************
#!/usr/bin/perl

print "Content-type: image/jpeg\n\n";

if ($ENV{'HTTP_REFERER'} ne '') {
	$img = "ok.jpg";
} else {
	$img = "ng.jpg";
}

open(JPG, $img);
while (<JPG>) {
	print;
}
close(JPG);
**************************

Comment 1

[Lars Linek]

confirming this bug on windows 95 so someone can change OS to 'All'
is it possible to add the keyword regression, because i checked my trunk
builds down to ID 2001032304 and none of them sent the referer, but
mozilla 0.8.1 does it.
this is a pretty bad bug, because some adserver
check the referer if the ad request comes from the correct website... and if
there is no referer, no ad will be displayed... pretty bad... :(
i think this should be fixed at least for 0.9

Comment 2

[neeti]

-->http

Comment 3

[Darin Fisher]

this is unlikely to be a HTTP bug... instead, i point my finger at whomever it
is that is opening the HTTP channel.

-> layout (perhaps)

Comment 4

[Konstantin Riabitsev]

*** Bug 75820 has been marked as a duplicate of this bug. ***

Comment 5

[Konstantin Riabitsev]

This is not limited to <img>'s or CGI's. Actually, every embedded object be it
<img>, <link rel="stylesheet"> or others will not send a "referer:" header
field. I think this is only true for same-site downloads, though, as some
traffic-sniffing shows that if something is linked to an off-site location, the
Referer: does end up going there.

Pretty bad.

Comment 6

[Peter Lubczynski]

I don't think this is layout as it's happening to all sorts of objects and it's 
a regression. Back over to Network for triage. CC:ing some layout folks just in 
case.

Comment 7

[neeti]

-->darin

Comment 8

[neeti]

-->darin

Comment 9

[Darin Fisher]

this is a problem with clients of necko... there is no way to solve this from
within necko as necko has no idea about the toplevel document!

-> browser-general... please don't send this back to networking... there's
nothing we can do to solve this problem!

Comment 10

[timeless]

docshell?

Comment 11

[Adam Lock]

The docshell correctly sets the http referrer on the main channel before telling
the uriloader to load it. I would guess that it is the uriloader that should be
 setting the referrer on subsequent URLs as they are found and need to be loaded.

Reassigning, changing milestone

Comment 12

[Jesse Ruderman]

See also bug 64248, "Browser does not send referer when requesting a javascript 
file."

Comment 13

[Stuart Parmenter]

*** Bug 78216 has been marked as a duplicate of this bug. ***

Comment 14

[neeti]

*** Bug 76723 has been marked as a duplicate of this bug. ***

Comment 15

[Peter Lubczynski]

I'm not too familiar with the image code, but it seems that there could be a 
problem in imgLoader.cpp as I don't see anything about a the http_referer being 
passed to the channel. I traced it to there from the image frame. CVS log shows 
pavlov in the file, over to imagelib.

Could this be causing the random problem of seeing two of the same image loaded? 
Seem that if a banner CGI was feeding the images and it didn't get a 
http_referer, it could possibly hand back the same image over and over.

Comment 16

[Gagan]

->0.9.2 Pavlov let me know if you need help with this. 

Comment 17

[Stuart Parmenter]

how can this be mine?  http does the referer stuff internally.

Comment 18

[Stuart Parmenter]

Attachment: patch to send the referrer info

Comment 19

[Brian Ryner (not reading)]

r=bryner

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

sr=[e-mail]

Comment 21

[Stuart Parmenter]

fixed

Comment 22

[Keyser Sose]

*** Bug 79321 has been marked as a duplicate of this bug. ***

Comment 23

[Stuart Parmenter]

*** Bug 51343 has been marked as a duplicate of this bug. ***

Comment 24

[benc]

*** Bug 76723 has been marked as a duplicate of this bug. ***

Comment 25

[R.K.Aa.]

*** Bug 81339 has been marked as a duplicate of this bug. ***

Comment 26

[Andreas M. "Clarence" Schneider]

*** Bug 80458 has been marked as a duplicate of this bug. ***

Comment 27

[benc]

changed summary for readability+searchability.

+verify me.
If you want networking qa to verify this w/ a trace, kick it over to us.

Comment 28

[Terri Preston]

Kicking over to benc, probably can more reliably verify

Comment 29

[Stephen Smoogen]

Using Blizzards 2001053010 build I am able to verify that it is currently fixed
for the URL's

http://www.creators.com/comics/lib/
http://www.kingfeatures.com/features/comics/babyblue/about.htm

However, this may not be related to the original problem.. if I go to the
pulldown on the menu on
http://www.kingfeatures.com/features/comics/babyblue/about.htm
and click on any other date I get an image that comes up if you have asked for
an illegal date. In netscape-4.77, I get the correct dated image that I am
looking for.


I am guessing that this is due to either what is being sent, or some different
parsing in:

 <script><!--
function linkToWindow(ndx) {
if (ndx==0) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010517' }
if (ndx==1) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010516' }
if (ndx==2) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010515' }
if (ndx==3) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010514' }
if (ndx==4) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010512' }
if (ndx==5) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010511' }
if (ndx==6) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010510' }
if (ndx==7) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010509' }
if (ndx==8) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010508' }
if (ndx==9) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010507' }
if (ndx==10) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010505' }
if (ndx==11) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010504' }
if (ndx==12) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010503' }
if (ndx==13) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010502' }
if (ndx==14) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010501' }
if (ndx==15) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010430' }
if (ndx==16) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010428' }
if (ndx==17) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010427' }
if (ndx==18) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010426' }
if (ndx==19) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010425' }
if (ndx==20) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010424' }
if (ndx==21) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010423' }
if (ndx==22) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010421' }
if (ndx==23) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010420' }
if (ndx==24) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010419' }
if (ndx==25) {
document.images[2].src='http://est.rbma.com/content/Baby_Blues?date=20010418' }

  }
// -->
</script>

and

 <form name="samples">
<select name="strip" size="1"
onchange="linkToWindow(document.samples.strip.selectedIndex)">
<option value>Thursday, May 17, 2001
<option value>Wednesday, May 16, 2001
<option value>Tuesday, May 15, 2001
<option value>Monday, May 14, 2001
<option value>Saturday, May 12, 2001
<option value>Friday, May 11, 2001
<option value>Thursday, May 10, 2001
<option value>Wednesday, May 9, 2001
<option value>Tuesday, May 8, 2001
<option value>Monday, May 7, 2001
<option value>Saturday, May 5, 2001
<option value>Friday, May 4, 2001
<option value>Thursday, May 3, 2001
<option value>Wednesday, May 2, 2001
<option value>Tuesday, May 1, 2001
<option value>Monday, April 30, 2001
<option value>Saturday, April 28, 2001
<option value>Friday, April 27, 2001
<option value>Thursday, April 26, 2001
<option value>Wednesday, April 25, 2001
<option value>Tuesday, April 24, 2001
<option value>Monday, April 23, 2001
<option value>Saturday, April 21, 2001
<option value>Friday, April 20, 2001
<option value>Thursday, April 19, 2001
<option value>Wednesday, April 18, 2001

						</select>
</form>

Please let me know if there is anything I can do to help track this down further
for you.

Comment 30

[Jesse Ruderman]

This bug has regressed.  The new bug is bug 83229, "Referer: not sent for <IMG> 
URLs, v2 (prefs problem)".

Comment 31

[benc]

qa to imagelib.

If you need help verifying or writing testcases, network qa can provide some help.

Comment 32

[Tracy Walker [:tracy]]

mass remove verifyme requests greater than 4 months old