| 2.0.0 (unreleased) |
| ------------------ |
| - Allow tasks to notice if the client disconnected. |
| |
| This inserts a callable `waitress.client_disconnected` into the environment |
| that allows the task to check if the client disconnected while waiting for |
| the response at strategic points in the execution and to cancel the |
| operation. |
| |
| It requires setting the new adjustment `channel_request_lookahead` to a value |
| larger than 0, which continues to read requests from a channel even if a |
| request is already being processed on that channel, up to the given count, |
| since a client disconnect is detected by reading from a readable socket and |
| receiving an empty result. |
| |
| See https://github.com/Pylons/waitress/pull/310 |
| |
| - Drop Python 2.7 support |
| |
| 1.4.4 (2020-06-01) |
| ------------------ |
| |
| - Fix an issue with keep-alive connections in which memory usage was higher |
| than expected because output buffers were being reused across requests on |
| a long-lived connection and each buffer would not be freed until it was full |
| or the connection was closed. Buffers are now rotated per-request to |
| stabilize their behavior. |
| |
| See https://github.com/Pylons/waitress/pull/300 |
| |
| - Waitress threads have been updated to contain their thread number. This will |
| allow loggers that use that information to print the thread that the log is |
| coming from. |
| |
| See https://github.com/Pylons/waitress/pull/302 |
| |
| 1.4.3 (2020-02-02) |
| ------------------ |
| |
| Security Fixes |
| ~~~~~~~~~~~~~~ |
| |
| - In Waitress version 1.4.2 a new regular expression was added to validate the |
| headers that Waitress receives to make sure that it matches RFC7230. |
| Unfortunately the regular expression was written in a way that with invalid |
| input it leads to catastrophic backtracking which allows for a Denial of |
| Service and CPU usage going to a 100%. |
| |
| This was reported by Fil Zembowicz to the Pylons Project. Please see |
| https://github.com/Pylons/waitress/security/advisories/GHSA-73m2-3pwg-5fgc |
| for more information. |
| |
| 1.4.2 (2020-01-02) |
| ------------------ |
| |
| Security Fixes |
| ~~~~~~~~~~~~~~ |
| |
| - This is a follow-up to the fix introduced in 1.4.1 to tighten up the way |
| Waitress strips whitespace from header values. This makes sure Waitress won't |
| accidentally treat non-printable characters as whitespace and lead to a |
| potental HTTP request smuggling/splitting security issue. |
| |
| Thanks to ZeddYu Lu for the extra test cases. |
| |
| Please see the security advisory for more information: |
| https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 |
| |
| CVE-ID: CVE-2019-16789 |
| |
| Bugfixes |
| ~~~~~~~~ |
| |
| - Updated the regex used to validate header-field content to match the errata |
| that was published for RFC7230. |
| |
| See: https://www.rfc-editor.org/errata_search.php?rfc=7230&eid=4189 |
| |
| |
| 1.4.1 (2019-12-24) |
| ------------------ |
| |
| Security Fixes |
| ~~~~~~~~~~~~~~ |
| |
| - Waitress did not properly validate that the HTTP headers it received were |
| properly formed, thereby potentially allowing a front-end server to treat a |
| request different from Waitress. This could lead to HTTP request |
| smuggling/splitting. |
| |
| Please see the security advisory for more information: |
| https://github.com/Pylons/waitress/security/advisories/GHSA-m5ff-3wj3-8ph4 |
| |
| CVE-ID: CVE-2019-16789 |
| |
| 1.4.0 (2019-12-20) |
| ------------------ |
| |
| Bugfixes |
| ~~~~~~~~ |
| |
| - Waitress used to slam the door shut on HTTP pipelined requests without |
| setting the ``Connection: close`` header as appropriate in the response. This |
| is of course not very friendly. Waitress now explicitly sets the header when |
| responding with an internally generated error such as 400 Bad Request or 500 |
| Internal Server Error to notify the remote client that it will be closing the |
| connection after the response is sent. |
| |
| - Waitress no longer allows any spaces to exist between the header field-name |
| and the colon. While waitress did not strip the space and thereby was not |
| vulnerable to any potential header field-name confusion, it should have sent |
| back a 400 Bad Request. See https://github.com/Pylons/waitress/issues/273 |
| |
| Security Fixes |
| ~~~~~~~~~~~~~~ |
| |
| - Waitress implemented a "MAY" part of the RFC7230 |
| (https://tools.ietf.org/html/rfc7230#section-3.5) which states: |
| |
| Although the line terminator for the start-line and header fields is |
| the sequence CRLF, a recipient MAY recognize a single LF as a line |
| terminator and ignore any preceding CR. |
| |
| Unfortunately if a front-end server does not parse header fields with an LF |
| the same way as it does those with a CRLF it can lead to the front-end and |
| the back-end server parsing the same HTTP message in two different ways. This |
| can lead to a potential for HTTP request smuggling/splitting whereby Waitress |
| may see two requests while the front-end server only sees a single HTTP |
| message. |
| |
| For more information I can highly recommend the blog post by ZeddYu Lu |
| https://blog.zeddyu.info/2019/12/08/HTTP-Smuggling-en/ |
| |
| Please see the security advisory for more information: |
| https://github.com/Pylons/waitress/security/advisories/GHSA-pg36-wpm5-g57p |
| |
| CVE-ID: CVE-2019-16785 |
| |
| - Waitress used to treat LF the same as CRLF in ``Transfer-Encoding: chunked`` |
| requests, while the maintainer doesn't believe this could lead to a security |
| issue, this is no longer supported and all chunks are now validated to be |
| properly framed with CRLF as required by RFC7230. |
| |
| - Waitress now validates that the ``Transfer-Encoding`` header contains only |
| transfer codes that it is able to decode. At the moment that includes the |
| only valid header value being ``chunked``. |
| |
| That means that if the following header is sent: |
| |
| ``Transfer-Encoding: gzip, chunked`` |
| |
| Waitress will send back a 501 Not Implemented with an error message stating |
| as such, as while Waitress supports ``chunked`` encoding it does not support |
| ``gzip`` and it is unable to pass that to the underlying WSGI environment |
| correctly. |
| |
| Waitress DOES NOT implement support for ``Transfer-Encoding: identity`` |
| eventhough ``identity`` was valid in RFC2616, it was removed in RFC7230. |
| Please update your clients to remove the ``Transfer-Encoding`` header if the |
| only transfer coding is ``identity`` or update your client to use |
| ``Transfer-Encoding: chunked`` instead of ``Transfer-Encoding: identity, |
| chunked``. |
| |
| Please see the security advisory for more information: |
| https://github.com/Pylons/waitress/security/advisories/GHSA-g2xc-35jw-c63p |
| |
| CVE-ID: CVE-2019-16786 |
| |
| - While validating the ``Transfer-Encoding`` header, Waitress now properly |
| handles line-folded ``Transfer-Encoding`` headers or those that contain |
| multiple comma seperated values. This closes a potential issue where a |
| front-end server may treat the request as being a chunked request (and thus |
| ignoring the Content-Length) and Waitress using the Content-Length as it was |
| looking for the single value ``chunked`` and did not support comma seperated |
| values. |
| |
| - Waitress used to explicitly set the Content-Length header to 0 if it was |
| unable to parse it as an integer (for example if the Content-Length header |
| was sent twice (and thus folded together), or was invalid) thereby allowing |
| for a potential request to be split and treated as two requests by HTTP |
| pipelining support in Waitress. If Waitress is now unable to parse the |
| Content-Length header, a 400 Bad Request is sent back to the client. |
| |
| Please see the security advisory for more information: |
| https://github.com/Pylons/waitress/security/advisories/GHSA-4ppp-gpcr-7qf6 |