logging variables -- $bytes_sent .. where is $bytes_read ?
jb
justinbeech at gmail.com
Sat Apr 18 01:23:54 UTC 2015
gotcha, I saw the discarded body thing in the debug log. ok thanks,
um, how do you proxy_pass to nginx itself ?
can you give an example ?
just proxy_pass http://127.0.0.1/
and proxy_pass_request_body off
what about my return 200 "$content_length bytes" line still keep that?
On Sat, Apr 18, 2015 at 11:10 AM, Valentin V. Bartenev <vbart at nginx.com>
wrote:
> 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 at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20150418/58590dde/attachment.html>
More information about the nginx
mailing list