PHP falsely triggering 413 with nginx?

Question

I'm using a proxy script (located here), which is for a two-step checkout (customer puts their billing information on step 1, clicks 'Next', then puts payment info on step 2).

When they click 'Next' on step 1, the proxy script accepts a PUT request with their entered data, then sends all of it to a 3rd party service (shopping cart).

The problem is that, on step 1 when I click submit, I get a 413 Request entity too large error.

I spent a LOT of time making sure Nginx was configured properly (it definitely is). It's something in the PHP script which is somehow falsely triggering a 413. I'm not a PHP expert, but that's the only thing I can think of.

Here are some reasons I believe it's not the Nginx config itself:

• The request is only about 10kb
• If I delete everything in the PHP file, it PUT's the data perfectly fine. It's only this script above is somehow triggering it.
• I have all the necessary PHP variables set (there were 4 of them I believe). All are set to 128M
• client_max_body_size is properly set to 32M

Here are reasons I know it's not the 3rd party server

• It works fine on apache
• Many other people (on apache) are using it successfully

Very Simple one-click download to try it yourself (if you feel like it)

If you want to tinker with it, download the zip, and upload to an nginx server:

• https://github.com/UltraCart/two_page_trial/archive/master.zip

You don't need to make any changes. Just upload, visit trial-page1.html and click the big Order Now button. You will see it logs 413 errors to console.

I don't even know how to go about debugging this, I would assume it's some kind of problem with the way curl is being used?

Answer 1

There is nothing particularly nginx specific about this issue - you are adding duplicate headers...specifically, two Content-Length headers: one in your foreach ($_SERVER as $i => $val) { ... } loop, one explicitly in $header[] = "Content-Type: " . $content_type;

A few small modifications to your script are available at this gist; note that it only scratches the surface of the things wrong with this script, even if you're willing to accept that doing a PHP proxy is a good idea to begin with...