This command line argunment allows someone to pass an environement variable to
gunicorn:
$ gunicorn --env FOO=1 test:app
With the command line above the application will be able to use the FOO
environment vatriable.
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
This changes introduced an issue with websockets support (#432) and is
probably related to #428 & #416 . It is safer for now to revert it.
This reverts commit aa22115cfc9c2b76c818ce231089b01c690052b6.
Conflicts:
gunicorn/workers/async.py
gunicorn/workers/sync.py
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.
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.
When the signal.siginterrupt call is available it can be used to make
interrupted system calls (errno == EINTR) retry transparently whenever
they have not caused any side effects yet (e.g. no data read/written).
It should make shutdown more graceful.
Patch by Jonas Borgström
the possibility to manage an access log compatible with apache combined
log format. reopening files is also handled. Also, this change fix
issues #237 and #190.
For the sake of simplicity logging file have been removed
--logfile option has become --error-logfile, by default "-"
Following options have been added:
--access-logfile, the access log file path. By default None. If set
access logs will bre written to defined output
eg:
$ gunicorn -w3 --access-logfile=- test:app
2011-08-21 19:36:52 [84572] [INFO] Starting gunicorn 0.13.0
2011-08-21 19:36:52 [84572] [INFO] Listening at: http://127.0.0.1:8000
(84572)
2011-08-21 19:36:52 [84572] [INFO] Using worker: sync
2011-08-21 19:36:52 [84573] [INFO] Booting worker with pid: 84573
2011-08-21 19:36:52 [84574] [INFO] Booting worker with pid: 84574
2011-08-21 19:36:52 [84575] [INFO] Booting worker with pid: 84575
127.0.0.1 - - [21/Aug/2011:19:37:04] "GET / HTTP/1.1" 200 14 "-"
"curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r
zlib/1.2.5"
* Always log the exception locally
* Still only pass the exception in the HTTP response if
debug is turned on.
* Slight cosmetic changes to the actual HTML of the error
response.
Works on sync and eventlet works. Doesn't work on gevent_pywsig or
gevent_wsgi workers as we don't control their main loops. Tornado
workers appear to be broken.
Worst of all, this causes vanilla gevent workers to segfault. I'm
waiting to see if there's a known issue before considering what to
do next. Worst case we could refuse to run with the bad combination
of settings.
Web applications use random numbers for things like sessions, if
we don't reseed then each worker will generate the same sequence
of random numbers which can lead to security concerns.
Thanks to Jonas Borgström for the patch.
I noticed with preload that if a worker fails to boot the arbiter will
dutifully respawn it. Only to watch it die again. This patch makes it so
if a worker process exits before making it to the run loop the process
will exit with a special exit code. When the arbiter sees this flag it
will shutdown all processes assuming there is an unrecoverable error.
may be better to use Event object. While i'm here move the monkey
patching in its own function used on config so we make sure to patch
only one time and prevent some ugly hack like reinit gevent each time we
spawn (it's better to use patched os.fork from gevent once time).
