Also simplifies the environment handling in the gevent_pywsgi
server so that it also has this key. An added side effect is
that the gunicorn FileWrapper gets set for the gevent_pywsgi
worker, too.
Fixes#486
Raise a StopIteration rather than returning so that the keep-alive
loop is terminated. If gunicorn has closed the socket there is no
sense in trying to read another request and it may cause spurious
EBADF errors to try.
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
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.
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.
Intoduce a change in log access format:
- request headers are now added to the log format using the
{HeaderName}i variable
- response headers are now handled using the {HeaderName}o variables
- headers name are insensitive
- non existent keys in the log access format are replaced by '-'
- make log access format customizable in settings:
- fix logger
To setup a log format use the --access-logformat option.
By default:
%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
h: remote address
t: date of the request
r: status line (ex: GET / HTTP/1.1)
s: status
b: response length or '-'
f: referer
a: user agent
T: request time in seconds
D: request time in microseconds
You can also pass any WSGI request header as a parameter.
(ex '%(HTTP_HOST)s').
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"
StopIteration is simply propogated, so there's no reason to catch it.
The catch-all exception is also caught and logged in handle(), but
broken pipe errors are ignored. The redundant catch here was generating
excess logging by calling handle_error for a broken pipe which fails to
send the error because the client has already disconnected.
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.
