Сегодня я хотел написать небольшой полезный совет для людей, пытающихся выполнять POST-запросы к статическим файлам. По-видимому, в этих случаях Nginx возвращает 405 недопустимый ответ.
Вот пара обходных путей, которые помогут вам снова начать работу:
server {
listen 80;
server_name test.com;
root /my/root;
error_page 405 =200 $uri;
location / {
index index.html index.htm;
}
# ...
}
Итак, в этом первом примере есть небольшая хитрость — каждый POST (с 405) в статический файл направляется обратно на тот же uri, но = 200 меняет код ответа на 200. Для захвата определенных URL-адресов нам может потребоваться создать больше местоположений, поскольку Nginx будет выполните дополнительный поиск ошибок.
Вот чуть более интересный пример (динамический конфиг):
...
error_page 405 = @app;
location @app {
proxy_pass http://backend;
}
....
В этом случае мы отправляем все ошибки POST 405 в указанное местоположение @app, которое затем передает запрос вышестоящим серверам. Также обратите внимание, что в этом случае мы не устанавливаем конкретный код статуса, поэтому любой возврат вышестоящего сервера будет установлен как код статуса.
Последний пример я нашел в сети, не помню где именно. Идея выглядит так:
server {
listen 80;
root /my/root;
error_page 405 = $uri;
# magic happens here
rewrite ^.*$ /api.json last;
location / {
index index.html;
}
}
Давайте посмотрим, что здесь происходит — сначала мы отправляем запрос POST в api.json (который является нашим статическим файлом), затем мы проксируем ошибку 405 на исходный URL-адрес (по существу запускает новый поиск Nginx), и наше условие перезаписи соответствует запросу и возвращает api .json с кодом состояния 200. Вы можете пойти еще дальше и перенести перезапись в определенное место или обновить правило регулярного выражения, чтобы оно соответствовало только некоторым URL-адресам.