multipart upload [was: ngx.location.capture and net::ERR_INCOMPLETE_CHUNKED_ENCODING]

lordnynex · 2014-05-21T14:45:04+00:00

Hello! On Sat, Jun 7, 2014 at 10:34 AM, Mathew Heard wrote: > The purpose of this was to allow exact control over the flow body data of a > request (a...

multipart upload [was: ngx.location.capture and net::ERR_INCOMPLETE_CHUNKED_ENCODING]

lordnynex

agentzh,

I've been troubleshooting a similar issue for failed requests on 'multipart/form-data' PUT's to an upstream back end. I haven't figured out if the problem is with nginx or my backend. Your response below makes me wonder what constitutes a sub-request? Will this not work because the named location is considered a sub request? In my most recent round of testing my error logs show nothing, and the access log indicates the response status sent to the client was a 500 error. The upstream error logs indicate the correct content length but is not able to read any data from the request body.

My configuration looks like:

upstream fileuploads { server 192.168.0.10:80; keepalive 64; }

limit_req_zone $binary_remote_addr zone=fileupload:10m rate=1r/s;

server {

listen 80;

location @FileUploads {

limit_req zone=fileupload burst=1 nodelay;

proxy_pass http://fileuploads;

}

location = "/fileupload" { echo_exec @FileUploads; }

location = "/fileuploads" { echo_exec @FileUploads; }

}

> Would headers from the upstream cause "premature" response to the client?
>

As long as your upstream is accessed directly in your main request
(that is, not in a subrequest initiated by ngx.location.capture, for
example).

> My configuration is like this
>
> location /internal_loc/ {
> proxy_pass http://backend/;
> }
> upstream backend {
> server 133.0.0.1:8888;
> keepalive 36;
> }
>

This config snippet is incomplete.

agentzh

Hello!

On Tue, May 20, 2014 at 11:45 PM, Lord Nynex wrote:
> I've been troubleshooting a similar issue for failed requests on
> 'multipart/form-data' PUT's to an upstream back end.

I suggest you use tools like nc, tcpdump, and wireshark to debug
backend issues on the TCP level. The nginx debugging logs can be
helpful as well.

> I haven't figured out
> if the problem is with nginx or my backend. Your response below makes me
> wonder what constitutes a sub-request?

Your example uses echo_exec which initiates an internal redirect
rather than a subrequest.

> Will this not work because the named
> location is considered a sub request?

You cannot initiate a subrequest to a named location, not to mention
you're not using subrequests at all.

Please read my nginx tutorials for some nginx basics:

    http://openresty.org/download/agentzh-nginx-tutorials-en.html

> In my most recent round of testing my
> error logs show nothing, and the access log indicates the response status
> sent to the client was a 500 error.

Everytime you see a 500 error, you should check out your nginx
error.log file (and ensure you're not using an "error_log" filtering
level that is too high).

> The upstream error logs indicate the
> correct content length but is not able to read any data from the request
> body.
>

The original error message should be much more helpful than your
(vague) English description.

Best regards,
-agentzh

lordnynex

Thank you for the response. Sorry for the vague error messages. It's sometimes difficult to provide examples without leaking proprietary or identifying information. I will take some pcap's and look at the stream. The part I'm confused about is that the 500 is returned from the backend and not nginx. I need to do further testing.

On Wed, May 21, 2014 at 11:38 AM, Yichun Zhang (agentzh) <age...@gmail.com> wrote:

Hello!

On Tue, May 20, 2014 at 11:45 PM, Lord Nynex wrote:
> I've been troubleshooting a similar issue for failed requests on
> 'multipart/form-data' PUT's to an upstream back end.

I suggest you use tools like nc, tcpdump, and wireshark to debug
backend issues on the TCP level. The nginx debugging logs can be
helpful as well.

> I haven't figured out
> if the problem is with nginx or my backend. Your response below makes me
> wonder what constitutes a sub-request?

Your example uses echo_exec which initiates an internal redirect
rather than a subrequest.

> Will this not work because the named
> location is considered a sub request?

You cannot initiate a subrequest to a named location, not to mention
you're not using subrequests at all.

Please read my nginx tutorials for some nginx basics:

http://openresty.org/download/agentzh-nginx-tutorials-en.html

> In my most recent round of testing my
> error logs show nothing, and the access log indicates the response status
> sent to the client was a 500 error.

Everytime you see a 500 error, you should check out your nginx
error.log file (and ensure you're not using an "error_log" filtering
level that is too high).

> The upstream error logs indicate the
> correct content length but is not able to read any data from the request
> body.
>

The original error message should be much more helpful than your
(vague) English description.

Best regards,
-agentzh
.