Debian Patches

Status for waitress/2.1.2-2+deb12u1

Patch Description Author Forwarded Bugs Origin Last update
docs-Don-t-try-to-detect-the-version-don-t-use-Pylons-the.patch docs: Don't try to detect the version, don't use Pylons theme Andrew Shadura <andrewsh@debian.org> not-needed 2022-05-09
docs-Use-internal-ressources-for-intersphinx.patch docs: Use internal ressources for intersphinx Carsten Schoenert <c.schoenert@t-online.de> not-needed 2022-11-12
0001-Fix-a-race-condition-on-recv_bytes-boundary-when-req.patch Fix a race condition on recv_bytes boundary when request is invalid
A remote client may send a request that is exactly recv_bytes long,
followed by a secondary request using HTTP pipelining.

When request lookahead is disabled (default) we won't read any more
requests, and when the first request fails due to a parsing error, we
simply close the connection.

However when request lookahead is enabled, it is possible to process and
receive the first request, start sending the error message back to the
client while we read the next request and queue it. This will allow the
secondar request to be serviced by the worker thread while the
connection should be closed.

The fix here checks if we should not have read the data in the first
place (because the conection is going to be torn down) while we hold the
`requests_lock` which means the service thread can't be in the middle of
flipping the `close_when_flushed` flag.		 Delta Regeer <bertjw@regeer.org> no 2024-10-26
0002-Make-DummySock-look-more-like-an-actual-socket.patch Make DummySock() look more like an actual socket
This forces DummySock() to look like a properly connected socket where
there is a buffer that is read from by the remote, and a buffer that is
written to by the remote.

The local side does the opposite, this way data written by the local
side can be read by the remote without operating on the same buffer.		 Delta Regeer <bertjw@regeer.org> no 2024-10-26
0003-Add-a-new-test-to-validate-the-lookahead-race-condit.patch Add a new test to validate the lookahead race condition Delta Regeer <bertjw@regeer.org> no 2024-10-26
0004-Remove-test-for-getpeername.patch Remove test for getpeername() Delta Regeer <bertjw@regeer.org> no 2024-03-03
0005-When-closing-the-socket-set-it-to-None.patch When closing the socket, set it to None
This avoids calling close() twice on the same socket if self.close() or
self.handle_close() is called multiple times		 Delta Regeer <bertjw@regeer.org> no 2024-03-03
0006-Don-t-exit-handle_write-early-even-if-socket-is-not-.patch Don't exit handle_write early -- even if socket is not connected
Calling handle_close() multiple times does not hurt anything, and is
safe.		 Delta Regeer <bertjw@regeer.org> no 2024-03-03
0007-Assume-socket-is-not-connected-when-passed-to-wasync.patch Assume socket is not connected when passed to wasyncore.dispatcher
No longer call getpeername() on the remote socket either, as it is not
necessary for any of the places where waitress requires that self.addr
in a subclass of the dispatcher needs it.

This removes a race condition when setting up a HTTPChannel where we
accepted the socket, and know the remote address, yet call getpeername()
again which would have the unintended side effect of potentially setting
self.connected to False because the remote has already shut down part of
the socket.

This issue was uncovered in #418, where the server would go into a hard
loop because self.connected was used in various parts of the code base.		 Delta Regeer <bertjw@regeer.org> no 2024-03-03
0008-HTTPChannel-is-always-created-from-accept-explicitly.patch HTTPChannel is always created from accept, explicitly set self.connected to True Delta Regeer <bertjw@regeer.org> no 2024-03-03

All known versions for source package 'waitress'

Links