238348 - 404 Error page when looking for favicon.ico

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Jeremy Hannon]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040322 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7b) Gecko/20040322 Firefox/0.8

When clicking a link that takes you to a site that has not recently been
visited, and then clicking a link on the next page before the page has finished
loading will sometimes load a 404 error page from the site stating that
http://www.foo.com/favicon.ico can not be found.

Reproducible: Sometimes
Steps to Reproduce:
1. Site must not actually have a favicon.ico file at the root of the site (for
example, http://support.dell.com)
2. It only seems to hapen when clicking from another site (the Customer Service
and Support site at http://www.dell.com, for example)
3. Click on another link on the target page as soon as you can see one.
4. The 404 error page is displayed.

Actual Results:  
link opens as normal

Expected Results:  
404 error page is shown.

It seems that the site must not have been visited recently enough so that
firefox will attempt to look for a favico.ico file.  It only seems to work the
first time in a browser session, and I have not been able to reproduce it more
than once per day, yet.  I have been able to reproduce it at the Dell site on
multiple machines, with both 0.8 milestone and this nightly.  I have had the
experience on sites other than Dell's, however, but do not remember what they
were to be able to reproduce.

Hitting back and clicking the link again will cause the site to open as normal.

Comment 1

[Jeremy Hannon]

Ok somehow I switched the Expected and Actual results above.  It should be:

Actual Results:  
404 error page is shown.

Expected Results:  
link opens as normal.

Also, it does not seem to be affected when the link you click is a javscript
link... probably because it has had time to actually verify the favicon.ico file
already before the javascript has been processed.

Comment 2

[Jesse Ruderman]

Do you have pipelining enabled?  (Go to about:config and look for
network.http.pipelining.)

Comment 3

[Jeremy Hannon]

Good Point.  I did have pipeling on.

However, I decided to try it again with a clean profile, and pipeling turned
off, and I am able to reproduce it almost 100% of the time now (4 of 4 tries). 
Before closing the browser to reproduce again, I did a "clear everything" in
privacy, which also clears the cookies that lets the Dell site remember what
area of support you are in.

Comment 4

[Ben Fowler]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a) Gecko/20040417
Firefox/0.8.0+

I would be surprised if this were a pipelining problem, the 404 page
concerned has this URL 
"http://support.dell.com/404.aspx?404;support.dell.com/favicon.ico"
which is rather what I would expect if the Dell site's custom missing
page hander were buggy.

According to Netcraft, "The site www.dell.com  is running Microsoft-IIS/5.0 on
Windows 2000".

Unless you can find a site running a webserver designed with a "correct
first", "fast second" goal with this behaviour, then it may be merely an
Evangelism issue.

Does the problem occur with any other browser? I can evince it in Safari,
which is not based on Gecko.

Comment 5

[Jesse Ruderman]

> I would be surprised if this were a pipelining problem, the 404 page
> concerned has this URL 
> "http://support.dell.com/404.aspx?404;support.dell.com/favicon.ico"
> which is rather what I would expect if the Dell site's custom missing
> page hander were buggy.

That's exactly what I would expect to see if it were a pipelining problem. 
Clicking a link to a URL other than favicon.ico gave a 404 message for favicon.ico.

Jeremy said he could reproduce without pipelining on and with a clean cache, so
I guess it's not a pipelining problem.  But I don't have another explanation. 
Ben, what's your explanation that involves a buggy custom missing
page hander?

Comment 6

[Ben Fowler]

Some webservers use an 'Active Page' mechanism to deliver a Custom
Error Page for file not found. Whilst this looks neat and tidy
from the web developer's POV, it is not always best from the
user's perspective as the URL bar "warps' from something other
than one has typed into it. The Apple developer's site is one of
the worst current offenders particularly as this behaviour happens
with URLs that were once correct.

IMHO, a webserver should not deliver such a custom page for an
optional element such as 'favicon.ico', but a simple error
response.

In regard to this bug, the problem on Dell's site in visible in Firefox
and Safari, so I would not look first to minutiae of Firefox's
network code, at least until I had found another site where it
occurs. I suspect that this bug will eventually be marked as invalid,
but I don't really know.

See http://lwn.net/favicon.ico and http://bugzilla.mozilla.org/favicon.ico
for other examples of 'weirdness' and http://texturizer.net/ for a site
that gets it right.

(Netcraft: The site www.texturizer.net  is running Apache/2.0.48 (Unix)
mod_ssl/2.0.48 OpenSSL/0.9.6b PHP/4.3.4 on Linux. But you probably guessed 
that.)

In short, unless you want to special case /favicon.ico, we are totally in
the hands of what the web site responds with when given an HTTP request.

Comment 7

[Jeremy Hannon]

I think the main problem is that, even if the web page returns it, firefox
should not show it.  

Firefox does not show the error page if the page has finished loading first.  In
those cases, we never see the 404 error.

Is it being suggested that that the 404 page is sent by the site when the GET
request is sent for the link, or just the GET request for the favicon.ico file?
 If the response is actually to the GET request for the new page, then there is
a server problem and out of Firefox's hands.  However, if it simply the response
to the GET for the favicon.ico file, then Firefox is displaying the wrong
response.  It should display the page for the new GET request, not the old.

Comment 8

[Daniel Morante]

I am able to reproduce this bug in FireFox 0.8 (release) 100% of the time at the
following site:

http://dmpe.aramark.net

The always bug occurs imiedatly after a succesful login to the site with a fresh
browser session.

Unforualy, this may not help since access to the site is limited to ARAMARK
employees.

I am willing to spend the time in providing any debugging info, but you'll need
to help me out, I don't know what to do.

Comment 9

[Robin Monks]

Moving to core->Networking...

Comment 10

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 11

[Jesse Ruderman]

WFM: I can't reproduce at http://www.dell.com or http://support.dell.com/ using
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20050926
Firefox/1.4.  If anyone can reproduce using Firefox 1.5 Beta 1 or later, please
reopen.

Daniel, I can't test http://dmpe.aramark.net/ (comment 8), but if you can still
reproduce the bug there using Firefox 1.5 Beta 1 or newer, I think it would be
best for you to file a new bug report (please CC me).

Comment 12

[Daniel Morante]

The site dmpe.aramark.net was recently updated, and it no longer produces the
favicon.ico error.

Must have been a coding problem in the site.

Comment 13

[Ben Fowler]

Personally, I agree with comment 7 .

All the cases appear to work correctly, I am fairly sure that the dell site(s)
have been revised.

If there ever was a defect in Firefox it has probably been fixed, otherwise
this report is WORKSFORME .