Clientbodyinfileonly - POST request is discarded

Francis Daly francis at daoine.org
Wed Oct 12 21:44:43 UTC 2016


On Wed, Oct 12, 2016 at 03:34:45PM -0400, yurai wrote:

Hi there,

> >Are you reporting that the content of the client-file upload.txt is not
> >saved on the nginx server that is localhost, in a numbered file below
> >your client_body_temp_path?
> 
> Yes. Exactly this. My /tmp/nginx-client-body directory is empty.

Ok, that is unexpected to me.

I've read back over the mail thread, and there seem to be a few things
where it is not clear to me what exactly is happening.

Can you make a test nginx.conf that is very simple, in an attempt to
isolate where things are going wrong?

I use this:

==
events {}
http {
    server {
        listen 8008;
        location = /upload {
            client_body_temp_path /tmp/clientb;
            client_body_in_file_only on;
            proxy_set_header X-FILE $request_body_file;
            proxy_pass http://127.0.0.1:8008/upstream;
        }
        location = /upstream {
            return 200 "Look in $http_x_file\n";
        }
    }
}

==

and when I do

  curl -v --data-binary words http://127.0.0.1:8008/upload

I see the POST with Content-Length: 5; I get a response of "Look in " and a
filename, and when I "ls -l" that filename I see that it is 5 bytes long.

I use /tmp/clientb as the client directory above; that directory did
not exist before I reloaded nginx, so nginx will create it with suitable
permissions.


When I then do

  curl -v --data-binary @upload.txt http://127.0.0.1:8008/upload

I see the POST with Content-Length: 16; I get a response of "Look in "
and a different filename, and when I "cat" that filename I see the same
16-byte content as was in my original local upload.txt file.

When you do exactly that, do you see anything different?


Note that this is *not* exactly the same as your original case, because
it leaves out many of the config directives. In particular, this *does*
send the initial POST content to the upstream. That's ok; the point of
this is to find out why and where the initial set-up is broken. Other
bits can be added afterwards.

> >There is more than one server involved. Please be very clear which one
> >you are referring to, when you refer to any.
> 
> Please notice that in many places I try to be precised as much as possible
> by reffering to s1 and s2. Sorry for confusion. 

Actually, I'm wrong there, sorry about that. I had got confused with a
separate mail; your mails were clear about the two server blocks on the
one nginx on localhost.

Thanks,

	f
-- 
Francis Daly        francis at daoine.org



More information about the nginx mailing list