Simple proxy_pass settings are invalidating/deleting multipart file data sent by POST

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Simple proxy_pass settings are invalidating/deleting multipart file data sent by POST

Denis Papathanasiou
As noted here -- https://github.com/gin-gonic/gin/issues/1582 -- I have a simple web app that handles multipart form file uploads correctly on its own, but when I put it behind a simple proxy_pass configuration like below, the underlying application sees a null value where the file form data was.

This is the configuration I am using:

location / {
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header Host $host;
    proxy_pass https://127.0.0.1:9001;
}

I have also experimented with setting setting proxy_request_buffering to 'off' but still gave me the same result.

If it is not a problem with the wen framework (and based on the logs I suspect it is not), how can I update my nginx config so it works properly?

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Simple proxy_pass settings are invalidating/deleting multipart file data sent by POST

Francis Daly
On Sat, Oct 06, 2018 at 05:15:50PM -0400, Denis Papathanasiou wrote:

Hi there,

> As noted here -- https://github.com/gin-gonic/gin/issues/1582 -- I have a
> simple web app that handles multipart form file uploads correctly on its
> own, but when I put it behind a simple proxy_pass configuration like below,
> the underlying application sees a null value where the file form data was.

If you "tcpdump" (or otherwise) and look at the traffic going to
nginx, and going to the backend, when an upload happens, do you see
any difference?

I've tried a quick test using a command like

  curl -v -F file=@/etc/hosts http://localhost:8000/x/

and the only obvious-to-me difference is that nginx sees the client
"Expect: 100-Continue" request header, but does not send that to upstream.

I think that that should probably not make a difference to the upstream
service.

> If it is not a problem with the wen framework (and based on the logs I
> suspect it is not), how can I update my nginx config so it works properly?

I suspect that you'll have to do some more investigation, to see what is
different on your upstream server when nginx is and is not involved. That
might help point at the problem, and see whether the solution is in
nginx or elsewhere.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Simple proxy_pass settings are invalidating/deleting multipart file data sent by POST

Denis Papathanasiou


I think that that should probably not make a difference to the upstream
service.

Correct, I did confirm that `proxy_pass` is sending the entire multipart form request.

I suspect that you'll have to do some more investigation, to see what is
different on your upstream server when nginx is and is not involved. That
might help point at the problem, and see whether the solution is in
nginx or elsewhere.

Right, it turns out nginx was working correctly, and the real problem is somewhere in the web framework  I am using.

I've updated the issue on github accordingly: https://github.com/gin-gonic/gin/issues/1582

Thank you for replying so promptly.


_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: Simple proxy_pass settings are invalidating/deleting multipart file data sent by POST

Francis Daly
On Sun, Oct 07, 2018 at 06:53:26PM -0400, Denis Papathanasiou wrote:

Hi there,

> Correct, I did confirm that `proxy_pass` is sending the entire multipart
> form request.

Thanks for following up with the nginx-related info; it'll help the next
person with the same problem know where to look to prove that nginx is
or is not at fault :-)

> Right, it turns out nginx was working correctly, and the real problem is
> somewhere in the web framework  I am using.

Good luck getting the problem fixed.

Cheers,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx