Nginx POST请求变成GET请求

我有一个带有nginx和unicorn的Rails 4.1应用程序。一些POST请求被转换为GET请求。我想这和我的nginx配置有关。这是关于它的最新消息

以下是my nginx.conf文件：

# you generally only need one nginx worker unless you're serving
# large amounts of static files which require blocking disk reads
worker_processes 3;

# # drop privileges, root is needed on most systems for binding to port 80
# # (or anything < 1024).  Capability-based security may be available for
# # your system and worth checking out so you won't need to be root to
# # start nginx to bind on 80
user nobody nogroup; # for systems with a "nogroup"
# user nobody nobody; # for systems with "nobody" as a group instead

# Feel free to change all paths to suite your needs here, of course
pid /run/nginx.pid;
# error_log /path/to/nginx.error.log;

events {
  worker_connections 1024; # increase if you have lots of clients
  accept_mutex off; # "on" if nginx worker_processes > 1
  # use epoll; # enable for Linux 2.6+
  # use kqueue; # enable for FreeBSD, OSX
}

http {
  # nginx will find this file in the config directory set at nginx build time
  include mime.types;

  # fallback in case we can't determine a type
  default_type application/octet-stream;

  # click tracking!
  # TODO: Fixme
  # access_log /path/to/nginx.access.log combined;

  # you generally want to serve static files with nginx since neither
  # Unicorn nor Rainbows! is optimized for it at the moment
  sendfile on;

  tcp_nopush on; # off may be better for *some* Comet/long-poll stuff
  tcp_nodelay off; # on may be better for some Comet/long-poll stuff
  keepalive_timeout 65;
  types_hash_max_size 2048;

  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;

  # we haven't checked to see if Rack::Deflate on the app server is
  # faster or not than doing compression via nginx.  It's easier
  # to configure it all in one place here for static files and also
  # to disable gzip for clients who don't get gzip/deflate right.
  # There are other gzip settings that may be needed used to deal with
  # bad clients out there, see http://wiki.nginx.org/NginxHttpGzipModule
  gzip on;
  gzip_http_version 1.1;
  gzip_proxied any;
  gzip_min_length 500;
  gzip_disable "MSIE [1-6]\.";
  gzip_types text/plain text/html text/xml text/css
             text/comma-separated-values
             text/javascript application/x-javascript
             application/atom+xml;

  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

}

出于安全原因，我隐藏了一些信息。有什么想法吗

server {
 server_name www.my-app.com
 return 301 $scheme://my-app.com$request_uri;
}

这将无条件地向www.my-app.com的每个请求抛出301

如果配置中没有其他

return301

：请检查表单操作（或ajax请求）是否使用的不是www.my-app.com域，而是my-app.com，因此不会重写

---

如果配置中有其他301（为发布而删除），则可能会有所不同。

您可能还需要尝试307重定向。我发现我的帖子在301重定向下变成了GET

即，您的服务器块变为：

server {
    server_name www.my-app.com my-app.com;
    return 307 $scheme://$host$request_uri;
}

---

你发布到哪个uri？例如，如果您发布到以斜杠结尾的url，由于

rewrite^/（.*）/$/$1永久性，您将重定向到不带斜杠的url我试过了，效果很好，但我发现很难理解。你能简单解释一下吗？@ZiyanJunaideen我不明白为什么，但原因是“307代码表明后续请求应该使用与原始请求相同的HTTP方法（所以GET保持GET，而POST保持POST，等等）。”301/2将POST转换为GET。。。看起来很傻，但就是这样！阅读更多：有趣的是。。。这只影响了我的流浪汉。。。我有很多服务器可以在301上正常工作。。。“原始请求的方法和主体被重新使用以执行重定向请求。”谢谢，我使用Certbot并启用重定向设置，默认情况下它使用301。
server {
    server_name www.my-app.com my-app.com;
    return 307 $scheme://$host$request_uri;
}