Closed Bug 281150 Opened 20 years ago Closed 12 years ago

favicon.ico image still used even if the image is sent with 404 status

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: ben, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug,
URL
)

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050127 Firefox/1.0 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5) Gecko/20050127 Firefox/1.0 My website has no favicon.ico, so I was surprised to find that Firefox would display one that seemed to match my site. I realized that it was a shrunk down version of my 404 image. My webserver generates and sends images instead of standard HTML error pages if the browser's accept header tells the webserver that it prefers an image. I added that feature precisely because I noticed that gecko was smart and would send more appropriate accept headers for inline images, and I thought that my webserver should be just as smart and satisfy its request. Yes, it does send these images with 404 status codes. To see what the 404 images look like at full size, see the examples on this page: http://tautology.org/software/woolweb/ Or just link to a non-existent file on my domain in an img element. Reproducible: Always Steps to Reproduce: 1. Load http://tautology.org/ 2. Look at the tab image Actual Results: The 404 image appears. Expected Results: It should act as if no favicon.ico were found.
this seems like a weird case to handle... we ask for an image, and get one back, to check whether it is returned with a 404 is essentially unexpected.
Yeah, I wasn't sure whether to file it as minor or trivial, since it is almost a feature. Now that I think about it more, it seems more arguable than I thought. I am not even sure if displaying the default is actually preferable to displaying the 404 image. The only reason I can think of for displaying the default is that the default exists, and that it represents a page with no favicon. I guess the question is: does the default represent no favicon, or no image in response to the request for the favicon? I guess you could say that the default just represents no image, and file this as invalid. I am also not sure whether the issue is with Firefox or whether the code is actually in Gecko. I figured it was UI, and I didn't think that Gecko would handle that, so I filed it as a problem with Firefox.
I agree. The problem boils down to what does the spec. say: If it says that only images returned with 20x or 30x codes may be used, then we can can adhere to that. If it says not to check the return code (but perhaps check other things such as dimensions) then we can do that. Of course, THERE IS NO SPECIFICATION. The behaviour expected here is essentially indeterminate. A web author may expect to be able to mark his favicon repsonses with a response code, but a browser vendor or end user may feel that any image is better than none. Personally I tend to agree with the latter plan, but without a spec. it is meaningless to discuss it. Conceivably, web authors might be counselled never to return an image in these circumstances unless they are happy for it to be used. I would recommend WONTFIX on thre basis that is wasteful to expend developers' time and attention on undefined behaviour, but it isn't really that important, is it?
However, one could make the argument that 404 is defined as "file not found", so if the favicon fetching code is looking or a favicon file, and a 404 is returned, then it should behave as if it didn't find a favicon. That much is covered by the spec. Also, the request resulted in an error. Even though the favicon fetching code found usable data, it is storing an error message as the site's icon. Even though that part isn't covered by any specification, it is certainly covered by just thinking about what is actually happening, and realizing that it isn't the appropriate way to handle an error message. Even though the spec says "User agents SHOULD display any included entity to the user.", I don't think that displaying it as a tab icon is appropriate. HTML error pages for favicon 404s aren't displayed anywhere. I think that error entities don't need to be displayed because the request was initiated by the browser, and not the user directly, so as long as the browser knows it is 404, that is fine. Developers work on undefined behavior all the time. The favicon feature itself is undefined to my knowledge. I don't see how that makes it meaningless to discuss. I understand that it is a minor bug, and that it is extremely low priority, but why not just leave it open as a futured, very minor bug until someone fixes it, even if never? I have never written C++ software before, but this seems like it wouldn't be that hard for me to fix. I could give it a go. I am not really expecting anyone to spend time working on this. I just wanted to let the issue be known.
Just a note that Galeon does not show my favicon error images in the tabs nor bookmarks. That is probably why I didn't notice this until I used Firefox while staying at my brother's place.
> to check whether it is returned with a 404 is essentially unexpected. Sorry but this is a scandalous reply. A developer who thinks that a browser should ignore error codes should be fired immediately.
> to check whether it is returned with a 404 is essentially unexpected. Sorry but this is a scandalous reply. A developer who thinks that a browser should ignore error codes should be fired.
(In reply to comment #7) > ... > > Sorry but this is a scandalous reply. A developer who thinks that a browser > should ignore error codes should be fired. Maybe, but Mike Conner was not suggesting ignoring error codes. At the moment, the browser asks for an image, gets an image and uses it. No 'error code' is involved: IMHO in the absence of a spec. we cannot improve on this. Note that that have been few, if any, comments dealing with this. I suspect that developers and web authors do, in fact, understand that this area is under-specified and that any reasonable behaviour should be accepted. If you are having problems, you might want to adjust your server to not return an image when asked for a /favicon.ico , just the 404 HTTP repsonse. Do you really think that this is not WONTFIX?
The point is that the fact that no error code is involved is a compliance bug. BTW, Galeon handles it correctly. The spec is perfectly clear what to do. I am just doing exactly what the spec told me to do. Your browser asks for a file. I say it is not there. Your browser asks for an image, so I gave it an image saying that it is not there, just like you would have gotten HTML if you would have asked for that. I am following the spec exactly, and it results in unexpected behavior in your browser. There is a problem, and it isn't on my end. I am NOT going to adjust my server to do the wrong thing when I worked so hard to make it do the right thing. I am not telling you which bugs to work on, or what to put in your product, but it is clearly a bug in the browser.
(In reply to comment #8) > Maybe, but Mike Conner was not suggesting ignoring error codes. Of course he did. Moreover, ignoring error codes is exactly what Firefox currently does. It receives a 404 Not Found error code and the action taken is: "Who cares what the server says? We got some file so let's use it." The Mozilla Foundation should realize the enormous responsibility it has. Their product will soon affect a major potion of the traffic and infrastructure on the World Wide Web. Incompetent developers should be fired before it is too late. > At the moment, the browser asks for an image, gets an image and uses it. No > 'error code' is involved: IMHO in the absence of a spec. we cannot improve > on this. Note that that have been few, if any, comments dealing with this. I > suspect that developers and web authors do, in fact, understand that this area > is under-specified and that any reasonable behaviour should be accepted. > If you are having problems, you might want to adjust your server to not return > an image when asked for a /favicon.ico , just the 404 HTTP repsonse. > Do you really think that this is not WONTFIX?
(In reply to comment #9) > ... . Your browser asks for an image, so I gave it an image saying that it is > not there, just like you would have gotten HTML ... > I am not telling you which bugs to work on, or what to put in your product, > but it is clearly a bug in the browser. I am sorry that you are upset, but I was going by your comment 2 . If you really feel that the 404 response code should take precedence over the response body, then you may find that most end users and some developers will disagree with you. I am prepared to look at both sides, but I feel that if you return an image when asked for /favicon.ico then you should not be surprised if the browser uses it. In short, you are saying "I have no favicon.ico and here it is", the browser replies "Thanks, mate". To me, this is ambiguous: maybe to you it is not. If you want, you can dup this against Bug 260500 "Browser requests favicon.ico on every page view", but that bug is mainly about a complaint that a 404 response to /favicon.ico should convey "No, and stop asking".
(In reply to comment #10) > (In reply to comment #8) > ... > > The Mozilla Foundation should realize the enormous responsibility it has. > Their product will soon affect a major potion of the traffic and > infrastructure on the World Wide Web. Incompetent developers should be > fired before it is too late. I am only posting again to repair my omission in not referring to the woeful Bug 260500 which has some points in common with your post. I am not sure that I can help you with a potion, but for a potation, see http://www.spreadfirefox.com/?q=node/view/16680 . This Report is unlikely to result in any improvement to Firefox. If you have a reference to a specification that Firefox violates, please post a URL that covers it (preferably in a new Bug Report). Unlike Bug 260500 where Firefox is clearly wrong, which may even be a regression and for which there is no credible explanation unless the developer(s) concerned are actually unaware of the problem; this bug covers a case where there are two plausible ways of construing what to do, Firefox could reasonably pick either, and has arguably chosen the better. I feel that this Bug is WONTFIX, but it could be INVALID or even a Dup of Bug 260500. Otherwise, I assure you that you have the last word if you want it
> If you really feel that the 404 response code should take precedence over the > response body, then you may find that most end users and some developers will > disagree with you. Let me summarize and demonstrate the way you program: 1) You call read (fd, read_buffer, len); 2) The system returns an error. 3) Coincidentally, read_buffer seems to contain some valid image, so you *disregard* the error code and use the image. (Let me remind you that I am not involved in this case. My server does not return custom errors images. I am only a bystander who had to respond to such a scandalous statement.) > If you really feel that the 404 response code should take precedence over the > response body, then you may find that most end users and some developers will > disagree with you. I am prepared to look at both sides, but I feel that if you return an > image when asked for /favicon.ico then you should not be surprised if the > browser uses it. In short, you are saying "I have no favicon.ico and here > it is", the browser replies "Thanks, mate". To me, this is ambiguous: maybe > to you it is not. > If you want, you can dup this against Bug 260500 "Browser requests > favicon.ico on every page view", but that bug is mainly about a complaint > that a 404 response to /favicon.ico should convey "No, and stop asking".
> "If you really feel that the 404 response code should take precedence over the response body, then you may find that most end users and some developers will disagree with you." The HTTP spec agrees with me, and that is what actually matters. The problem is in your misunderstanding of the HTTP spec. The response body does not conflict with the response code. They are not mutually exclusive. The response body and the response codes go together, and response bodies are not necessarily the requested resource. If your code is not aware of that, it is simply not standards compliant. When you ask for a resource, you cannot expect to get the resource you are asking for if the status code is not 2xx. The spec makes this perfectly unambiguous: http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2 For 2xx: 'This class of status code indicates that the client's request was successfully received, understood, and accepted.' For 200: 'GET an entity corresponding to the requested resource is sent in the response;' It specifies only in 2xx that entities corresponding to the requested resource are to be sent, and it specifically says that the entity sent does NOT match the requested resource for 404: For 4xx: 'The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.' For 404: 'The server has not found anything matching the Request-URI.' > "I am prepared to look at both sides, but I feel that if you return an image when asked for /favicon.ico then you should not be surprised if the browser uses it. In short, you are saying "I have no favicon.ico and here it is", the browser replies "Thanks, mate". To me, this is ambiguous: maybe to you it is not." No. According to the spec, I am saying "I have no favicon, and here is an error message in the form you asked for.". What servers usually say is "I have no favicon, and here is an error message.". What the spec requires is "I have no favicon, and there SHOULD[1] be an error message which SHOULD[2] be in the form that you asked for." If the server satisfies what it SHOULD, your browser will get a messed up favicon. The only reason why it doen't happen more often is simply because servers aren't doing what they SHOULD. And that is what I do: "include human- readable information which will explain the unusual status.". Also note that "applications MUST understand the class of any status code" makes it pretty clear that you are not being standards compliant. Would you say that your code understands the 4xx class? I don't think it does. [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html 'HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, applications MUST understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response MUST NOT be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents SHOULD present to the user the entity returned with the response, since that entity is likely to include human- readable information which will explain the unusual status.' [2]http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1
(In reply to comment #14) > In such cases, user agents SHOULD present to the > user the entity returned with the response, since that entity is likely to > include human- readable information which will explain the unusual status.' Precisely. That entity can be an image. Firefox for some reason thinks this error-code-associated entity should be used as favicon.ico.
Assignee: bross2 → nobody
Confirming.
Status: UNCONFIRMED → NEW
Ever confirmed: true
The given testcase in comment 1 appears to no longer exist. This is a new testcase that confirms that the issue still appears on trunk. http://users.blueprintit.co.uk/~dave/testcases/bug281150/
URL: http://tautology.org/ → http://users.blueprintit.co.uk/~dave/...
OS: Linux → All
Hardware: PC → All
See also bug 443648 and bug 299138.
Depends on: 299138
Version: unspecified → Trunk
Blocks: 120352
No longer blocks: acid3
Blocks: acid3
Needs a testcase
Flags: blocking-firefox3.2?
Testcase at http://acid3.acidtests.org/ (there's no favicon, server returns a cat on a read background as the description for error 404, note the difference in favicon compared to reference rendering). The page given in the URL works as the testcase, too.
(In reply to comment #21) > Testcase at http://acid3.acidtests.org/ (there's no favicon, server returns a > cat on a read background as the description for error 404, note the difference > in favicon compared to reference rendering). The page given in the URL works as > the testcase, too. Confirmed! Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.8) Gecko/2009032609 Firefox/3.0.8
Fixed in 3.5? Testcase from comment #21 has no favicon displayed in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2. Needs another testcase, or a reference to a duplicate bug which has been fixed..
(In reply to comment #23) > Fixed in 3.5? Testcase from comment #21 has no favicon displayed in > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.2) Gecko/20090729 > Firefox/3.5.2. Needs another testcase, or a reference to a duplicate bug which > has been fixed.. Confirmed. Mozilla/5.0 (X11; U; Linux x86_64; en-GB; rv:1.9.1.2) Gecko/20090803 Ubuntu/9.04 (jaunty) Shiretoko/3.5.2
The issue in the bug is NOT fixed. Favicon images that are returned with a 404 error code are still being displayed. The only reason this issue is no longer occurring in the ACID3 test is because of a server configuration change (which I think is unintentional) on the server that hosts the official ACID3 test.
What about the testcase in the URL field, which also seems to work fine?
Flags: blocking-firefox3.6? → blocking-firefox3.6-
(In reply to comment #26) > What about the testcase in the URL field That page doesn't exist anymore.
URL: http://users.blueprintit.co.uk/~dave/...
You could use the following URL: http://xela.org.ua/favicon/
Component: General → ImageLib
Flags: blocking-firefox3.6-
Product: Firefox → Core
QA Contact: general → imagelib
Why is this an imagelib issue? Imagelib doesn't want to prevent 404 images from being rendered it's pretty much a requirement to do that for an image loaded in a toplevel document. And as I said in bug 299138 various imagelib consumers need different behaviors here, and we need imagelib API for that, but bug 299138 covers that. Once that bug is fixed, the favicon consumer here will need to communicate what it wants to happen to imagelib, and that's what this bug is about.
Component: ImageLib → General
Product: Core → Firefox
QA Contact: imagelib → general
And in particular, note that this bug is asking for the favicon to behave differently than <img> does in HTML. That's not something imagelib can figure out for itself, obviously; the favicon code will need to very explicitly tell it to have the different behavior.
This is not worth fixing. The "bug" has user advantage when it does crop up an it probably crops up rarely.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
Since when the standard compliance started to matter only for the problems that trigger frequently? :(
There is no standard covering the browser UI.
Comment 14 states what w3c standards does this violate. How is this an UI bug?
1) There is no W3C standard listed in comment 14. There is an IETF standard. 2) This bug is all about what's shown in the Firefox UI. There is no standard for that. Nothing requires us to show the favicon.ico from the site, for example. We do it in some cases because it's useful. We might not do it in other cases if we think it would be a problem. It's totally up to the UI what it wants to do here. The IETF standard doesn't cover the behavior here, just like it doesn't cover the behavior of what "curl" should do with a 404 response. And in fact curl has options that can change its behavior in response to a 404: you can choose to get the response body and process it or you can choose to have curl print an error and return a failure code, or you can choose to have curl just return the failure code. You can make the argument that the current behavior is not useful or not helpful, but it's certainly not violating any standards I can see, just like curl http://example.org/nosuchpage | parse-the-html is not violating standards.
The problem here is not in displaying something. It is in _interpreting_ the 404 response as favicon. Displaying it wrongly (as favicon) is just a consequence. How to _interpret_ things, is perfectly speced.
I went through this a week ago. I removed my website's favicon months ago but firefox kept showing the old favicon. I added a new one last week and firefox updates it's storage to the new one. The question is. is there anything against caching responses with 404 headers (not expiring them).
(In reply to Boris Zbarsky [:bz] from comment #35) > 2) This bug is all about what's shown in the Firefox UI. There is no > standard for that. Hixie writes: --- A favicon that is a 404, just like an <img> that is a 404, or an <object> that is a 404, should be dropped. In the case of favicon, it should cause us to use the default icon. --- If the standard says it should be dropped and you display it (and, in particular, display as being favicon) - is it still an UI issue? I doubt.
> is it still an UI issue? Yes, it's completely a UI issue, since it's about what's being shown in the UI.
If the standard says it should be dropped, then displaying it is a clear violation. The standard only allows UI to use the default icon. It is up to UI to display the default icon or not, but UI can't display what was dropped on a parsing stage.
> Yes, it's completely a UI issue, since it's about what's being shown in the UI. So there are no standards for what's show in the UI. Wouldn't it be simpler to just show a blank page? But a blank page isn't useful, so it would be better if Firefox displayed something useful. The best way to be useful is to display what the web site specifies. In this case the web site clearly specifies (in a well-documented standard approach) "there is not favicon", but Firefox goes against the explicit and well defined statement of the web site, chooses an inappropriate image, and treats the image as a favicon. The current behavior is disrespectful to the web site developer, and to the person browsing the site.
(In reply to B.J. Herbison from comment #41) > > Yes, it's completely a UI issue, since it's about what's being shown in the UI. > So there are no standards for what's show in the UI. Wouldn't it be simpler > to just show a blank page? What kind of blank page are you talking about? The default icon should be used as favicon, and that's all.
The problem is the backend. The UI is simply affected by it. Does anyone know if http standards content delivered with 404 header can be cached/stored? If yes, then there is no issue here. If the standard says content delivered with 404 header cannot be cached, then we have a legitimate bug. Any experts? If not, anyone knows where to ask?
This was only ever reported as an issue because the acid3 test pinged it as an issue. The test was later revised such that it no longer is. This is NOT a standards issue. Please give it up.
(In reply to Bill Gianopoulos [:WG9s] from comment #44) > This was only ever reported as an issue because the acid3 test pinged it as > an issue. The description of this bug and a few subsequent comments clearly shows the otherwise. What is a surprise of a web developer who sees his generic 404 image being used as favicon? What if he put some "****" on a 404 image? :) > This is > NOT a standards issue. Please give it up. Hixie says the response body should be dropped. Why is this not enough?
(In reply to Stas Sergeev from comment #45) > What is a surprise of a web developer who sees his generic > 404 image being used as favicon? What if he put some "****" > on a 404 image? :) [I'm starting to think you might be a troll.] Sure, web developers can do whatever they like, including providing sketchy favicons (with or without 404 responses). You're not making a compelling case with that scenario. > > This is > > NOT a standards issue. Please give it up. > Hixie says the response body should be dropped. "Hixie says" is not a web standard. See also Comment 35 part (2). Note also that your Hixie-quote is from bug 299138, which is about the <img> element, not favicons. But long as you're quoting from that bug, have a look at the *actual* spec-quote later in that bug -- bug 299138 comment 16: "Note: This allows servers to return images with error responses, and have them displayed." (Again, that's <img>-specific, and favicon-display-behavior doesn't seem to be specified anywhere; I'm only bringing it up since you're quoting that bug. And per comment 30, it seems odd that we'd be inconsistent between <img> vs. favicon.)
(In reply to Daniel Holbert [:dholbert] from comment #46) > "Note: This allows servers to return images with error responses, and have them displayed." Doesn't "displayed" mean displayed as part of the page? Favicons aren't displayed as part of the page anywhere. Favicons are put outside the frame of the page *if they exist*, and in this case the favicon explicitly doesn't exist. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.5 10.4.5 404 Not Found The server has not found anything matching the Request-URI. ... There's also the last point brought up in comment 14: If Firefox is asking for an image, the 404 should be sent as an image. Is Firefox asking for an image when requesting the favicon? If so, this is a case where Firefox doesn't honor the responses from servers with a better RFC2616 implementation, but honoring the responses from servers with worse implementations.
(In reply to Daniel Holbert [:dholbert] from comment #46) > [I'm starting to think you might be a troll.] You can start thinking that silently as well. > Sure, web developers can do whatever they like, including providing sketchy > favicons (with or without 404 responses). He was _not_ providing a favicon! Certainly not with the 404 response. How many times this should be repeated in that thread? This was just his generic 404 reply with image. > "Hixie says" is not a web standard. See also Comment 35 part (2). I've seen it, replied to it and not agreeing with it. If the standard says the response body should be dropped, then it should, no matter what UI thinks. If Hixie says that, then the standard does (or will) too. > Note also that your Hixie-quote is from bug 299138, which is about the <img> > element, not favicons. So what, if he explicitly talks about favicon in his comment? > But long as you're quoting from that bug, have a look > at the *actual* spec-quote later in that bug -- bug 299138 comment 16: > "Note: This allows servers to return images with error responses, and have > them displayed." Displayed as what? As favicon? It instead refers to this Hixie's point: --- If you go to the URI directly, then we should show the error message from the server (whatever its MIME type is) since that's the primary resource. --- Only in that case it can be displayed. > (Again, that's <img>-specific, and favicon-display-behavior doesn't seem to > be specified anywhere; I can only quote again: --- A favicon that is a 404, just like an <img> that is a 404, or an <object> that is a 404, should be dropped. In the case of favicon, it should cause us to use the default icon. --- > bug. And per comment 30, it seems odd that we'd be inconsistent between > <img> vs. favicon.) There is no inconsistency. For <img> it should be dropped as well. It is not dropped only "If you go to the URI directly". Hixie said it all clearly and unambiguosly.
(In reply to Daniel Holbert [:dholbert] from comment #46) > at the *actual* spec-quote later in that bug -- bug 299138 comment 16: > "Note: This allows servers to return images with error responses, and have > them displayed." I wonder if you've read an entire comment 16 and googled the spec it referred, so I've done that for you. http://dev.w3.org/html5/spec-preview/the-img-element.html --- Whether the image is fetched successfully or not (e.g. whether the response code was a 2xx code or equivalent) must be ignored when determining the image's type and whether it is a valid image. --- From this sentence we see that the error code is meaningless when determining image type and validity. Also we see that the image can be fetched successfully or not - this is controlled by the response code. So, with 404 we have a valid image with unsuccessfull fetch. Lets see what unsuccessfull setch gives us: --- If the download was successful Set the img element to the completely available state, update the presentation of the image appropriately, add the image to the list of available images using the key key, and fire a simple event named load at the img element. Otherwise Set the img element to the broken state, and fire a simple event named error at the img element. --- Of course if you accuse me being a troll, then you likely have read that standard already, really?
(In reply to Stas Sergeev from comment #49) > I wonder if you've read an entire comment 16 and googled > the spec it referred, so I've done that for you. > http://dev.w3.org/html5/spec-preview/the-img-element.html > --- > Whether the image is fetched successfully or not (e.g. whether the response > code was a 2xx code or equivalent) must be ignored when determining the > image's type and whether it is a valid image. > --- > From this sentence we see that the error code is > meaningless when determining image type and validity. > Also we see that the image can be fetched successfully > or not - this is controlled by the response code. > So, with 404 we have a valid image with unsuccessfull fetch. That's the wrong context for two reasons. 1) The spec you are quoting is for displaying an HTML page. The favicon isn't displayed as part of the HTML page. The favicon is something the browser displays elsewhere. 2) The context is for an image explicitly requested by the HTML page. The default favicon isn't requested by the web page, it is something extra the browser goes looking for. The purpose of the section you quote: When a web page responds to a request for a missing image the server "SHOULD" (http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1 as mentioned in comment 14) send the error message in an image so the browser can display the error message where the image was to be displayed. That purpose doesn't fit the favicon context as a missing default favicon isn't an error in the web page, so displaying the error isn't appropriate.
(In reply to B.J. Herbison from comment #50) > That's the wrong context for two reasons. > 1) The spec you are quoting is for displaying an HTML page. The favicon Well, sorry if I wasn't clear. I was replying to the particular person and was debunking his myth about this: --- And per comment 30, it seems odd that we'd be inconsistent between <img> vs. favicon.) --- and a few other myths he raised from the different bug report. The readers of only this thread are advised to ignore these messages.
In fact, the roots of this problem may be as far as in the Bug #32087. Hixie said: --- * This should not assume that the icon has a particular name, e.g. favicon.ico. Much better would be to only check for the file if the web page includes a link to the icon, like this: <link rel="icon" href="..." type="image/png"> --- But, contrary to that, it seems firefox is probing for favicon on its own. If it wouldn't, then this "take 404 as favicon" would indeed count just as a minor nuance and people could argue that he passed a favicon with 404 status, because he first explicitly referred to this favicon. Then what was said here by the "bug defenders" would suddenly make sense. But, as long as it is probing for favicon at will, it is a great surprise for the developer to see the 404 image being used as favicon.
You need to log in before you can comment on or make changes to this bug.