Почему Chrome ищет мой favicon.ico, когда я запускаю файл из ASP.NET MVC?

У меня есть контроллер в MVC, обслуживающий изображения из базы данных.

EDIT: Это все равно, если я передаю файл по полностью стандартным средствам в MVC.

Каждый раз, когда я запрашиваю свой образ, Google Chrome также ищет мой favicon.ico.

Чтобы избежать ненужных дискуссий о других вещах, "мне также должно быть интересно", предположим, что я не забочусь о кешировании в этом примере, и я всегда буду возвращать ответ HTTP 200 с файлом.

В моем контроллере я возвращаю следующее:

return File(fileBytes, contentType);

После проверки Fiddler 2 генерируется следующий ответ:

HTTP/1.1 200 OK
Cache-Control: public
Content-Type: image/gif
ETag: oYu19wKo + KEHkyxZQ2WXAA ==
Сервер: Microsoft-IIS/7.0
X-AspNetMvc-Version: 1.0
X-AspNet-версия: 2.0.50727
X-Powered-By: ASP.NET
Дата: Вт, 16 июн 2009 18:48:45 GMT
Контент-длина: 29344

Для сравнения, это ответ в Fiddler от Google, когда я впервые (я спрашиваю) логотип Google:

HTTP/1.1 200 OK
Content-Type: image/gif
Последнее изменение: ср, 07 июн 2006 19:42:34 GMT
Дата: Вт, 16 июн 2009 18:50:54 GMT
Истекает: ср, 16 июн 2010 18:50:54 GMT
Cache-Control: public, max-age = 31536000
Сервер: gws
Content-Length: 8706
Возраст: 2

Однако в Chrome после получения моего изображения Chrome пытается найти мой favicon.ico. Он не пробовал это после запроса логотипа Google.

Любые идеи, почему это может произойти? Из моего понимания в HTML, ответ должен быть в заголовке ответа, потому что, конечно, все, что должен сделать клиент? Пожалуйста, поправьте меня!

РЕДАКТИРОВАТЬ 2: Кажется, что многие люди полностью не поняли проблему. Проблема состоит в том, что not отсутствие favicon и запросов об ошибках в MVC - проблема с запросом favicon при загрузке только изображения с типом контента "IMAGE/JPEG" ", в отличие от веб-страницы с типом контента" ТЕКСТ /HTML "!!

Ответ 1

Это не имеет ничего общего с MVC. Я использую webforms с настраиваемой службой журнала, и я наткнулся на этот пост, задаваясь вопросом, почему у меня были непрерывные ошибки "Файл не существует" в моих журналах. Это локально на моей машине разработки, у меня нет файлов favicon.ico в моих проектах, и я попробовал IE, Firefox и Google, пытаясь выяснить, какой браузер является виновным.

Каждый запрос из Google Chrome в мои приложения делает запрос на favicon.ico. Я должен был запустить локальный браузер, чтобы определить, что это был браузер googles, который является виновником. Я свяжусь с Google, если это вас беспокоит. Я просто хотел убедиться, что это не какой-то новый троянец, заражающий мой хром.

Ответ 2

Фактический ответ: Это известная, проверенная ошибка. * (недавно исправлено!... может быть?)

Похоже, известная давняя проблема с Chrome: http://crbug.com/39402

Если вы хотите, чтобы это было исправлено раньше, начните тему. Больше людей, играющих главную роль в этой проблеме, скорее всего, увеличит свой приоритет и, возможно, быстрее ее исправят.


**** ОБНОВЛЕНИЕ 1 ***: По состоянию на 15 мая этого года (2013) - спустя четыре года после того, как этот вопрос был задан, похоже, проблема была исправлена ​​в версии 29: http://crbug.com/39402#c47

Не стесняйтесь отменить все ваши хаки и обходные пути.:]

**** ОБНОВЛЕНИЕ 2 (2015-01) ***: Это, по-видимому, все еще проблема для некоторых пользователей, в соответствии с той же проблемой.:/

Ответ 3

У вас есть значок? Если нет, возможно, именно поэтому Chrome пытается найти его каждый раз для вашего сайта. Для google у него уже есть кэшированный favicon.

Ответ 4

одна вещь, которую вы могли бы сделать, - это MVC игнорировать любой запрос для *.ico, чтобы вы не получали никаких исключений при отладке.

Должно быть что-то вроде этого:

routes.MapRoute("ignore-favicon", "{*path}", null, new {path = ".*/favicon\\.ico"});

Этот шаблон URL соответствует всем, но тогда мы ограничиваем его только совпадением с чем-либо, заканчивающимся на favicon.ico. (Я не тестировал это)

Ответ 5

Я столкнулся с этой проблемой некоторое время назад и обошел ее, проигнорировав конкретный маршрут, добавив

routes.IgnoreRoute("{*favicon}", new { favicon = ".*/favicon\\.ico" });

в метод RegisterRoutes в Global.asax.

Ответ 6

Вы можете добавить что-то вроде этого в свой web.config файл, чтобы убедиться, что favicon.ico кэшируется на клиенте и не запрашивается каждый раз.

<location path="favicon.ico">
    <system.webServer>
        <httpProtocol>
            <customHeaders>
                <add name="Cache-Control" value="public, max-age=31536000" />
             </customHeaders>
        </httpProtocol>
    </system.webServer>
</location>

Вы можете/должны делать то же самое для любых изображений /.js и css файлов

Ответ 7

Мне кажется, что Chrome запрашивает значок для своих собственных вкладок - я продолжал получать 404s (потому что мой значок уже где-то еще и мои страницы знают это), пока я не проведу несколько тестов, и понял, что именно Chrome делает прямые запросы к значку файл. Никакого реального исправления, кроме внесения перезаписи в реальный файл, я думаю,

Ответ 8

Вы должны установить заголовок Expires, чтобы сообщить браузеру, как долго он должен использовать свою локальную копию.

Ответ 9

Если вы проверяете настройку своего проекта, он где-то говорит значок по умолчанию. Удалить это?

Ответ 10

Браузер Chrome может работать с сайтом Google иначе, чем с любым другим сайтом, поэтому сначала я бы рекомендовал проверить, ищет ли он favicon.ico каждый раз в другом месте, например, в StackOverflow.

Я также хотел бы проверить, делает ли Firefox то же самое с вашим сайтом. Я думаю, что favicon.ico следует запрашивать только один раз для браузера, даже если его нет на сайте. Это может быть ошибка в используемой вами версии Chrome.

Ответ 11

Это. Вопрос/ответ SO объясняет, как использовать Favicon для браузера с помощью маршрутов.

Ответ 12

Важно добавить ссылку ICON на вашу главную страницу, или некоторые браузеры попытаются найти favicon.ico для всех каталогов, а не только по всему миру один раз за каждый.

 <link rel="SHORTCUT ICON" href="<%= Url.Content("~/content/images/rr-favicon.ico") %>"/>

Кажется, панель инструментов Google - это виновная сторона, судя по моим журналам (и, конечно, IE6). Они оба будут делать запросы для каталогов, отличных от корневого

 Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
 Mozilla/4.0 (compatible; GoogleToolbar 6.2.1910.1554; Windows 6.0; MSIE 8.0.6001.18828)