mirror of
https://github.com/curl/curl.git
synced 2026-04-11 12:01:42 +08:00
smpt: fix starttls
In cases where the connection was fast, curl sometimes failed to open a
connection. This fixes a regression of c2d973627b.
The regression triggered in these steps:
1. Create an smtp connection
2. Use STARTTLS
3. Receive the response
4. We are inside the loop in `smtp_statemachine`, calling
`smtp_state_starttls_resp`
5. In the good flow, we exit the loop, re-enter `smtp_statemachine` and
run `smtp_perform_upgrade_tls` at the start of the function.
In the bad flow, we stay in the while loop, calling
`Curl_pp_readresp`, which reads part of the TLS handshake and things
go wrong.
The reason is that `Curl_pp_moredata` changed behavior and always
returns `true`, so we stay in the loop in `smtp_statemachine`. With a
slow connection `Curl_pp_readresp` cannot read new data and returns
`CURL_AGAIN`, so we leave the loop and re-enter `smtp_statemachine`.
With a fast connection, `Curl_pp_readresp` reads new data from the tcp
connection, which is part of the TLS handshake.
The fix is in `Curl_pp_moredata`, which needs to take the final line
into account and return `false` if only the final line is stored.
Closes #13048
This commit is contained in:
parent
14bcea074a
commit
a5dd9435ee
@ -432,7 +432,7 @@ CURLcode Curl_pp_disconnect(struct pingpong *pp)
|
||||
|
||||
bool Curl_pp_moredata(struct pingpong *pp)
|
||||
{
|
||||
return (!pp->sendleft && Curl_dyn_len(&pp->recvbuf));
|
||||
return (!pp->sendleft && Curl_dyn_len(&pp->recvbuf) > pp->nfinal);
|
||||
}
|
||||
|
||||
#endif
|
||||
|
||||
Loading…
Reference in New Issue
Block a user