Thanks for the warning! I have to admit i was a little surprised to learn that, arguably, the two major browsers don't implement 100-continue and have no plan to do so. I know our scenario is far from typical but POST uploads are surely widespread. Thanks to all for your help on this, the support provided by this forum is really great and much appreciated.by garyc - Nginx Mailing List - English
Thanks, understood. Got a bit excited when I realized our client wasn't sending the 'Expect: 100-continue' header in our POST but as you have pointed out even with this header Chrome and Firefox do not stop sending the body.by garyc - Nginx Mailing List - English
Looks like support for 100 Continue: https://www.w3.org/Protocols/rfc2616/rfc2616-sec8.html#sec8.2.3 may have covered our scenario, I found an old ticket on this https://trac.nginx.org/nginx/ticket/493#no1 I guess there is no intention to support this in a future release? We can live with a 2 stage process for now, may look to move to http 2 for other reasons in the future, we can aby garyc - Nginx Mailing List - English
I had a look around for expected behavior during large http 1.x POST requests, it looks like the standards suggest that browsers should monitor for 413 responses and terminate the body transmission but they don't: https://stackoverflow.com/questions/18367824/how-to-cancel-http-upload-from-data-events/18370751#18370751 Chrome and Firefox have issues 4+ years old on this, doesn't look likely tby garyc - Nginx Mailing List - English
Ok, thanks, I will look into tcpdump. In your opinion, in principle, is what i am attempting feasible? >In the second case, 30 seconds after the response was sent by nginx, the >request body still wasn't received and nginx had nothing to do than just >close the connection. This suggests to me that although i am attempting to intercept the request header and reject it if there is iby garyc - Nginx Mailing List - English
Hello, thanks for explaining, can I ask, in the 5MB scenario (client accepted 413 response) the logs show: 2017/09/21 12:06:41 21560#0: *1 http run request: "/pcapLowDiskSpace.html?" 2017/09/21 12:06:41 21560#0: *1 http read discarded body 2017/09/21 12:06:41 21560#0: *1 recv: eof:0, avail:1 2017/09/21 12:06:41 21560#0: *1 recv: fd:3 2159 of 2159 2017/09/21 12:06:41 21560#0:by garyc - Nginx Mailing List - English
Apologies, I posted this issue to the wrong list (php-fpm), the link is: > https://forum.nginx.org/read.php?3,276451,276475#msg-276475 It has debug log file extracts that seem to suggest the location redirect to a static error page is attempted but doesn't resolve. Many thanksby garyc - Nginx Mailing List - English
The log extract >2017/09/21 12:09:02 22090#0: *1 http run request: "/pcapLowDiskSpace.html?" should have read 2017/09/21 12:09:02 22090#0: *1 http run request: "/lowDiskSpace.html?"by garyc - Php-fpm Mailing List - English
garyc Wrote: ------------------------------------------------------- > The next step will be to get a debug version of nginx setup to see if > there is any indication of the problem, the default nginx error log is > not reporting any problems. Further to this I have run some tests with the debug information active in nginx. I placed an error log statement with the debug option at tby garyc - Php-fpm Mailing List - English
garyc Wrote: ------------------------------------------------------- > The next step will be to get a debug version of nginx setup to see if > there is any indication of the problem, the default nginx error log is > not reporting any problems. Further to this I have run some tests with the debug information active in nginx. I placed an error log statement with the debug option at tby garyc - Php-fpm Mailing List - English
Hello, thanks to the support of this forum I managed to configure nginx to use the http_auth_request module to intercept a file upload request and verify there is enough disk space left to store the file, rejecting the request if there isn't. This works fine for smaller files; the auth_request redirects to the php script which either validates (returning 200) or rejects the request (returning 4by garyc - Php-fpm Mailing List - English
Apologies, please ignore the line > The fastcgi_params file we include in the above location blocks include the lines What followed wasn't really relevant (just about overriding php.ini values with the PHP_VALUE command) so i removed it.by garyc - Nginx Mailing List - English
Hi, Reinis has probably covered this but the default php.ini file has a 'File Upload section' with... ; Temporary directory for HTTP uploaded files (will use system default if not ; specified). ; upload_tmp_dir = I just uncommented the attribute and set it to a location on our main disk e.g. upload_tmp_dir = /opt/tmp -- The complete solution involved using the http_auth_request_by garyc - Nginx Mailing List - English
Please ignore the last message, having learned a bit more about probing the file system we can now see that it is PHP that is caching the file to the system default location (hence rootfs) a small change to the PHP configuration has sorted this. Thanks to everyone for your help Garyby garyc - Nginx Mailing List - English
Hello, Thanks for the hint I have managed to use the auth request module to check available disk space before accepting the request so I only attempt the upload if there is disk space available. I am now having another problem. Our debian environment uses a rootfs ramdisk which has just under 1GB of memory, when i accept the upload request I can see the rootfs disk fill steadily until it is fuby garyc - Nginx Mailing List - English
Hi Maxim, > With "fastcgi_request_buffering off;" nginx will send the request > body to the FastCGI application immediately, without trying to > buffer it anywhere. I have been monitoring the disk space while uploading a test file of 1.1 GB in size and have confirmed that with the fastcgi_request_buffering directive set to 'on' the disk space reduces by approximately 2by garyc - Nginx Mailing List - English
Thank you, it sounds like this approach may yet work. > It is up to your FastCGI application to handle this though, > and PHP as well as PHP-FPM may impose additional limitations > and/or require additional configuration for this to work. I will dig into the php configuration details and see if i can progress this, it is reassuring to hear that the fastcgi_request_buffering direby garyc - Nginx Mailing List - English
Hello, hopefully someone can tell me if i am attempting the impossible. We use nginx and php5-fpm to handle the upload of test files used by our web app that may be several gigabytes in size. To achieve this we use a location block for the upload url and define the fastcgi_pass directive to provide the location of the fastcgi socket i.e. location /api/filter/analysis/upload { fastcgby garyc - Nginx Mailing List - English