Назад | Перейти на главную страницу

Apache обслуживает неправильную страницу

К предисловию: наверное, это одна из самых странных ошибок, которые я когда-либо видел, особенно с тех пор, как они появляются и исчезают.

Существует страница с названием view.php и другая страница называется save.php. Ошибка проявляется, когда я прошу save.php - Вместо этого я получаю view.php. Заголовки запроса говорят save.php, и это происходит в Firefox, IE, Chrome, Opera, Safari. Это происходит постоянно, если - и вот что самое странное - я не открываю файл и не сохраняю его. Я не вношу в него никаких изменений, просто сохраняю. После сохранения я могу сделать такой же запрос, и он будет обслуживаться save.php как будто ничего плохого не было.

В настоящее время я экспортирую из репозитория svn (просто svn export http: // сервер / репозиторий target команда). Если я экспортирую, не внося никаких изменений, ошибка проявляется снова. Если внести изменение (на совершенно несвязанную страницу) и зафиксировать его в репозитории, а затем экспортировать, ошибка обычно исчезает. Однако то же самое может произойти с двумя разными страницами (также не связанными с измененной страницей), а может и нет.

Я не использую никакого кеширования (без кеширования php, кеширования браузера или кеширования apache).

Версии SVN: 1.6.9 с AnkhSVN на машине Windows (машина разработки), 1.4.2 как на машине репозитория, так и на тестовой машине (где я запускаю команду экспорта).

Я понятия не имею, кроме того, что подозреваю, что в svn что-то идет не так.

Почему бы вам не попробовать переименовать файлы. Переименуйте оба файла, добавьте какой-нибудь префикс и попробуйте еще раз. Это может избавить вас от неправильной путаницы при перенаправлении / индексировании (возможно).

Убедитесь, что кеширование не включено. Проверьте свои модули в Apache и выгрузите любой модуль кеширования. Убедитесь, что расширение APC в PHP не загружено (phpinfo)

Попробуйте использовать svn checkout вместо того svn export. Начните тестирование и, когда заметите баги, сделайте svn stat чтобы увидеть, не изменилось ли что-нибудь. Технически не должно быть разницы между checkout и export Кроме этого checkout более полезен, поскольку позволяет обновлять на месте. Но с checkout вы хотите иметь что-то вроде следующего в своей конфигурации vhost.

<LocationMatch "\.svn.*">
 Order deny,allow
 Deny from all
</LocationMatch>

И последнее, но не менее важное: начните со свежей конфигурации HTTP. Сделайте резервную копию конфигурации и переустановите пакеты Apache / PHP. Это должно сгенерировать конфигурацию по умолчанию. Затем добавьте простые изменения конфигурации, чтобы иметь возможность обслуживать файлы PHP. Как только вы увидите оба файла без проблем, начните тестирование для вашей проблемы. Затем постепенно начните добавлять части конфигурации из сохраненной конфигурации, пока она не начнет давать сбой. Последняя часть, которую вы добавили, - это причина.

У меня только поверхностное знание mod_rewrite. Независимо от наличия mod_rewrite, я бы рекомендовал удалить как save.php, так и view.php из SVN, а затем повторно импортировать их с отдельными коммитами. Я теряю некоторые знания, которые я получил, где ревизии становятся поврежденными, и их перемещение или удаление и повторный импорт устраняет проблему. Я знаю, что это не изящное (предлагаемое) решение.

Надеюсь, это поможет.

Спасибо,
Закари

Конечно, я никогда слышал о чем-либо подобном, несмотря на наличие нескольких малых и средних сайтов LAMP.

Помимо подозрений в svn, что-то идет не так

Насколько сложно будет проверить, что содержимое save.php не было заменено на save.php? Но это само по себе не объясняет, почему это происходит случайно.

Обнюхивали ли вы трафик при репликации ошибки, чтобы убедиться, что она не связана с перенаправлением или кешированием?

Что показывают журналы доступа и ошибок после обслуживания неправильного контента?

С.