Я получаю ошибку 404 «Страница не найдена» (80% времени) по любым ссылкам вне http://doubleabody.com/, но только для браузеров IE и только если включен параметр «Удобные сообщения об ошибках». Зайдите в настройки IE и отключите «Дружественные сообщения об ошибках», и проблема не вернется. Включите «Дружественные сообщения об ошибках» снова, и проблема вернется снова, но только в 80% случаев. Никакой другой браузер, кроме IE, не имеет этой проблемы. Пока мы видим эту проблему в IE8 и IE9.
Когда я говорю «80% времени», я имею в виду, что щелкаю ссылку после очистки истории и кеша браузера и получаю сообщение 404 в IE. Но затем обновите примерно 4 раза, и внезапно страница открывается нормально. Отключите «Дружественные сообщения об ошибках», и проблема вернется. Мы наблюдаем это на нескольких типах Windows (XP, Vista, Windows 7, Windows Server 2008 на виртуальной машине в Ubuntu Linux).
Кроме того, это недавняя проблема, около 2 недель назад. В течение нескольких месяцев этот сайт работал на a2hosting.com нормально. Пока что a2hosting.com все еще занимается устранением неполадок, и они тоже не могут решить проблему.
Это сайт WordPress, на который загружена Pods CMS. У него нет других плагинов, кроме Pods CMS. Я создал специальную тему WordPress, а затем использовал API CMS Pods для извлечения содержимого для отображения. Это превратило его из блога в веб-сайт для малого бизнеса.
.Htaccess этого сайта также является обычной разновидностью WordPress.
ОБНОВЛЕНИЕ1
По запросу от @JeffAlbert я показываю, что говорится в журналах ошибок, когда я сталкиваюсь с ошибкой 404 из браузера IE8. Это было, когда я щелкнул ссылку «/ карта» на главной странице. (Обратите внимание, что я изменил IP-адрес для защиты моей рабочей станции.) Обратите внимание, что первая попытка не удалась. Со второй попытки все прошло.
50.0.0.0 - - [25/Mar/2011:00:56:51 -0400] "GET /map HTTP/1.1" 404 9082 "http://doubleabody.com/" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
50.0.0.0 - - [25/Mar/2011:00:56:59 -0400] "GET /map HTTP/1.1" 404 9216 "-" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
А теперь вот что происходит, когда я снова щелкаю / сопоставляю с отключенными в IE8 «Дружественными сообщениями об ошибках», где это постоянно появляется нормально:
50.0.0.0 - - [25/Mar/2011:01:03:19 -0400] "GET /map HTTP/1.1" 404 9216 "http://doubleabody.com/liftgates" "Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 6.0; Trident/4.0; SLCC1; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729)"
И вот результат, когда я использую Google Chrome из Ubuntu Linux, где он работает стабильно:
50.0.0.0 - - [25/Mar/2011:01:07:20 -0400] "GET /about HTTP/1.1" 404 11801 "http://doubleabody.com/map" "Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/534.16 (KHTML, like Gecko) Chrome/10.0.648.151 Safari/534.16"
У меня была собственная тема в WordPress, которую я написал. Это работало так, что он захватил все подключения к сайту и отправил их в файл index.php темы. Затем это вызовет get_header (), get_sidebar () WordPress, покажет контент, а затем get_footer () - стандартный материал WordPress.
Как ни странно, журналы отражали статус 404. Итак, в моем index.php я сделал первую строку такой:
заголовок ('HTTP / 1.1 200 OK');
На тот момент журналы Apache больше не показывали 404, а 200. Теперь проблема в IE больше не возникает.
Итак, вот что я сделал из этой проблемы. Очевидно, IE игнорировал условие 404 с самого начала IE. Но на прошлой неделе, очевидно, я предположил, что Microsoft представила системное обновление для IE7, IE8 и IE9, которое заставило его немедленно останавливаться на заголовке состояния 404, даже если вернется действительный контент. Если я пропустил заголовок 200 через тему, IE больше не видит 404 и видит 200. Таким образом, ошибки нет.
Неожиданное предположение: плохой DNS-сервер, доступный для клиентов. Методология тестирования: подтвердите в журналах доступа к вашему веб-серверу, действительно ли вы видите 404, возвращенные для каких-либо клиентов; в противном случае запросы никогда не попадали на ваш веб-сервер, и вам следует начать искать либо DNS (начиная с авторитетного источника для вашего домена), либо реальные проблемы с сетевым подключением со стороны клиента.
Если вы действительно видите, что возвращаются фактические сообщения 404, путь, который пытался загрузить ваш клиент, вероятно, даст вам довольно хорошее представление о том, что вызывает проблему. Надеюсь, это поможет!