PR that rebase #651. Should also fix#625.
Add the capability to load gunicorn.base.Application without the
loading of the arguments of the command line.
Gunicorn should generally only bother writing its own log and let
the application handle the way it want to log its own errors.
Now the log_file option will be overriden by the gunicorn options
`--error-logfile` and `--access-logfile` if they are given.
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.
It is now possible to specify a file with "config" as an application
configuration key in a paste deploy configuration file. This allows
paster applications to use the full range of gunicorn settings even
when using paste/pserve rather than gunicorn_paster.
Fixes#540.
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
This patch makes sure that we now handle correctly bytes and native
strings on python 3:
- In python 3, sockets are now taking and returning bytes.
- according to PEP3333, headers should be native strings and body in
bytes.
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 '-'
- handle new way to launch applications in django 1.4
- simplify the way we discover the project path and settings
- add --pythonpath & --settings options for django applications
- still compatible with older versions (>=1.1)
-handle DJANGO_SETTINGS_MODULE env.
close#283, #275, #274, #241
