У нас есть сайт, на котором работают PHP-FPM и NGINX. Приложение отправляет приглашения участникам сайта, которые содержат 40-символьные случайные строки (только буквенно-цифровые символы - пример ниже). Сегодня мы впервые столкнулись с проблемой такого подхода. Следующий URL:
http://oursite.com/notices/response/approve/1960/OzH0pedV3rJhefFlMezDuoOQSomlUVdhJUliAhjS
возвращает ошибку 404. Этот формат URL-адреса работает уже 6 месяцев без проблем, а другие URL-адреса, следующие в этом точном формате, продолжают разрешаться правильно. У нас очень простая конфигурация с простым перенаправлением на фронт-контроллер, а все остальное уже некоторое время работает нормально.
Кроме того, если мы изменим последний символ с «S» на любой другой, кроме «s» в нижнем регистре, ошибки 404 не будет, и сайт правильно обработает запрос, поэтому мне интересно, есть ли какой-нибудь модуль безопасности, который может что-то увидеть неправильно с этой конкретной строкой ... Не уверен, что это имеет смысл.
Мы не уверены, где искать, что конкретно вызывает проблему, поэтому мы будем очень признательны за любое указание.
Спасибо!
Обновление: добавление косой черты в конец URL-адреса позволило правильно обработать его ... Тем не менее, все же хотелось бы разобраться в сути проблемы.
Решено: проблема была вызвана частью моей конфигурации ... Понимал, что должен был написать, но уезжал из города, и у меня не было шанса.
Любой URL-адрес, заканчивающийся на "css" или "js" и не обязательно предваренный точкой (например, http://site.com/response/somerandomestringcss ) был интерпретирован как запрос файла, и этот запрос не был маршрутизирован через фронт-контроллер. Проблема заключалась в моем регулярном выражении для отключения ведения журнала и установки заголовков срока действия для jpgs, gif, icos и т. Д.
Я заменил это:
location ~* ^.+(jpg|jpeg|gif|css|png|js|ico)$ {
с этим:
location ~* \.(jpg|jpeg|gif|css|png|js|ico)$ {
И теперь URL-адреса, заканчивающиеся на css, js, png и т. Д., Правильно маршрутизируются через фронт-контроллер. Надеюсь, это поможет кому-то другому.
Из OP:
Это была проблема с файлом конфигурации; Я условно устанавливал заголовки срока действия и отключал ведение журнала для изображений, js, css, ico файлов и т. Д. У меня было:
location ~* ^.+(jpeg|jpg|gif|css|png|js|ico)${и изменил его на:
location ~* \.(jpeg|jpg|gif|css|png|js|ico)${Теперь, когда я запрашиваю URL-адрес, который заканчивается одной из этих строк, он анализирует его как URL-адрес, а не как файл, поэтому ошибок 404 больше нет.
Возможно, ваше регулярное выражение url не включает символы верхнего регистра в правильный путь. Вы можете разместить это здесь?