diff options
Diffstat (limited to 'HISTORY.txt')
| -rw-r--r-- | HISTORY.txt | 104 |
1 files changed, 104 insertions, 0 deletions
diff --git a/HISTORY.txt b/HISTORY.txt index 2eb829d..c03da8a 100644 --- a/HISTORY.txt +++ b/HISTORY.txt @@ -1,3 +1,107 @@ +2.1.2 +----- + +Bugfix +~~~~~~ + +- When expose_tracebacks is enabled waitress would fail to properly encode + unicode thereby causing another error during error handling. See + https://github.com/Pylons/waitress/pull/378 + +- Header length checking had a calculation that was done incorrectly when the + data was received across multple socket reads. This calculation has been + corrected, and no longer will Waitress send back a 413 Request Entity Too + Large. See https://github.com/Pylons/waitress/pull/376 + +Security Bugfix +~~~~~~~~~~~~~~~ + +- in 2.1.0 a new feature was introduced that allowed the WSGI thread to start + sending data to the socket. However this introduced a race condition whereby + a socket may be closed in the sending thread while the main thread is about + to call select() therey causing the entire application to be taken down. + Waitress will no longer close the socket in the WSGI thread, instead waking + up the main thread to cleanup. See https://github.com/Pylons/waitress/pull/377 + +2.1.1 +----- + +Security Bugfix +~~~~~~~~~~~~~~~ + +- Waitress now validates that chunked encoding extensions are valid, and don't + contain invalid characters that are not allowed. They are still skipped/not + processed, but if they contain invalid data we no longer continue in and + return a 400 Bad Request. This stops potential HTTP desync/HTTP request + smuggling. Thanks to Zhang Zeyu for reporting this issue. See + https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36 + +- Waitress now validates that the chunk length is only valid hex digits when + parsing chunked encoding, and values such as ``0x01`` and ``+01`` are no + longer supported. This stops potential HTTP desync/HTTP request smuggling. + Thanks to Zhang Zeyu for reporting this issue. See + https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36 + +- Waitress now validates that the Content-Length sent by a remote contains only + digits in accordance with RFC7230 and will return a 400 Bad Request when the + Content-Length header contains invalid data, such as ``+10`` which would + previously get parsed as ``10`` and accepted. This stops potential HTTP + desync/HTTP request smuggling Thanks to Zhang Zeyu for reporting this issue. See + https://github.com/Pylons/waitress/security/advisories/GHSA-4f7p-27jc-3c36 + +2.1.0 +----- + +Python Version Support +~~~~~~~~~~~~~~~~~~~~~~ + +- Python 3.6 is no longer supported by Waitress + +- Python 3.10 is fully supported by Waitress + +Bugfix +~~~~~~ + +- ``wsgi.file_wrapper`` now sets the ``seekable``, ``seek``, and ``tell`` + attributes from the underlying file if the underlying file is seekable. This + allows WSGI middleware to implement things like range requests for example + + See https://github.com/Pylons/waitress/issues/359 and + https://github.com/Pylons/waitress/pull/363 + +- In Python 3 ``OSError`` is no longer subscriptable, this caused failures on + Windows attempting to loop to find an socket that would work for use in the + trigger. + + See https://github.com/Pylons/waitress/pull/361 + +- Fixed an issue whereby ``BytesIO`` objects were not properly closed, and + thereby would not get cleaned up until garbage collection would get around to + it. + + This led to potential for random memory spikes/memory issues, see + https://github.com/Pylons/waitress/pull/358 and + https://github.com/Pylons/waitress/issues/357 . + + With thanks to Florian Schulze for testing/vaidating this fix! + +Features +~~~~~~~~ + +- When the WSGI app starts sending data to the output buffer, we now attempt to + send data directly to the socket. This avoids needing to wake up the main + thread to start sending data. Allowing faster transmission of the first byte. + See https://github.com/Pylons/waitress/pull/364 + + With thanks to Michael Merickel for being a great rubber ducky! + +- Add REQUEST_URI to the WSGI environment. + + REQUEST_URI is similar to ``request_uri`` in nginx. It is a string that + contains the request path before separating the query string and + decoding ``%``-escaped characters. + + 2.0.0 (2021-03-07) ------------------ |