У меня есть конечная точка на моем веб-сайте, на которую я получаю 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:
Единственный общий знаменатель, о котором я могу думать, - это 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).
^(.*)$ можно упростить до (.*) поскольку регулярное выражение по умолчанию является жадным.