Я думаю, что нашел причину для этого.
Когда веб-сервер обнаруживает ошибку, он обычно подает в браузер документ (обычно HTML-документ, описывающий ошибку) с указанием состояния ошибки с использованием кода состояния HTTP.
Согласно этому отчету об ошибках, Firefox изначально всегда отображал возвращенный документ; обычно это то, что вы хотите. Однако пользователь обнаружил проблему с неправильно настроенным сервером AOL: при запросе несуществующего EXE-файла сервер будет обслуживать страницу 404, но с неверным типом содержимого. Это привело к тому, что Firefox предложил загрузить документ HTML с расширением .exe , что сбивало с толку, поскольку не было никаких признаков того, что произошла какая-либо ошибка. Они изменили поведение простым взломом (не оправдывая усилий по написанию новой страницы с сообщением об ошибке, поскольку это редкий случай, вместо того, чтобы повторно использовать страницу "не найден", что имеет смысл в конкретном примере, приведенном репортером ошибки).
Из сообщения об ошибке, обнаруженного @ m4573r, похоже на текущее поведение, когда Firefox получает ответ с HTTP-кодом, сигнализирующим об ошибке, а Content-Type ответа отличается от HTML, тогда Firefox отображает ошибку "Файл не найден" стр.
Подавляющее большинство веб-серверов настроено на обслуживание HTML-документа в случае ошибки, поэтому вы обычно этого не видите. Но в этом угловом случае сообщение об ошибке не имеет смысла.
wget -d http://www.ssa.gov/framework/images/icons/png/ подтверждает, что здесь происходит:
---response begin---
HTTP/1.1 500 Server Error
Server: Generic Web Server 1.0
Date: Thu, 20 Feb 2014 23:29:57 GMT
Cache-control: public
Content-type: magnus-internal/directory
Transfer-encoding: chunked
---response end---
Он обслуживает страницу ошибок с поддельным Content-type magnus-internal/directory , вызывая поведение в Firefox.
Очевидно, Google подумал, что такое поведение имело смысл, и реализовал его аналогичным образом в Chromium.
