Release notes
*Sourced from [waitress's releases](https://github.com/Pylons/waitress/releases).*
> ## v1.4.0
> No release notes provided.
>
> ## v1.3.1
> No release notes provided.
>
> ## v1.3.0
> No release notes provided.
>
> ## v1.3.0b0
> No release notes provided.
>
> ## v1.2.1
> No release notes provided.
>
> ## v1.2.0
> No release notes provided.
>
> ## v1.1.0
> https://pypi.org/project/waitress/1.1.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.0.2...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/scipy-conference/procbuild/network/alerts).
dependabot[bot]
commented
4 years ago
Bumps waitress from 1.0.2 to 1.4.0.
Release notes
*Sourced from [waitress's releases](https://github.com/Pylons/waitress/releases).* > ## v1.4.0 > No release notes provided. > > ## v1.3.1 > No release notes provided. > > ## v1.3.0 > No release notes provided. > > ## v1.3.0b0 > No release notes provided. > > ## v1.2.1 > No release notes provided. > > ## v1.2.0 > No release notes provided. > > ## v1.1.0 > https://pypi.org/project/waitress/1.1.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.0.2...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/scipy-conference/procbuild/network/alerts).