Fix HTTP/3 bug: uploading payload larger than 65536 will be blocked until timeout.

[MegatronKing]

The upload buffer default size is 65536, if we post a payload larger than this, the first buffer is ok, but when sending the second buffer, the stream will be blocked with a curlcode CURLE_AGAIN. I supoose the cause is the upload_len was not reset.

[bagder]

and the other comment, what do you think about it?

[MegatronKing]

@bagder
Actually, I am not very confident about my fix, I tested with all my POST cases and all approved.
I am confusing about the function 'cb_h3_readfunction', when and how it would be invoked? And this line

curl/lib/vquic/ngtcp2.c

Line 1350 in b836b06

if(data->set.postfields) {

also is specific for POST and I am not able to understand too.

[MegatronKing]

My test cases:

• POST application/octem 10/100/1024/1024 * 1024/10 * 1024 * 1024
• POST multipart/form-data 10/100/1024/1024 * 1024/10 * 1024 * 1024
  And something intersting, POST multipart/form-data and data->set.postfields is false.

[bagder]

POST multipart/form-data and data->set.postfields is false

That's why I didn't like the fix. set.postfields is only set with CURLOPT_POSTFIELDS while you can send data over HTTP several other ways with libcurl. One of those ways you see. You can also try curl -T [file] -X POST $URL ...

So if you make the change I proposed, does it still work or isn't that good enough?

[MegatronKing]

if data->set.postfields is true, a flag NGHTTP3_DATA_FLAG_EOF is set and return, and the value of stream->upload_len would never be updated, right? I think this is a bug.

[MegatronKing]

Agree with the fix is not good enough, I updated!

[bagder]

do you have a HTTP/3 test server somewhere that you can do large posts to, to verify this fix?

[bagder]

Thanks, I pushed this as I believe it does improve things. I still experience problems if I upload multiple megabytes, but after all the data has been sent...