Nginx as reverse proxy causes failure to respond to certain POST requests

asp.netnginx

(specifically, the ASP.NET postbacks – but even then only some of them)

I have nginx configured to reverse proxy an ASP.NET server. Most of it works perfectly fine. All GET requests work, and most POST requests work too. Most ASP.NET postbacks work. But there is the occasional postback which, for some strange reason that I haven't figured out, fails to ever receive a response, every single time (i.e. it is guaranteed to fail).

This particular server is configured so that one can access the ASP.NET instance directly (bypassing nginx) by specifying a port number. When nginx is bypassed, everything works perfectly and all requests are responded to instantly.

What can I do to debug this further? I haven't been able to get Nginx to log events like starting and ending the upstream requests/responses, let alone their entire bodies. Fiddler can't help because there is nothing wrong with the request from browser to nginx; the issue occurs between nginx and ASP.NET. Any other ideas?

Config excerpt: http://pastebin.com/FyTtuUQZ

It might have something to do with keepalives, because the postback eventually times out after roughly 65 seconds – the time specified in the above config as the keepalive timeout. But this might be a red herring.

P.S. It's a development-only server, and the purpose of reverse proxying it is so that we can point several domains at this one machine and have incompatible servers all appear as if they were on port 80. But in order for me to trust nginx reverse-proxying production servers, I need to understand this problem to make sure it won't affect production.

Best Answer

The problem: ASP.NET development server sends a 100 Continue response even when there was no Expect: 100-continue in the request. Nginx will issue a request with no Expect header; ASP.NET will respond with one, then receive the rest of the request, and then send the actual response. Nginx, however, will only forward the 100 Continue part. It will not forward the actual response; that gets swallowed, at least on nginx 1.4.2.

The solution: use IIS, even though this whole set-up was for development purposes only.