Closed
Bug 263239
Opened 20 years ago
Closed 20 years ago
If you set the SRC of a created image to an empty string, mozilla makes another request for the host page.
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: cake, Assigned: jdunn)
References
()
Details
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•20 years ago
|
||
-> 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/" + ""?
Assignee: general → jdunn
Component: JavaScript Engine → Layout: Images
QA Contact: pschwartau → core.layout.images
Comment 2•20 years ago
|
||
Yep, this is invalid per bug 204386. Empty src means "current page".
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 3•20 years ago
|
||
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.
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Comment 4•20 years ago
|
||
> "" 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.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago → 20 years ago
Resolution: --- → INVALID
Reporter | ||
Comment 5•20 years ago
|
||
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•20 years ago
|
||
The pages in question aren't exactly trying to work in all browsers.
Reporter | ||
Comment 7•20 years ago
|
||
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•20 years ago
|
||
>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.
Reporter | ||
Comment 9•20 years ago
|
||
Okay, well Python, PHP and Javascript are the languages I know, and in all of them "" evaluates to false.
Reporter | ||
Comment 10•20 years ago
|
||
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•20 years ago
|
||
> 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•20 years ago
|
||
*** Bug 278939 has been marked as a duplicate of this bug. ***
Comment 13•19 years ago
|
||
*** Bug 326527 has been marked as a duplicate of this bug. ***
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•