1.2.1:
Bugfixes
- When given an IPv6 address in X-Forwarded-For or Forwarded for=
waitress was placing the IP address in REMOTE_ADDR with brackets:
[2001:db8::0], this does not match the requirements in the CGI spec which
REMOTE_ADDR was lifted from. Waitress will now place the bare IPv6
address in REMOTE_ADDR: 2001:db8::0.
1.2.0:
No changes since the last beta release. Enjoy Waitress!
1.2.0b3:
Bugfixes
- Modified clear_untrusted_proxy_headers to be usable without a
trusted_proxy.
- Modified trusted_proxy_count to error when used without a
trusted_proxy.
1.2.0b2:
Bugfixes
- Fixed logic to no longer warn on writes where the output is required to have
a body but there may not be any data to be written. Solves issue posted on
the Pylons Project mailing list with 1.2.0b1.
1.2.0b1:
Happy New Year!
Features
- Setting the trusted_proxy setting to '*' (wildcard) will allow all
upstreams to be considered trusted proxies, thereby allowing services behind
Cloudflare/ELBs to function correctly whereby there may not be a singular IP
address that requests are received from.
Using this setting is potentially dangerous if your server is also available
from anywhere on the internet, and further protections should be used to lock
down access to Waitress.
- Waitress has increased its support of the X-Forwarded-* headers and includes
Forwarded (RFC7239) support. This may be used to allow proxy servers to
influence the WSGI environment.
This also provides a new security feature when using Waitress behind a proxy
in that it is possible to remove untrusted proxy headers thereby making sure
that downstream WSGI applications don't accidentally use those proxy headers
to make security decisions.
The documentation has more information, see the following new arguments:
- trusted_proxy_count
- trusted_proxy_headers
- clear_untrusted_proxy_headers
- log_untrusted_proxy_headers (useful for debugging)
Be aware that the defaults for these are currently backwards compatible with
older versions of Waitress, this will change in a future release of waitress.
If you expect to need this behaviour please explicitly set these variables in
your configuration, or pin this version of waitress.
Documentation:
https://docs.pylonsproject.org/projects/waitress/en/latest/reverse-proxy.html
- Waitress can now accept a list of sockets that are already pre-bound rather
than creating its own to allow for socket activation. Support for init
systems/other systems that create said activated sockets is not included.
- Server header can be omitted by specifying ident=None or ident=''.
Bugfixes
- Waitress will no longer send Transfer-Encoding or Content-Length for 1xx,
204, or 304 responses, and will completely ignore any message body sent by
the WSGI application, making sure to follow the HTTP standard.
Compatibility
- Waitress has now "vendored" asyncore into itself as waitress.wasyncore.
This is to cope with the eventuality that asyncore will be removed from
the Python standard library in 3.8 or so.
Documentation
- Bring in documentation of paste.translogger from Pyramid. Reorganize and
clean up documentation.
1.1.0:
Features
* Waitress now has a __main__ and thus may be called with python -mwaitress
Bugfixes
* Waitress no longer allows lowercase HTTP verbs. This change was made to fall in line with most HTTP servers.
* When receiving non-ascii bytes in the request URL, waitress will no longer abruptly close the connection, instead returning a 400 Bad Request.
Features
- Python 3.6 is now officially supported in Waitress
Bugfixes
- Add a work-around for libc issue on Linux not following the documented
standards. If getnameinfo() fails because of DNS not being available it
should return the IP address instead of the reverse DNS entry, however
instead getnameinfo() raises. We catch this, and ask getnameinfo()
for the same information again, explicitly asking for IP address instead of
reverse DNS hostname.
Waitress is meant to be a production-quality pure-Python WSGI server
with very acceptable performance. It has no dependencies except
ones which live in the Python standard library. It supports HTTP/1.0
and HTTP/1.1.
