curl
curl POP3 STAT shows 2 minute delay
I did this
curl --request STAT --ssl-reqd -v --insecure -u user:password pop3s://pop.gmx.net
I expected the following
I expect curl to finish immediately, but see a 2 minute delay instead.
This follows up on https://github.com/curl/curl/issues/14201#issuecomment-2296896857, but the actual cause might be unrelated.
Here is the Windows error log.
curl/libcurl version
Windows:
curl 8.9.1 (x86_64-w64-mingw32) libcurl/8.9.1 LibreSSL/3.9.2 zlib/1.3.1 brotli/1.1.0 zstd/1.5.6 WinIDN libpsl/0.21.5 libssh2/1.11.0 nghttp2/1.62.1 ngtcp2/1.6.0 nghttp3/1.4.0 Release-Date: 2024-07-31 Protocols: dict file ftp ftps gopher gophers http https imap imaps ipfs ipns ldap ldaps mqtt pop3 pop3s rtsp scp sftp smb smbs smtp smtps telnet tftp ws wss Features: alt-svc AsynchDNS brotli HSTS HTTP2 HTTP3 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM PSL SPNEGO SSL SSPI threadsafe UnixSockets zstd
Debian Bookworm:
curl 7.88.1 (x86_64-pc-linux-gnu) libcurl/7.88.1 OpenSSL/3.0.13 zlib/1.2.13 brotli/1.0.9 zstd/1.5.4 libidn2/2.3.3 libpsl/0.21.2 (+libidn2/2.3.3) libssh2/1.10.0 nghttp2/1.52.0 librtmp/2.3 OpenLDAP/2.5.13 Release-Date: 2023-02-20, security patched: 7.88.1-10+deb12u6 Protocols: dict file ftp ftps gopher gophers http https imap imaps ldap ldaps mqtt pop3 pop3s rtmp rtsp scp sftp smb smbs smtp smtps telnet tftp Features: alt-svc AsynchDNS brotli GSS-API HSTS HTTP2 HTTPS-proxy IDN IPv6 Kerberos Largefile libz NTLM NTLM_WB PSL SPNEGO SSL threadsafe TLS-SRP UnixSockets zstd
operating system
Windows 11, Debian Bookworm.
No.
On Windows, the oldest version I tested is curl 8.4.0, and the delay is present there as well as all later versions.
On Debian Bookworm I just tested curl 7.88.1, which also has the delay.
I did not test other versions.
Looking at the POP3 log, curl just seems to wait for the server to send more lines, whereas 'STAT' only sends a single line back. The 2 minute delay is a timeout at the server that then sends curl a TLS close notify.
RFC 1939 differentiates between multi-line commands, ending with \n.\n and commands that give only a single line. @bagder: I cannot see how pop3.c handles these.
Just a note on this based on the explanation above: --request was always an option that replaces a command string with another string, without otherwise changing how it behaves.
Thus: --request STAT for POP3 is not a curl bug. It is actually just "wrong use" of curl.
But of course: we might still want to consider supporting this use case so that users actually can send STAT this way.
Thus: --request STAT for POP3 is not a curl bug. It is actually just "wrong use" of curl.
Could you suggest a "correct" use of curl to obtain the result of POP3 STAT?
Could you suggest a "correct" use of curl to obtain the result of POP3 STAT?
I don't believe curl has one.