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.

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

Thanks!

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)]
  or
  [ 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.

1. http://cuarentaydos.com/chrome-bug/index.php

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?

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!

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.

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!

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.

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.

(No comment was entered for this change.)

(No comment was entered for this change.)

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.

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/render_view.cc:3366 right now:

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

  // 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) {
    navigation_state->set_postpone_loading_data(false);
    frame->commitDocumentData(navigation_state->postponed_data().data(),
                              navigation_state->postponed_data().size());
    navigation_state->clear_postponed_data();
  }
}

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.

 Issue 1695  has been merged into this issue.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=75887

------------------------------------------------------------------------
r75887 | mmenke@chromium.org | Thu Feb 24 06:55:09 PST 2011

Changed paths:
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/iframe404-inner.html?r1=75887&r2=75886&pathrev=75887
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/page404.html?r1=75887&r2=75886&pathrev=75887
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/errorpage_uitest.cc?r1=75887&r2=75886&pathrev=75887
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/iframe404-inner.html.mock-http-headers?r1=75887&r2=75886&pathrev=75887
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/navigation_state.cc?r1=75887&r2=75886&pathrev=75887
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/navigation_state.h?r1=75887&r2=75886&pathrev=75887
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/renderer/render_view.cc?r1=75887&r2=75886&pathrev=75887
 D http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/data/iframe404.html?r1=75887&r2=75886&pathrev=75887

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

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

BUG=36558
TEST=ErrorPageTest.Page404

Review URL: http://codereview.chromium.org/6546069
------------------------------------------------------------------------

(No comment was entered for this change.)

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=76541

------------------------------------------------------------------------
r76541 | mmenke@chromium.org | Wed Mar 02 07:10:21 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/errorpage_uitest.cc?r1=76541&r2=76540&pathrev=76541

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

BUG=36558
TEST=ErrorPageTest.Page404

Review URL: http://codereview.chromium.org/6591044
------------------------------------------------------------------------

 Issue 31561  has been merged into this issue.

 Issue 47813  has been merged into this issue.

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.

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.

Aren't useful, rather.