How does early error response detection work?
Date: Sat, 23 May 2020 17:27:51 +0200
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 inputs.zip -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 
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