curl / Mailing Lists / curl-users / Single Mail
Buy commercial curl support from WolfSSL. We help you work out your issues, debug your libcurl applications, use the API, port to new platforms, add new features and more. With a team lead by the curl founder himself.

How does early error response detection work?

From: Osipov, Michael via curl-users <>
Date: Sat, 23 May 2020 17:27:51 +0200

Hi folks,

I am currently trying to understand how curl via libcurl detects an
early error respone (401) on a POST request with a large request body:

> truss -o out -dH curl -X POST --upload-file -H "Content-Type: application/zip" https://<hostname>:11111/content-dev/api/documents -H "Expect:" --http1.1

Expect continue has been intentionally disabled to reproduce the
bahavior with py-requests [1]

I am running

> $ curl -V
> curl 7.70.0 (amd64-portbld-freebsd12.1) libcurl/7.70.0 OpenSSL/1.1.1g zlib/1.2.11 nghttp2/1.40.0
> Release-Date: 2020-04-29
> Protocols: file http https smtp smtps
> Features: AsynchDNS GSS-API HTTP2 HTTPS-proxy Kerberos Largefile libz SPNEGO SSL UnixSockets

with Tomcat via 8.5.53 APR/OpenSSL on the same host.

I read the source code (rewind and auth) and ran curl through truss. As
far as I understand curl works with non-blocking I/O. It sends the
headers, reads from socket and then sends the first block of data (64
KiB), waits with a poll for the socket, send the next chuck, receives a
EAGAIN (ERR#35 on BSD), polls again and tries to read from the socket
and notices that an error response has been transmitted, all FDs are
closed and the application terminated.

Hopefully this is properly understood from my side.

Since all runs in the same thread, I did not fully understand the
synchronization between read() and write(). Does the EAGAIN on write()
cause the read() on the socket or rather after a write() happens a
read(), sets some flags and the write() picks them up and notices that
any further write()s won't be fruitful?



Received on 2020-05-23