If you redirect the output somewhere and get the progress meter displayed, can you see how far it gets before it stops? Have you figured out a specific size limit when the problem appears? Do you know if this happens to all/most HTTP/2 servers or just this/a few?

1. unfortunately --progress-bar does not show how far curl consumes input file.
2. something around 65535 bytes (+- 100 for form prolog epilog). (i guess it's the key for understanding a bug)
3. almost any http/2 public server (google.com, yandex.ru)

particularly this time out happens https://github.com/curl/curl/blob/curl-7_69_1/lib/vtls/schannel.c#L1561

It seems winsock select() for write on non-block socket can return 0 and WSAGetLastError() == 0 ( just checked wsageetlasterror result then select returns 0). So i have made following changes and schannel starts to post large pieces properly:

      what = SOCKET_WRITABLE(conn->sock[sockindex], timeleft);
      if(what < 0) {
        /* fatal error */
        failf(conn->data, "select/poll on SSL socket, errno: %d", SOCKERRNO);
        *err = CURLE_SEND_ERROR;
        written = -1;
        break;
      }
      /* Non-Block socket may return 0 for select() write check
      else if(0 == what) {
        failf(conn->data, "schannel: timed out sending data "
              "(bytes sent: %zd)", written);
        *err = CURLE_OPERATION_TIMEDOUT;
        written = -1;
        break;
      }
    */
      /* socket is writable */

      result = Curl_write_plain(conn, conn->sock[sockindex], data + written,
                                len - written, &this_write);
      if(result == CURLE_AGAIN)
        continue;
      else if(result != CURLE_OK) {
        *err = result;
        written = -1;
        break;
      }

BTW gopther send buffer implementation also check only fatal error on select() for write: https://github.com/curl/curl/blob/curl-7_69_1/lib/gopher.c#L151

@bagder If you think it's appropriate change then i may create pull request.

This should be correctly handled in our wrapper functions Curl_socket_check/Curl_select to make sure that our select calls stay cross-platform compatible (even though schannel of course is only available on Windows). I would like to take a look at this tomorrow.

If the socket is not processing a connect call, writability means a send, sendto, or WSASendto are guaranteed to succeed. However, they can block on a blocking socket if the len parameter exceeds the amount of outgoing system buffer space available. It is not specified how long these guarantees can be assumed to be valid, particularly in a multithreaded environment

Source: https://docs.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-select#remarks

I find it highly unlikely that this is a select() issue. We use select with all TLS backends and all protocols so we would get this problem widely and frequently if it was. curl is used on Windows by many users very often after all.

I rather suspect that this is a Schannel specific problem. Like perhaps it doesn't drain the TLS buffers correctly.

This is what I was thinking too. But if it is a schannel specific problem, then it should happen regardless of HTTP/2.

Some trace info:
curl -v --http1.1 -X POST -H "Expect:" -F "image=@large6MB.bin" "https://nghttp2.org/"

swrite 191
swrite 93
schannel_send 187
swrite 216
schannel_send 65536
swrite 16413
schannel_send 49152
swrite 16413
schannel_send 32768
swrite 16413
swrite 31

curl -v --http2.0 -X POST -H "Expect:" -F "image=@large6MB.bin" "https://nghttp2.org/"

swrite 194
swrite 93
schannel_send 24
swrite 53
schannel_send 27
swrite 56
schannel_send 13
swrite 42
schannel_send 99
swrite 128
schannel_send 16393
swrite 16413
schannel_send 9
swrite 38
schannel_send 16393
swrite 16413
schannel_send 9
swrite 38
schannel_send 16393
swrite 16413
schannel_send 9
swrite 38
schannel_send 16392
swrite 16413
schannel_send 8
swrite 37 <<< select() for write returns 0 before this call
schannel_send 9
swrite 38

So as i mentioned earlier SOCKET_WRITABLE (while doing buffer send routing) was checked for zero only at schannel (gopher does only below zero check). And all Curl_socket_check(writefd) at connection routines treat 0 for nonblock as unfinished connection(non fatal state). May be select(writefd)==0 for nonblock sockets is a valid state?

But if it is a schannel specific problem, then it should happen regardless of HTTP/2.

Perhaps, but HTTP/2 creates a pretty unique pattern of use with incoming/outgoing packages that is quite different than HTTP/1, so we've seen several issues in the past only trigger with HTTP/2.

Quick question: @ajax16384 why are you talking about non-blocking sockets here? My understanding is that curl is using blocking socket operations with select. cc @bagder, right?

@mback2k singleipconnect marks socket with curlx_nonblock as nonblock ( https://github.com/curl/curl/blob/curl-7_69_1/lib/connect.c#L1205 ). That's why swrite-send can fail with WSAEWOULDBLOCK and return CURLE_AGAIN wrom Curl_write_*, so caller may wait and retry operation.

Sorry, I am unable to dive deeper into this quickly at the moment, because I have never build curl with HTTP/2 support. Maybe @jay or @MarcelRaad can take a look at this and reproduce the issue?

curl is using non-blocking sockets to never risk a blocking network call

We don't have decryption for schannel so we can't see the HTTP/2 in wireshark. Schannel decryption involves getting the master key from somewhere in the OS memory. I've read it's possible but it looks time consuming.

I don't have a debugging setup in Windows 10 to reproduce what was reported, maybe Marcel does. My guess is it's actually timing out. The reporter could print the timeout value passed to select before the call and GetTickCount() before and after to see if it's actually timing out.

@jay you do not need to involve decryption analysis cause bug happens at encryption state:

>	libcurl.dll!schannel_send(connectdata * conn, int sockindex, const void * buf, unsigned __int64 len, CURLcode * err) Line 1564	C
 	libcurl.dll!send_callback(nghttp2_session * h2, const unsigned char * data, unsigned __int64 length, int flags, void * userp) Line 360	C
 	libcurl.dll!nghttp2_session_send(nghttp2_session * session) Line 3250	C
 	libcurl.dll!h2_session_send(Curl_easy * data, nghttp2_session * h2) Line 1507	C
 	libcurl.dll!http2_send(connectdata * conn, int sockindex, const void * mem, unsigned __int64 len, CURLcode * err) Line 1858	C
 	libcurl.dll!Curl_write(connectdata * conn, unsigned __int64 sockfd, const void * mem, unsigned __int64 len, __int64 * written) Line 349	C
 	libcurl.dll!readwrite_upload(Curl_easy * data, connectdata * conn, int * didwhat) Line 1129	C
 	libcurl.dll!Curl_readwrite(connectdata * conn, Curl_easy * data, bool * done, bool * comeback) Line 1247	C
 	libcurl.dll!multi_runsingle(Curl_multi * multi, curltime now, Curl_easy * data) Line 2091	C
 	libcurl.dll!curl_multi_perform(Curl_multi * multi, int * running_handles) Line 2359	C
 	libcurl.dll!easy_transfer(Curl_multi * multi) Line 602	C
 	libcurl.dll!easy_perform(Curl_easy * data, bool events) Line 691	C
 	libcurl.dll!curl_easy_perform(Curl_easy * data) Line 711	C

as of possible timeout - i guess it's not in this case cause:

a) -w "@curl-format.txt"

time_namelookup: %{time_namelookup} time_connect: %{time_connect} time_appconnect: %{time_appconnect} time_pretransfer: %{time_pretransfer} time_redirect: %{time_redirect} time_starttransfer: %{time_starttransfer} time_total: %{time_total}

and fault request shows:
time_namelookup: 0.004688 time_connect: 0.299161 time_appconnect: 0.892617 time_pretransfer: 0.892932 time_redirect: 0.000000 time_starttransfer: 0.892983 time_total: 0.893292

b) SOCKET_WRITABLE checks socket with timeleft==0, (in both http1.1 and http2 variants). So nonblock socket immediatly return it's state.

b) SOCKET_WRITABLE checks socket with timeleft==0, (in both http1.1 and http2 variants). So nonblock socket immediatly return it's state.

Ok. It seems to me technically it is timing out though. select is supposed to return the ready sockets even if 0 timeout (AFAIK). So there is no ready socket and it times out immediately. This is probably a race condition like #1410 which is why you don't see the server reply. We could probably improve on this in schannel. I'm playing around with making the schannel send not block on sending a full record. That requires that the function be called again with the same parameters but we have a similar situation with OpenSSL SSL_write so I'm thinking it should work..

Could this error be related? 8843678#comments

I do not get the warning/error then I compile curl using autotools/mingw, but the CMake build on AppVeyor started to fail after that commit.