> On 5 Mar 2018, at 2:17 am, Cristiano Coelho <[email protected]> wrote:
> 
> Hi Graham, thanks for the response, that indeed looks like a tricky thing to 
> implement.
> 
> There's another scenario that might also benefit from something like this, 
> for example, when uploading large files (I know this is usually not the best 
> thing to do, and rather it should be uploaded directly to the storage such as 
> S3) and you do some server side checks with python that ends up with an error 
> (such as checking the request content length to avoid large uploads) even if 
> you return a response right away with the error without even touching the 
> file, the user will still need to wait until the whole file is uploaded (and 
> probably saved locally as a temp file with django) before getting the error 
> back.

If you rely on LimitRequestBody directive in Apache to limit request content 
size, it should be rejected before attempting to send the request through to a 
daemon process. You should only have issue with waiting for 413 response if was 
implemented in the WSGI application.

Graham

> El domingo, 4 de marzo de 2018, 0:49:31 (UTC-3), Graham Dumpleton escribió:
> I got quite a lot done on mod_wsgi during my holidays, but that didn't 
> include a simple answer to this. The idea I initially had couldn't work. The 
> only way I have been able to work out that might work is when have request 
> content and it is over a certain size, is to spawn a second thread for the 
> request handler in Apache that handles pushing the request content through to 
> the mod_wsgi daemon process, while the original thread deals with the 
> response. This is obviously going to be tricky to implement and I ran out of 
> time while I was on holidays. Am back busy at my day job now and so haven't 
> had a chance to pursue it further. I haven't even released a new version with 
> all of what I did manage to get done when on holidays, which I should really 
> do.
> 
> Graham
> 
>> On 3 Mar 2018, at 2:57 am, Cristiano Coelho <cristia...@ <>gmail.com 
>> <http://gmail.com/>> wrote:
>> 
>> Hi Graham, got any updates related to this? Have been trying to reach out 
>> AWS to update their mod_wsgi versions but seems like an useless effort.
>> 
>> 
>> 
>> El domingo, 10 de diciembre de 2017, 20:23:01 (UTC-3), Graham Dumpleton 
>> escribió:
>> Anyway, am looking into something about how daemon mode works to see if I 
>> can short circuit things to possibly partly avoid the problem.
>> 
>> Will update later.
>> 
>> Graham
>> 
>>> On 11 Dec 2017, at 10:21 am, Cristiano Coelho <cristia...@ <>gmail.com 
>>> <http://gmail.com/>> wrote:
>>> 
>>> Sorry, I think it was a typo when I tried the commands, my tests were with 
>>> just HTTP after all, and I see the same issue, if I use HTTPS the slowloris 
>>> script just stops instantly.
>>> 
>>> The logs from the main post were with HTTPS indeed but that's because the 
>>> server uses HTTPS. The local test was done only with HTTP.
>>> 
>>> 
>>> El domingo, 10 de diciembre de 2017, 19:48:59 (UTC-3), Graham Dumpleton 
>>> escribió:
>>> I will try and provide a better explanation of why solving it is hard 
>>> later, but if I change:
>>> 
>>>     slowhttptest -c 6 -B -i 10 -r 200 -s 8192 -t POST -u 
>>> "https://localhost:8080/test <https://localhost:8080/test>" -x 10 -p 3
>>> 
>>> to:
>>> 
>>>     slowhttptest -c 6 -B -i 10 -r 200 -s 8192 -t POST -u 
>>> "http://localhost:8080/test <http://localhost:8080/test>" -x 10 -p 3
>>> 
>>> Ie., non HTTPS, since mod_wsgi-express is only accepting HTTP, then I don't 
>>> see any immediate response being logged in the access log.
>>> 
>>>    mod_wsgi-express start-server app.py --port 8080 --body-timeout 62 
>>> --log-to-terminal --access-log
>>> 
>>> Other than that, the behaviour I see is as I would expect.
>>> 
>>> Graham
>>> 
>>>> On 11 Dec 2017, at 5:06 am, Cristiano Coelho <cristia...@ <>gmail.com 
>>>> <http://gmail.com/>> wrote:
>>>> 
>>>> Update: Here's a small wsgi test script, tested with a fresh apache 
>>>> mod_wsgi installation (through pip).
>>>> 
>>>> The same issue can be easily replicated, and it seems that the only way to 
>>>> improve it is with the request timeout values (header and body), which 
>>>> sadly needs to be high when using AWS due to how the load balancer works 
>>>> (keeping open connections to the apache server to improve loading time).
>>>> 
>>>> The same issue happens with another server like gunicorn, which they 
>>>> clearly state on their docs it's an issue that WILL happen unless the 
>>>> reverse proxy (nginx) is properly set up. Now for Apache + mod_wsgi, I 
>>>> would expect that apache is the reverse proxy (even if there's a load 
>>>> balancer before it) and it should help with the issue just like nginx and 
>>>> gunicorn, or even IIS + asp.net <http://asp.net/>
>>>> 
>>>> 
>>>> from flask import Flask, request, jsonify
>>>> 
>>>> # pip install Flask
>>>> 
>>>> # Testing flask
>>>> # export FLASK_APP=app.py
>>>> # flask run
>>>> 
>>>> 
>>>> # Testing mod_wsgi
>>>> # pip install mod_wsgi (and apache2 + apache2-dev before this if it's not 
>>>> installed)
>>>> # Create user wsgi or change user
>>>> # sudo -u wsgi mod_wsgi-express start-server app.py --port 8080 
>>>> --body-timeout 62
>>>> # Set --body-timeout to simulate AWS setup
>>>> 
>>>> # Interesting settings
>>>> # --connect-timeout defaults to 15s
>>>> # --queue-timeout defaults to 30s
>>>> # --body-timeout defaults to 15s
>>>> 
>>>> 
>>>> # Test slowloris:
>>>> # apt-get install slowhttptest 
>>>> # 6 or a value > configured worked threads*processes
>>>> # slowhttptest -c 6 -B -i 10 -r 200 -s 8192 -t POST -u 
>>>> "https://localhost:8080/test <https://localhost:8080/test>" -x 10 -p 3
>>>> # Note that GET also works in which case the request should be pretty much 
>>>> ignored since it's an unsupported method
>>>> 
>>>> 
>>>> app = Flask(__name__)
>>>> application = app    # For mod_wsgi
>>>> 
>>>> 
>>>> @app.route('/test', methods=['POST'])
>>>> def test():
>>>> 
>>>>     data = request.get_json(silent=True) or request.form
>>>> 
>>>>     if not data:
>>>>         r = jsonify({
>>>>             'out': '',
>>>>             'err': 'No data provided'
>>>>         })
>>>> 
>>>>         r.status_code = 400
>>>> 
>>>>     else:
>>>>         r = jsonify({
>>>>             'out': data,
>>>>             'err': None
>>>>         })
>>>> 
>>>>         r.status_code = 200
>>>> 
>>>>     return r
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> You received this message because you are subscribed to the Google Groups 
>>>> "modwsgi" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>>> email to modwsgi+u...@ <>googlegroups.com <http://googlegroups.com/>.
>>>> To post to this group, send email to mod...@ <>googlegroups.com 
>>>> <http://googlegroups.com/>.
>>>> Visit this group at https://groups.google.com/group/modwsgi 
>>>> <https://groups.google.com/group/modwsgi>.
>>>> For more options, visit https://groups.google.com/d/optout 
>>>> <https://groups.google.com/d/optout>.
>>> 
>>> 
>>> -- 
>>> You received this message because you are subscribed to the Google Groups 
>>> "modwsgi" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an 
>>> email to [email protected] <>.
>>> To post to this group, send email to [email protected] <>.
>>> Visit this group at https://groups.google.com/group/modwsgi 
>>> <https://groups.google.com/group/modwsgi>.
>>> For more options, visit https://groups.google.com/d/optout 
>>> <https://groups.google.com/d/optout>.
>> 
>> 
>> -- 
>> You received this message because you are subscribed to the Google Groups 
>> "modwsgi" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to [email protected] <>.
>> To post to this group, send email to [email protected] <>.
>> Visit this group at https://groups.google.com/group/modwsgi 
>> <https://groups.google.com/group/modwsgi>.
>> For more options, visit https://groups.google.com/d/optout 
>> <https://groups.google.com/d/optout>.
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "modwsgi" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] 
> <mailto:[email protected]>.
> To post to this group, send email to [email protected] 
> <mailto:[email protected]>.
> Visit this group at https://groups.google.com/group/modwsgi 
> <https://groups.google.com/group/modwsgi>.
> For more options, visit https://groups.google.com/d/optout 
> <https://groups.google.com/d/optout>.

-- 
You received this message because you are subscribed to the Google Groups 
"modwsgi" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/modwsgi.
For more options, visit https://groups.google.com/d/optout.

Reply via email to