KNOWN_BUGS: add three HTTP/3 issues

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

Closes #6606
Closes #6510
Closes #6494

diff --git a/docs/KNOWN_BUGS b/docs/KNOWN_BUGS
index 243f678a68436aed59e82c0228690e66c8ee9ca8..b44cf2e2fa21ac21be6422d5d061358832f33a28 100644 (file)
--- a/docs/KNOWN_BUGS
+++ b/docs/KNOWN_BUGS
@@ -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,19 +142,18 @@ problems may have been fixed or changed somewhat since this was written!
  16. Applications
  16.1 pulseUI VPN client
 
-==============================================================================
-
-1. HTTP
+ 17. HTTP/2
+ 17.1 Excessive HTTP/2 packets with TCP_NODELAY
+ 17.2 HTTP/2 frames while in the connection pool kill reuse
 
-1.1 Excessive HTTP/2 packets with TCP_NODELAY
+ 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
 
- 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. HTTP
 
 1.2 Multiple methods in a single WWW-Authenticate: header
 
@@ -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