[prev in list] [next in list] [prev in thread] [next in thread] 

List:       uwsgi
Subject:    [uWSGI] Early socket close?
From:       roberto () unbit ! it (Roberto De Ioris)
Date:       2012-05-23 18:59:02
Message-ID: 3c2e3a0dc89f6d561439f47fafe876d5.squirrel () manage ! unbit ! it
[Download RAW message or body]


> Happy vacation, Roberto!
> Thanks for the quick fix but isn`t it would be better to make
> uwsgi.disconnect() behave the same way as return or yield ''  i.e. -
> not closing socket untill data send? I understand wsgi sepcification
> but uwsgi.disconnect() is not a part of it and it would be more
> natural to make it behave like return or yield '' imo.
> Additional option --start_response-nodelay seems like redundant in
> this case. I suppose it is very unlikely that someone ever will want
> to start_response() and then uwsgi.disconnect() to not send anything
> in response. (which is default now without --start_response-nodelay.)
>
>

Honestly i do it in a couple of apps where i have a blacklist and i want
to reject peers as soon as possibile without paying for bandwidth :)

By the way, uwsgi.disconnect() can be used in other standard (like Web3 or
Pump) or in other plugins, like the codestring feature of the fastrouter,
so making it so smart to maintain track of start_reponse() status will be
a lot hard.

I am with you, the old non-standard approach looked more "natural" :(
-- 
Roberto De Ioris
http://unbit.it

[prev in list] [next in list] [prev in thread] [next in thread]