У нас было это , и поскольку мы используем бритву с html, страницы не могут адаптироваться автоматически. Для меня самым простым исправлением было изменение типа контента в _ViewStart.cshtml
:
Response.ContentType = "text/html";
Безумие "сам разберись в типе контента" происходит только тогда, когда ничего явно не установлено. Итак ... установите его.
Ваши фактические просмотры все еще могут переопределить это:
@{
Layout = null;
Response.ContentType = "application/atom+xml";
}
Для информации, чтобы проверить эту проблему на вашем локальном сервере разработки (с чистым кешем, чтобы избежать ложных результатов по предыдущим кэшированным данным), сделайте что-то вроде wget или Fiddler:
wget yourpage --header="Accept: text/vnd.wap.wml" --server-response --header="Accept-Encoding: gzip, deflate"
и ищите:
Content-Type: text/vnd.wap.wml; charset=utf-8
в результате; если вы видите это, IIS / ASP.NET решил сделать вид, что ваш ответ удовлетворяет заголовку запроса «Принять» ... даже если это не так. Хуже того: теперь вы можете получить этот "text / vnd.wap.wml" из wget без без указания заголовка Accept (или с указанием чего-то вроде "text / html"); если вы видите это , у вас есть проблема (или: ваши пользователи видят) - у вас есть кэшированный ответ для WAP, который подается клиентам не-WAP.
С помощью приведенной выше настройки первый wget вернет "text / html" - так как это то, что наш контент. Извините, браузеры нижнего уровня; Вы должны были включить "text / html" в качестве опции - и если вы не можете обработать "text / html" ... отстой, чтобы быть вами.