mod_rewrite внезапно не работает, ТОЛЬКО для входящих запросов POST от Foursquare API
У меня есть конечная точка на моем веб-сайте, откуда я получаю push-уведомления от FourSquare API. Конечная точка:
https://www.example.com/auth/foursquare/
На самом сервере исходный файл:
/home/myusername/public_html/www.example.com/auth/foursquare/index.php
Обычно файлы сайта находятся в:
/home/myusername/public_html/
Но я использую mod_rewrite, чтобы вместо этого поместить их в подкаталог обычного корневого веб-каталога:
/home/myusername/public_html/www.example.com/
Это правила mod_rewrite:
RewriteCond %{HTTP_HOST} ^(www.)?example.com$ [NC]
RewriteRule ^(.*)$ /www.example.com/$1 [L]
Пока все хорошо. Все работает так, и работает без проблем много лет. Пока внезапно, пару месяцев назад, толчки FourSquare перестали поступать. Исследование журналов ошибок сервера показало, что по какой-то причине он теперь пытается обслуживать файлы по исходному (не перезаписанному) пути:
2019-12-30 00:26:31.383141 [INFO] [34.231.230.177:15669] File not found [/home/myusername/public_html/auth/foursquare/]
2019-12-30 00:26:31.383256 [INFO] [34.231.230.177:15669] File not found [/home/myusername/public_html/404.shtml]
Что действительно странно, так это то, что это происходит ТОЛЬКО, когда входящий запрос приходит от самого Foursquare API:
- Я могу ПОСЕТИТЬ https://www.example.com/auth/foursquare/ в браузере, и он обслуживает правильный файл.
- Я могу отправить POST на https://www.example.com/auth/foursquare/ с помощью Postman, Insomnia или любого другого инструмента тестирования API, и он обслуживает правильный файл. Даже если я точно воспроизведу заголовки и данные POST из FourSquare (что я определил, изменив приложение FourSquare для отправки на конечную точку подключения, чтобы я мог проверить точные данные, которые они отправляют).
Единственный общий знаменатель, о котором я могу думать, - это IP-адрес источника; когда POST приходит с IP-адреса FourSquare, mod_rewrite обслуживает не ожидаемый файл из подкаталога, а со всех остальных IP-адресов. Хотя, очевидно, у меня нет никаких правил, специфичных для IP, которые могли бы вызвать это, так что на самом деле это не имеет смысла.
Поскольку код или правила htaccess не были изменены с моей стороны в течение очень долгого времени (т.е. задолго до того, как это спонтанно началось), очевидно, что мой (общий) веб-хост должен был изменить некоторую конфигурацию сервера, которая его нарушила. . Но я обменялся с ними более чем 20 сообщениями, и они все время возвращаются к «мы не знаем, почему это происходит, просто создайте символическую ссылку с исходного пути, и это сработает». Это правда, создание символической ссылки из / home / myusername / public_html / auth / на /home/myusername/public_html/www.example.com/auth/ работает. Однако это на самом деле не объясняет, почему он внезапно сломался, и решения IMO для слепых пластырей редко бывают хорошей идеей. Что, если все, что сломалось, повлияло и на что-то еще, чего мне еще не посчастливилось заметить? Я хотел бы точно понять, что происходит, почему он самопроизвольно перестал работать и как правильно это исправить. К сожалению, кажется довольно очевидным, что веб-хостинг - который кажется наиболее вероятным виновником - не поможет.
Если у кого-нибудь есть идеи, я буду очень признателен.
Reqhost был установлен на:"www.example.com:443"
Это, безусловно, может быть причиной проблемы. Хотя , почему порт (, на который отправляется запрос, )теперь присутствует в заголовке Host— это другой вопрос. 443— порт по умолчанию для HTTPS. Однако, поскольку это порт по умолчанию , для него не требуется, чтобы присутствовал в заголовке Host. Вам потребуется только указанный порт, если вы обслуживаете контент с не-стандартных портов.
Возможно, FourSquare начал скрытно включать номер порта как часть запроса (, предполагая, что это не было ошибочно установлено в вашей конфигурации на FourSquare?)-хотя это, возможно, было бы неправильно (хотя и не является строго нарушением спецификации )поскольку это ограничит ваш сервер использованием портов по умолчанию (вы должны иметь возможность использовать любой порт, который вы хотите ).
Другая возможность заключается в том, что у вас есть (новый)передний-прокси-сервер, который, возможно, добавляет номер порта к пересылаемому запросу на ваш сервер приложений. Но это маловероятно, поскольку предположительно это повлияет на все запросы, а из ваших тестов это не так.
Похоже, что «исправление» заключается в том, чтобы разрешить номер порта в запросе (, предполагая только порт 443, а не порт 80 -обычный HTTP).
Например,:
RewriteCond %{HTTP_HOST} ^(www\.)?example\.com(:443)?$ [NC]
RewriteRule (.*) /www.example.com/$1 [L]
(:443)?делает номер порта необязательным в заголовке Host(, если ситуация изменится сама собой).
Не забудьте экранировать точки в регулярном выражении(CondPattern).
^(.*)$можно упростить до (.*), поскольку по умолчанию регулярное выражение является жадным.