curl_setup: Disable by default recv-before-send in Windows #10409
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jay
force-pushed
the
disable_recv-before-send
branch
from
2154327
to
a5c1b05
Compare
|
Maybe just disable recv-before-send for the handshakes and use it for the data transfers? |
|
Of the other hand, this workaround was implemented for HTTP servers not following RFC requirements: https://www.rfc-editor.org/rfc/rfc9112#section-9.6-9 |
jay
force-pushed
the
disable_recv-before-send
branch
from
a5c1b05
to
99ce088
Compare
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 7, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 7, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
99ce088
to
668468c
Compare
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 8, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
668468c
to
3a41ab5
Compare
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 8, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
3a41ab5
to
36ce18f
Compare
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 8, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
36ce18f
to
aee6960
Compare
jay
added a commit
to jay/curl
that referenced
this pull request
Feb 8, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
aee6960
to
53b32b0
Compare
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
jay
force-pushed
the
disable_recv-before-send
branch
from
53b32b0
to
c2b2799
Compare
Thanks for your feedback. Yes, unfortunately premature server responses may be lost on Windows if they're followed by RST. |
jay
referenced
this pull request
May 20, 2023
bch
pushed a commit
to bch/curl
that referenced
this pull request
Jul 19, 2023
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer. This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data. Two recent significant bugs this workaround caused: - Broken Schannel TLS 1.3 connections (curl#9431) - HTTP/2 arbitrary hangs (curl#10253) The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this workaround. Ref: curl#657 Ref: curl#668 Ref: curl#720 Ref: curl#9431 Ref: curl#10253 Closes curl#10409
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to this change a workaround for Windows to recv before every send was enabled by default. The way it works is a recv is called before every send and saves the received data, in case send fails because in Windows apparently that can wipe out the socket's internal received data buffer.
This feature has led to several bugs because the way libcurl operates it waits on a socket to read or to write, and may not at all times check for buffered receive data.
Two recent significant bugs this workaround caused:
The actual code remains though it is disabled by default. Though future changes to connection filter buffering could improve the situation IMO it's just not tenable to manage this behavior, though it could possibly be handled more correctly at a higher level (eg transfer handling checks for server error response before it has completed sending its request).
Ref: #9431
Ref: #10253
Closes #xxxx
/cc @Karlson2k