Replies: 2 comments
|
I am about to capture traffic on the wire, as what I can't tell from the app side logging is if these bytes are even leaving the device or getting ACKed. [later] There is no problem on the wire. This is not a delivery problem, a TCP window stall, or silent client retries. What we see mirrors this app log:
|
0 replies
|
Also tried various permutations of disabling EXPECT, using chunked transfer, etc. Fundamentally hit the same wall. |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Unclear if this is a defect in libcurl, or a platform issue. This is on a 32-bit embedded platform with NetBSD 6 network semantics, talking to a Java server.
The problem is that our multipart transfer routines never transfer more than a single buffersize even when it looks like curl knows there is more to read. Reducing the buffersize to 16K did not change the behaviour. If the data to transfer is under this buffersize, it transfers fine.
That is, only if curl has to read the next buffer or remaining does it seem to stall, until the server times out the connection (that's the 400 we see below). To be clear: that 400 result is always 30s after the first buffer is read and, apparently, sent. We can see some SSL/TLS/BIO back and forth which I presume is TLS stuff. But curl never sends another chunk.
curl_mime*I switched to
mime_data_cband friends to rule out a problem with POST/READFUNCTION internals, and that is what was used to test out the edges (the callback is pretty reasonable: return 0 on all bytes read with 0 bytes remaining, buffersize or remaining on more than 0 bytes remaining).The interesting part to me is the lack of any reads after the "AAAA" dummy data is sent and the " DATE:2026.08.12 TIME:16:54:23" line inserted by the platform logger. I think that the
eos=0is curl knowing it has more data, and the data counts all seem to add up. I cannot explain why curl can read and send the first chunk, and can write in the TLS stuff and eventual failure, but seems to be stuck or waiting to read and send the next buffer.This feels like the curl scheduler knows it has data to read and send, but it never sends it.
Example libcurl log using mime_data_cb and friends (though, again, we get the same behaviour using a read callback):
The diagnostic code used to generate this output (once again, I noticed the same behaviour with a read callback implementation):
The rather wordy configuration tuned for the target platform to remove most of what we don't need. We need (mostly) only HTTP/HTTPS:
All reactions