This issue has been address in mod_wsgi 4.0 trunk in source code
repository if you can check that it now works as required.
Graham
On 28 October 2011 09:43, Graham Dumpleton graham.dumple...@gmail.com wrote:
Here is the reason.
For daemon mode, partially out of convenience as could reuse some
I'm trying to implement a limit on the size of uploaded files which depends
on a user's status, i.e. a user who pays gets to upload larger files than
one who doesn't. I want to check the size of the upload BEFORE reading the
data because I don't want to read 27 gigabytes only to find that this
If I recall correctly, when I wrote the code to read uploaded files, it was
one chunk at a time (eg 4096 bytes). Wouldn't this give you the
opportunity to stop at the right point?
take a look at github.com/appcove/AppStruct ...
Python/AppStruct/WSGI/Lib.py (or related, maybe werkseug.py) to see
No, the problem is that the entire file is (apparently) read by modwsgi
before the application code is run at all.
--
You received this message because you are subscribed to the Google Groups
modwsgi group.
To view this discussion on the web visit
I am pretty sure this is not the case...
Looking forward to Graham's comments.
Look at docs on environ['wsgi.input'].
Thanks!
On Nov 24, 2011 3:00 PM, Lisper ron.gar...@gmail.com wrote:
No, the problem is that the entire file is (apparently) read by modwsgi
before the application code is run
Do you mean sent rather than read?
Except for Opera, browsers don't implement 100-continue and so the
browser will always send the huge upload anyway. If the browser said
it is using HTTP/1.1 then Apache doesn't have a choice but to still
read the entire request content to throw it away if you
BTW, don't expect to see your nice message in the browser even when
using 413. Because a browser not implementing 100-continue as it
should, they usually don't try and deal with a response before sending
all data. Because Apache will close input side of connection, the
browser will fail sending
Wow, that really sucks. It does indeed appear to be the case that the
server is doing the Right Thing and it's the browser that's screwing this
up. Bummer. I guess it's time to break out the client-side Javascript
filefrobber object :-(
Thanks, Graham!
--
You received this message because
I user ubuntu 10.04 Apache/2.2.14 mod_wsgi 2.8.
I use WSGIDaemonProcess server user=demon group=demon ,but when I
print sys.stderr,os.environ,I see the result:
'''
[Fri Nov 25 15:23:12 2011] [error] {'LANG': 'C', 'SHLVL': '1',
'APACHE_RUN_USER': 'www-data', 'APACHE_PID_FILE': '/var/run/
On 25 November 2011 18:28, Chunlin Zhang zhangchun...@gmail.com wrote:
I user ubuntu 10.04 Apache/2.2.14 mod_wsgi 2.8.
I use WSGIDaemonProcess server user=demon group=demon ,but when I
print sys.stderr,os.environ,I see the result:
'''
[Fri Nov 25 15:23:12 2011] [error] {'LANG': 'C', 'SHLVL':
After I add WSGIProcessGroup directive,my app work ok now,but the
print sys.stderr,os.environ still www-data.
It works now but weird.
On Fri, Nov 25, 2011 at 3:28 PM, Chunlin Zhang zhangchun...@gmail.com wrote:
I user ubuntu 10.04 Apache/2.2.14 mod_wsgi 2.8.
I use WSGIDaemonProcess server
11 matches
Mail list logo
