This will let a standard init script (or any script that look for a
pidfile) know that gunicorn is already running and won't attempt to run
it twice.
This would also enable the script to stop gunicorn even in it's startup
phase.
We were accidentally including partial data when we didn't find the
request line terminating '\r\n'. This changes the check to make sure
we're testing the length after we assert there's no termination.
Keepalive=0 means that we aren't waiting for the next connection. So
make sure to send appropriate "close" header and that we handle the first
connection.
1. client.getpeername() can raise "error: [Errno 107] Transport endpoint
is
not connected" if a client has unexpectedly disconnected.
2. I guess we do not need worry about sending error message to client.
We really shouldn't allow the people to override the way we spawn the
new workers on reload. Graceful is about launching new worker and kill
olders after the graceful time.
This change add gtraceful timeout option. This timeout is different than
the worker timeout and can be extended to handled a longer delay before
closing a running connection.
Patch based on the one given by @sirkonst with some edit + support of
the eventlet worker.
patch from Djoume Salvetti . address the following issues in gunicorn:
* Gunicorn does not limit the size of a request header (the
* limit_request_field_size configuration parameter is not used)
* When the configured request limit is lower than its maximum value, the
* maximum value is used instead. For instance if limit_request_line is
* set to 1024, gunicorn will only limit the request line to 4096 chars
* (this issue also affects limit_request_fields)
* Request limits are not limited to their maximum authorized values. For
* instance it is possible to set limit_request_line to 64K (this issue
* also affects limit_request_fields)
* Setting limit_request_fields and limit_request_field_size to 0 does
* not make them unlimited. The following patch allows limit_request_line
* and limit_request_field_size to be unlimited. limit_request_fields can
* no longer be unlimited (I can't imagine 32K fields to not be enough
* but I have a use case where 8K for the request line is not enough).
* Parsing errors (premature client disconnection) are not reported
* When request line limit is exceeded the configured value is reported
* instead of the effective value.
