Bump waitress from 1.3.1 to 1.4.0

[dependabot[bot]]

Bumps waitress from 1.3.1 to 1.4.0.

Changelog

*Sourced from [waitress's changelog](https://github.com/Pylons/waitress/blob/master/CHANGES.txt).* > 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 [Pylons/waitress#273](https://github-redirect.dependabot.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/ > > - 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`` > ... (truncated)

Commits

- [`f11093a`](https://github.com/Pylons/waitress/commit/f11093a6b3240fc26830b6111e826128af7771c3) Merge pull request from GHSA-g2xc-35jw-c63p - [`e586be8`](https://github.com/Pylons/waitress/commit/e586be8f43dbb266b9ef28bb285408b3ac3dacd4) Version 1.4.0 - [`d1f283b`](https://github.com/Pylons/waitress/commit/d1f283b277a664ac03fee62b3f0e9fc930f6ee50) Update CHANGES.txt and HISTORY.txt as appropriate - [`60f92b8`](https://github.com/Pylons/waitress/commit/60f92b822538230f279efcfb9561dd2c2524d696) Allow end of chunk parser to be resumeable - [`8ecd8dc`](https://github.com/Pylons/waitress/commit/8ecd8dc4be000a0e1be2212dc35ea6a418a8523e) Improve validation of Transfer-Encoding - [`575994c`](https://github.com/Pylons/waitress/commit/575994cd42e83fd772a5f7ec98b2c56751bd3f65) Upon receiving invalid Content-Length bail - [`804e313`](https://github.com/Pylons/waitress/commit/804e3133a54088fc879c5e791bbe14bb8eb625f9) Disallow BWS in header field-names - [`fb08ecf`](https://github.com/Pylons/waitress/commit/fb08ecf008d314a6c5ba4814efbb41abb0284dbf) Properly enforce max_request_header_size - [`8eba394`](https://github.com/Pylons/waitress/commit/8eba394ad75deaf9e5cd15b78a3d16b12e6b0eba) Remove support for non CRLF line endings - [`7ff1e6b`](https://github.com/Pylons/waitress/commit/7ff1e6b19d3754669d9473104070798f763b56ec) Make sure all errors have a code/reason - Additional commits viewable in [compare view](https://github.com/Pylons/waitress/compare/v1.3.1...v1.4.0)

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR: - `@dependabot rebase` will rebase this PR - `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it - `@dependabot merge` will merge this PR after your CI passes on it - `@dependabot squash and merge` will squash and merge this PR after your CI passes on it - `@dependabot cancel merge` will cancel a previously requested merge and block automerging - `@dependabot reopen` will reopen this PR if it is closed - `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself) - `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself) - `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language - `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language - `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language - `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language You can disable automated security fix PRs for this repo from the [Security Alerts page](https://github.com/AICoE/prometheus-anomaly-detector/network/alerts).

[ghost]

Build succeeded.

• thoth-coala : SUCCESS in 39s

[dependabot[bot]]

Superseded by #93.