New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 36558 link

Starred by 63 users

Issue metadata

Status: Fixed
Closed: Feb 2011
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocked on:
issue 457847

  • Only users with EditIssue permission may comment.

Sign in to add a comment

chrome eats 404 pages, doesn't show any custom messages to user

Project Member Reported by, Feb 23 2010

Issue description

Chrome Version       : 5.0.307.9 beta
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
  Firefox 3.x: OK

I'm trying to load a site on my intranet and it is coming back with a 404 
error. In addition to the 404 HTTP status, I also happen to know that this 
site returns content with an error message explaining what went wrong.

Unfortunately, chrome eats the 404 error and gives me a generic search page 
instead. I had to switch to firefox to get around this.

This sucks for 2 reasons:
1. There appears to be no way to send both the correct HTTP status and a 
user-visible message. So now I have to I return 200 with a 
helpful message? or 404 without a message?  Terrible...this encourages web 
page authors to mis-use HTTP.

2. Chrome's default 404 offers to do a google search which is rather 
arrogant, especially when I'm loading a private site that google can't 
possibly crawl.


Comment 1 Deleted

Comment 2 by, Feb 23 2010

If a non-200 HTTP code returned page is under a specific size (512 bytes?) Chrome will 
display its own page which it hopes is more useful.  Go to Options > Under the Hood and 
uncheck Show Suggestions for Navigation Errors to suppress this behavior and always 
show the server's page.

Comment 3 by, Feb 23 2010

Oh, so as a website devloper I just need to include a few extra bytes and then chrome 
will always show my messages?


Comment 4 by *, Mar 1 2010

Status: WontFix
Close this bug due to #2
I think this behaviour is incorrect, in addition to the reasons in #1, because:

- A creative (and useful) 404 page can be below 512 bytes as you can see at [1],
  it's far from be a professional work, but you can get the idea.
- Chromium (*not Google Chrome*) includes
  a google logo, and a search box that uses google to search internet, my company
  may have nothing to do with Google.   

- I may develop an intranet site that is not indexable by google,
  so this default page is useless.

- Disabling this behaviour by user is neither an option,
  you can imagine a temporal worker, or just a visitor, an external consultant, etc...
  using chromium and you have all the problems back again.

- Last, but not not least, padding up to 512
  bytes files is not an option.
  First, its browser-specific, we start with this little thing but who knows
  we can end?                   
  404 pages can be generated, controling output size can be a headache or be under-optimized.
  I can see solutions like:       
  [ $buffer = render_page(); if ($buffer.length() < 512) $buffer = add_padding($buffer)]
  [ print render_page() + (" "*512); ]

So, please reconsider this behaviour, may be this option should be disabled by default and add one like "Use 
google to search missing page

Thanks for reading this.

I don't believe it, you mean we have to develop with firefox to discover missing files until someone searches on this useless chromium behaviour until they find a page like this with a wontfix!?

Could we at least, please, be able to trigger a proper 404 result from the server with a custom header without requiring the end-user to modify their browser settings?

Comment 7 by, Oct 28 2010

I have just stumbled upon this issue in Chrome 7 and I can't believe chromium would do something that everybody hates about IE! I have spent an hour trying to understand why my site doesn't display a proper 404 page. This really sucks!

Comment 8 by, Oct 31 2010

I have been fighting with Tomcat trying to create a custom 404 page - was sure I was making mistakes.

Tested in Safari, and things worked fine. (Strange, huh?) Did a bit of research, found this issue. This is extremely frustrating. As a web developer, I want any incorrect requests to be redirected to the home page. A redirect page doesn't need to be more than 512 bytes, and I sure don't want my users sent to Chromium's "friendly" 404 page when they could automatically be redirected to the proper home page.

Fix this guys. It's arrogant and a step backwards.

Comment 9 by *, Nov 1 2010

Labels: -Area-Undefined Area-UI Feature-TabContents
Status: Untriaged
Reopen the issue for review due to the website developers comments
This is really annoying. I'm developing a webserver as a college project and I've spent lots of time trying to find out why my error pages were not shown! At least until I try with firefox and realize that everything was fine.
Please guys, fix this!

Comment 11 by, Jan 11 2011

How does Chromium eat the response from the server?  I can *almost* understand showing a browser utility page if a likely unhelpful response is received.  However, the developer tools in the browser show no evidence that the server was even contacted to get a 404 status code.  No request, no response headers, nada. I would expect that there, as a knowledgeable developer, I would be able to see some insight into *why* the browser is not showing me the intended 404 page.

Spending hours trying to figure out if there was an erroneous "die();" in my code (or the framework i'm using was very frustrating.  It wasn't until I finally tried Firefox that I got my placeholder 404 response.  It's likely not what will end up in production, but right now it would be nice if it wasn't buried by the browser.

Comment 12 by *, Jan 11 2011

Labels: -Feature-TabContents
Anthony, do you know who own the feature "Suggestions for Navigation Errors"?
For the record, I just wasted about 2 hours debugging Apache because of this so-called "feature" in Chrome.  The assumption that if a returned error message is less than 512 bytes then its not useful is incorrect.
Labels: -Area-UI Area-Internals Internals-Network
Labels: Mstone-12
Status: Assigned
This can be turned off - Under the Hood->Use a web service to help resolve navigation errors.

I'd be happy to change how this works, but I believe any changes to this would need the sign-off of a UI lead.

Comment 17 by, Feb 14 2011

tony: could you tell us why we replace the server's HTTP error
page if it's less than 512 bytes?  In my opinion, we should
display the server's error page faithfully, unless it is blank
(0 bytes).  I'd appreciate it if you could advise us on this
issue.  I can ask mmenke to make the changes.

The relevant code is at
src/chrome/renderer/ right now:

void RenderView::didReceiveDocumentData(
    WebFrame* frame, const char* data, size_t data_len,
    bool& prevent_default) {
  NavigationState* navigation_state =
  if (!navigation_state->postpone_loading_data())

  // We're going to call commitDocumentData ourselves...
  prevent_default = true;

  // Continue buffering the response data for the original error page.  If it
  // grows too large, then we'll just let it through.  For any error other than
  // a 404, "too large" means any data at all.
  navigation_state->append_postponed_data(data, data_len);
  if (navigation_state->postponed_data().size() >= 512 ||
      navigation_state->http_status_code() != 404) {

Comment 18 by, Feb 14 2011

This was originally done to match IE, which would replace 404 pages if the content was less than 512 bytes.  It looks like this feature was removed in IE7 (according to wikipedia) and now that IE6 has a small market share, seems like it would be worthwhile to remove the code in Chrome/Chromium as well.

wtc makes a good suggestion of showing the custom page if the server returns 0 bytes.

I'd be happy to review the change.

Comment 19 by, Feb 14 2011

 Issue 1695  has been merged into this issue.
Project Member

Comment 20 by, Feb 24 2011

The following revision refers to this bug:

r75887 | | Thu Feb 24 06:55:09 PST 2011

Changed paths:

Only display Link Doctor page on 404 errors with no body.

Had to remove some of the old tests, since
will not sent blank pages when there's an error code (On
the trybots, at least).

BUG= 36558 

Review URL:
Status: Fixed
Labels: -Mstone-12 Mstone-11
Project Member

Comment 23 by, Mar 2 2011

The following revision refers to this bug:

r76541 | | Wed Mar 02 07:10:21 PST 2011

Changed paths:

Replace an unnecessary "NavigateToURLBlockUntilNavigationsComplete" with
"NavigateToURL" in ErrorPageTest.Page404

BUG= 36558 

Review URL:

Comment 24 by, Sep 19 2011

 Issue 31561  has been merged into this issue.

Comment 25 by, Sep 19 2011

 Issue 47813  has been merged into this issue.

Comment 26 by, Jan 10 2012

Comments above indicate that the behaviour can be turned off.  This is not correct.  I have the option indicated disabled and am still seeing this behaviour.

Comment 27 by, Jan 10 2012

That comment was specifically in response to assuming error pages with less than 512 bytes aren't useful, and was true at the time.  Now we only assume error pages without any body at all (content-length: 0) aren't useless to end users.

Comment 28 by, Jan 10 2012

Aren't useful, rather.
Project Member

Comment 29 by, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 30 by, Mar 10 2013

Labels: -Area-Internals -Internals-Network -Mstone-11 Cr-Internals Cr-Internals-Network M-11
Project Member

Comment 31 by, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue

Sign in to add a comment