404 Error Page Status

Feature Description

We want Firefox to override server-supplied 404 error pages in certain cases. The Firefox 404 page should provide the user with tools we think are more useful to the user for resolving the situation, than the server supplied page. This includes alternate ("did you mean") URLs derived from the Places database and some pre-loaded search links/controls. This feature is being tracked in bug 482874.

Status

Almost ready to go. Notable progress this week:

The docshell changes have r+ from bz with just a few changes, most of which I've already made.
Axel has provided some feedback on localization.
Johnath has provided feedback on the XHTML.
Marco has provided some feedback about the Places changes. Notably he points out that query performance could be an issue on large databases.
David Dahl has provided me with a "max_places" test database. The bad news is the URL suggestions query can take ~30 seconds to run against this database. The good news is that a very simple length-check guard in the query can make a big difference.

Next Steps

Address the localization changes Axel raised, and then get formal L10N review.
Address the performance issues in the URL suggestions query. (Probably just a LIMIT-based approach for the initial patch)
Get a formal review of Places changes (Dietrich did an informal review a few weeks ago).
Get a final UI review.
Make sure all the parts of the patch have r+ from the various parties.
Land the thing.

9 responses

I am still parading around trying to find a solution to this : https://bugzilla.mozilla.org/show_bug.cgi?id=317056

If you type in a url that is incomplete like www.slashdot.or and press go.. then realize it and try to retype the URL.. the "can't load page" thing comes up and stops you from finishing typing in the URL.

— Adam

@Adam:

Once we get the 404 page up and running, we can extend it to handle DNS Not Found errors as well. The suggested URLs feature should then provide you with a "did you mean: slashdot.org" option, assuming that you've been there at least once already.

— Curtis Bartley

You’re competing with the ISPs too who have taken to redirecting 404s to their ad-laden search pages.

— Kroc Camen

I know IE has done this before, but what I worry about is, will this not push web sites to serve error pages with a regular 200 OK because the 404 response gets intercepted and replaced with a browser page? Breaking part of the web architecture in the process.

— Laurens Holst

The intention here is not to stomp on a web site supplied 404 error page, but merely to override the default error message produced by the webserver software. Other browsers do this by keying off the length of the returned HTML. The server default page is in general very short and the web site defined error pages tend to be much larger.

If you read the bug, you will see the same thing is being done here.

— Bill Gianopoulos

@Laurens Holst:

We only override very small 404 error pages, on the assumption that these are almost always largely useless default web server 404 pages. Note that Internet Explorer and Google Chrome do this now, so we're unlikely to make the situation any worse.

It won't be in the first patch, but we'd like to provide a facility for viewing the overridden error page should the user decide to do so.

@Kroc Camen:

Well, COMCAST isn't doing that yet, thankfully. I notice that they're now hijacking dns-not-found errors, however. I don't know if there's anything Firefox can do about this sort of thing, but if there is, I'm all for it.

Kroc, ISPs are hijacking DNS NXDOMAIN responses, not HTTP 404 responses.

— Boris

I wonder if we could allow servers to send an additional response header indicating that they want their 404 page to be seen, not our replacement page. That might provide an out for them without guessing based on the page length. Alternately, as bz mentioned in the bug, if we can detect the default Apache 404 page, that would be pretty cool.

— Ted Mielczarek