On Saturday 18 April 2015 10:24:17 jb wrote:
> And maybe I am approaching this the wrong way? can you comment..
>
> I want an nginx upload target for POST that reads the content, discards it,
> and reports the amount read. This is what I have in essence:
>
> location ~* "/upload" {
> limit_except POST OPTIONS { deny all; }
> client_max_body_size 0;
> add_header Cache-Control "max-age=0, no-cache, no-store, must-revalidate";
> keepalive_timeout 0;
> add_header Content-Type 'text/html';

This just adds duplicate "Content-Type" header.
See the "default_type" directive: http://nginx.org/r/default_type


> return 200 '$content_length bytes';
> }
>
> The uploads are being done with XHR on the browser side. It works, however
> randomly (less than 1% of cases), browsers fail during the POST: they
> return xhr with readyState 4 but status 0, and only a partial upload
> progress recorded.
> On the server side, no error is generated in error_log, and access_log
> reports status 200.
>
> $request_length is very short, just the header of the upload.
>
> I am wondering if this is mis-use of upload handling by nginx. However I do
> not want to setup an upstream server to receive the POST content, it is to
> be discarded anyway.
>
> Is there a more correct way to handle POST within nginx, with a response
> after all data is read, but without an upstream server?
>
[..]

Oh, ok I see what happens. Indeed, the $request_length isn't accounted if
you discard request body this way.

The workaround can be using proxy_pass to nginx itself. You don't need
to pass body however: http://nginx.org/r/proxy_pass_request_body

wbr, Valentin V. Bartenev

_______________________________________________
nginx mailing list
nginx@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx