263239 - If you set the SRC of a created image to an empty string, mozilla makes another request for the host page.

Status: RESOLVED INVALID

(Core :: Layout: Images, Video, and HTML Frames, defect)

Description

[James Edwards]

User-Agent:       Opera/7.54 (Macintosh; PPC Mac OS X; U)  [en]
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; rv:1.7.3) Gecko/20040913 Firefox/0.10

Given a test div, and appending an image to it with this code:

  window.onload = function()
  {
    var logo = document.getElementById('test').appendChild(document.
createElement('img'));
    logo.src = 'logo.gif';
  }

Produces expected data in Apache's access log:

  192.168.0.1 - - [04/Oct/2004:23:41:52 +0100] "GET /Ref/empty-src/ HTTP/1.1" 
200 809
  192.168.0.1 - - [04/Oct/2004:23:41:52 +0100] "GET /Ref/empty-src/logo.gif 
HTTP/1.1" 200 3641

But using this code:

  window.onload = function()
  {
    var logo = document.getElementById('test').appendChild(document.
createElement('img'));
    logo.setAttribute('src','');
    logo.src = 'logo.gif';
  }

Produces this:

192.168.0.1 - - [04/Oct/2004:23:43:19 +0100] "GET /Ref/empty-src/ HTTP/1.1" 200 
1507
192.168.0.1 - - [04/Oct/2004:23:43:19 +0100] "GET /Ref/empty-src/logo.gif HTTP/
1.1" 200 3641
192.168.0.1 - - [04/Oct/2004:23:43:20 +0100] "GET /Ref/empty-src/ HTTP/1.1" 200 
1507


Reproducible: Always
Steps to Reproduce:
1. create an img object
2. append it another element
3. set its SRC to an empty string

Actual Results:  
Mozilla made another request for the host page.

Expected Results:  
Not made any request at all.

Comment 1

[Tuukka Tolvanen (sp3000)]

-> layout:images? semi-related, bug 204386, bug 222276

If an img on http://www.brothercake.com/Ref/empty-src/ has its src set to "",
doesn't it make sense for that relative url for to resolve to
"http://www.brothercake.com/Ref/empty-src/" + ""?

Comment 2

[Boris Zbarsky [:bzbarsky]]

Yep, this is invalid per bug 204386.  Empty src means "current page".

Comment 3

[James Edwards]

I don't believe this is invalid bug - "" does not mean current page, it means 
current directory, and this behavior occurs on pages which are not the directory 
root as well as those that are - the host page is called, not the directory 
index.

Even if it isn't technically wrong, it's conceptually wrong - it's not the same 
as the iframe src issue, because iframes can contain pages, but an image cannot 
contain a JS script - there's no way a call to self can come from an image.

Comment 4

[Boris Zbarsky [:bzbarsky]]

> "" does not mean current page, it means  current directory

Sorry, that's not true.  Please see RFC 2396 (eg at
http://www.faqs.org/rfcs/rfc2396.html), section 5.2 ("Resolving Relative
References to Absolute Form").  Rule #2 is:

  If the path component is empty and the scheme, authority, and
  query components are undefined, then it is a reference to the
  current document and we are done.  Otherwise, the reference URI's
  query and fragment components are defined as found (or not found)
  within the URI reference and not inherited from the base URI.

Note the "it is a reference to the current document and we are done" part.

> but an image cannot contain a JS script

A server can serve an image and a JS script for the same URI depending on the
Accept: headers the browser sends (which would in fact be different in Mozilla
for loading an image and loading a script from the same URI).  Please see
HTTP/1.1 content negotiation.  There exist pages on the web that make use of
this functionality and that _do_ use src="" to do it.

Furthermore, there are some image formats (svg comes to mind) that could
actually be authored to be a valid image and a valid script at the same time,
with enough care.

Re-marking invalid.

Comment 5

[James Edwards]

Fair enough, I'll bow to your explanation of facts and conformity with the RFC, 
but I still think this is undesirable behavior and should be "fixed". If there 
are pages out there relying on this, then presumably those pages don't work 
properly in any browser except moz builds later than 1.5

Comment 6

[Boris Zbarsky [:bzbarsky]]

The pages in question aren't exactly trying to work in all browsers.

Comment 7

[James Edwards]

Clearly not ... fair enough to that too.  But this has, and will continue to,  
affect people who aren't expecting it, and it's by no means an obvious thing to 
isolate - it took me half a day just to isolate that this was responsible for 
the excessive number of requests in my clients' server logs and the 
correspondent slowness of their pages.

I think that this is comparable, in impact, to IE's 'continually reloading 
background images' bug, and as Firefox becomes more popular, you're gonna get 
more and more reports for this exact issue.

I think the RFC itself is wrong - it doesn't make sense - in all programming 
languages I'm familiar with, an empty string evalutes to false, so I think it 
makes sense logically for an empty SRC to resolve to no file at all. 
But either way, you have the choice to go against the RFC, just as you can go 
against a w3c standard when to conform makes less sense, and I think you should.

That's all :) I hasten to add - I don't personally care either way, because I 
know about this behavior now.  My concern is for developers who don't, and who 
will end up wasting time tracking it down.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

>in all programming languages I'm familiar with, an empty string evalutes to false

in most that I'm familiar with, it evals to true or is not allowed... consider
C++, where "" is a non-null pointer and thus evals to true; or java, where if
("") does not compile. C# does not allow that comparison either.

Comment 9

[James Edwards]

Okay, well Python, PHP and Javascript are the languages I know, and in all of 
them "" evaluates to false.

Comment 10

[James Edwards]

But that's not the point anuwau.

The point is, people will be (and are being) affected by this.  It causes slow 
loading pages, exaggerated bandwidth demands, and innacurate page-view 
statistics for anyone who unwittingly triggers it.  

Every other browser vendor has chosen to silently fail empty image requests, and 
I really think mozilla should too.  Are the needs of a handful of hardcore 
developers making experimental scripts for other hardcore developers more 
important than meeting common expectation? Is being "right" really more 
important than being sensitive?

You chose to err on the side of expectation with empty iframe SRCs, as mentioned 
in bug 222276, so how is this any different?

Comment 11

[Boris Zbarsky [:bzbarsky]]

> You chose to err on the side of expectation with empty iframe SRCs

Empty iframe SRCs are very very common.  Empty <img> srcs are exceedingly rare,
however.

Comment 12

[Phil Ringnalda (:philor)]

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

Comment 13

[Jo Hermans]

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