moparisthebest/curl
1
0
Fork 0
mirror of https://github.com/moparisthebest/curl synced 2025-01-08 12:28:06 -05:00
Code Issues Releases Wiki Activity

KNOWN_BUGS: add three HTTP/3 issues

Browse Source 
... and moved the HTTP/2 issues to its own section

Closes #6606
Closes #6510
Closes #6494
This commit is contained in:
Daniel Stenberg 2021-05-03 17:22:52 +02:00
parent 94241a9e78
commit e41f2e5225
No known key found for this signature in database
GPG Key ID: 5CC908FDB71E12C2
1 changed files with 45 additions and 22 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

67
docs/KNOWN_BUGS
View File

@ -12,7 +12,6 @@ check the changelog of the current development status, as one or more of these
problems may have been fixed or changed somewhat since this was written!
1. HTTP
1.1 Excessive HTTP/2 packets with TCP_NODELAY
1.2 Multiple methods in a single WWW-Authenticate: header
1.3 STARTTRANSFER time is wrong for HTTP POSTs
1.4 multipart formposts file name encoding
@ -20,7 +19,6 @@ problems may have been fixed or changed somewhat since this was written!
1.6 Unnecessary close when 401 received waiting for 100
1.7 Deflate error after all content was received
1.8 DoH isn't used for all name resolves when enabled
1.9 HTTP/2 frames while in the connection pool kill reuse
1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
2. TLS
@ -144,20 +142,19 @@ problems may have been fixed or changed somewhat since this was written!
16. Applications
16.1 pulseUI VPN client
17. HTTP/2
17.1 Excessive HTTP/2 packets with TCP_NODELAY
17.2 HTTP/2 frames while in the connection pool kill reuse
18. HTTP/3
18.1 If the HTTP/3 server closes connection during upload curl hangs
18.2 Uploading HTTP/3 files gets interrupted at certain file sizes
18.3 HTTP/3 download is 5x times slower than HTTP/2
==============================================================================
1. HTTP
1.1 Excessive HTTP/2 packets with TCP_NODELAY
Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued
using more separate TCP packets than it would otherwise need to use. This
means spending more bytes than it has to. Just disabling TCP_NODELAY for
HTTP/2 is also not the correct fix because that then makes the outgoing
packets to get delayed.
See https://github.com/curl/curl/issues/6363
1.2 Multiple methods in a single WWW-Authenticate: header
The HTTP responses headers WWW-Authenticate: can provide information about
@ -215,16 +212,6 @@ problems may have been fixed or changed somewhat since this was written!
See https://github.com/curl/curl/pull/3857 and
https://github.com/curl/curl/pull/3850
1.9 HTTP/2 frames while in the connection pool kill reuse
If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
curl while the connection is held in curl's connection pool, the socket will
be found readable when considered for reuse and that makes curl think it is
dead and then it will be closed and a new connection gets created instead.
This is *best* fixed by adding monitoring to connections while they are kept
in the pool so that pings can be responded to appropriately.
1.11 CURLOPT_SEEKFUNCTION not called with CURLFORM_STREAM
I'm using libcurl to POST form data using a FILE* with the CURLFORM_STREAM
@ -1016,3 +1003,39 @@ problems may have been fixed or changed somewhat since this was written!
See
https://community.pulsesecure.net/t5/Pulse-Desktop-Clients/Linux-Pulse-Client-does-not-work-with-curl-7-74/m-p/44378
and https://github.com/curl/curl/issues/6306
17. HTTP/2
17.1 Excessive HTTP/2 packets with TCP_NODELAY
Because of how curl sets TCP_NODELAY by default, HTTP/2 requests are issued
using more separate TCP packets than it would otherwise need to use. This
means spending more bytes than it has to. Just disabling TCP_NODELAY for
HTTP/2 is also not the correct fix because that then makes the outgoing
packets to get delayed.
See https://github.com/curl/curl/issues/6363
17.2 HTTP/2 frames while in the connection pool kill reuse
If the server sends HTTP/2 frames (like for example an HTTP/2 PING frame) to
curl while the connection is held in curl's connection pool, the socket will
be found readable when considered for reuse and that makes curl think it is
dead and then it will be closed and a new connection gets created instead.
This is *best* fixed by adding monitoring to connections while they are kept
in the pool so that pings can be responded to appropriately.
18. HTTP/3
18.1 If the HTTP/3 server closes connection during upload curl hangs
See https://github.com/curl/curl/issues/6606
18.2 Uploading HTTP/3 files gets interrupted at certain file sizes
See https://github.com/curl/curl/issues/6510
18.3 HTTP/3 download is 5x times slower than HTTP/2
See https://github.com/curl/curl/issues/6494