Move setting of env vars from Arbiter.start to Arbiter.setup so that they are available during application start up when 'preload_app' is used.
Closes#735
"Limits the number of worker processes to 1" hasn't been true since
06a4dc6 (fix one error in gunicorn_paster, global conf was ignored,
2010-06-22), although it was true when the line was added in 3c7d532
(Large refactor of the documentation and website, 2010-05-22).
"changes some error handling that's sent to clients" hasn't been true
since feb86d3 (don't display the traceback in the HTTP response,
2013-09-27).
The only remaining actions that --debug had were disabling --preload
and hiding debug-level config logging. The former seems useless (just
disable --preload directly) and the latter at doesn't seem useful
enough for a new setting (just turn down --log-level). With this
commit, --preload always works and you always get debug-level config
logging.
I left a stub Debug entry in gunicorn.config, which we can leave in
place while folks convert any gunicorn scripts and configurations to
drop --debug. When the time comes, we can just remove that entry. I
also the boolean-config tests to use --preload, since that will still
be around after we remove the dummy Debug entry.
Fixes#700.
``send_special_chunks`` sends the request data in two chunks, one having a length of 1 byte, which ensures there is no CRLF, and a second chunk containing the rest of the request data. Practically, this forces ``gunicorn.http.message.Request.read_line()`` to get the full request data with two buffer reads and reveal possible bugs related to the internal buffer mechanism. See #670 for more information.
Instead of faking STDIN/STDERR to a fake object that we close on reopen,
simply redirect them to a file and reopen this one when need.
Should fix most of the issues on #309
Allows gunicorn to listen on different interface. It can be either ipv6,
unix or ipv4 sockets.
Ex:
gunicorn -w3 -b 127.0.0.1:8001 -b 127.0.0.1:8000 -b [::1]:8000 test:app
fix#444
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.
Add --limit-request-fields (limit_request_fields) and
--limit-request-field-size (limit-request-field-size) options.
- limit_request_fields:
Value is a number from 0 (unlimited) to 32768. This parameter is
used to limit the number of headers in a request to prevent DDOS
attack. Used with the `limit_request_field_size` it allows more
safety.
- limit_request_field_size:
Value is a number from 0 (unlimited) to 8190. to set the limit
on the allowed size of an HTTP request header field.
You can now pass the parameter --limit-request-line or set the
limit_request_line in your configuration file to set the max size of the
request line in bytes.
This parameter is used to limit the allowed size of a client's HTTP
request-line. Since the request-line consists of the HTTP method, URI,
and protocol version, this directive places a restriction on the length
of a request-URI allowed for a request on the server. A server needs
this value to be large enough to hold any of its resource names,
including any information that might be passed in the query part of a
GET request. By default this value is 4094 and can't be larger than
8190.
This parameter can be used to prevent any DDOS attack.
