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.
RFC 2616 says that only headers that are allowed to have comma separated
values are acceptable for repetition. Though it doesn't specify an error
condition for that situation. I reckon the cleanest way would be to list
the headers that are acceptable for repetition, and return a 400 Bad
Request.
