Re: curl tests now use perl module Memoize.pm
Am 17.05.23 um 10:14 schrieb Dan Fandrich: On Wed, May 17, 2023 at 09:48:39AM +0200, Rainer Jung via curl-library wrote: I just wanted to note, that the test suite now uses the perl module Memoize.pm. That module is contained in the perl base package eg. for RHEL 7, but for RHEL 8 must be installed as perl-Memoize. I had assumed this would be available everywhere in a base perl installation and therefore safe to use, especially since nobody complained until now. Memoize just improves test performance and isn't critical, so if it's going to cause issues it could be made optional. Are there any other perl distributions that relegate it to a separate package? As far as I could see, it seems to be mostly the RHEL, Fedora and similar distributions. And for them it is easy to install. So maybe a hint in the test suite explanations wouold be nice, but I don't see the need to make it optional. Thanks and regards, Rainer -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
> On 17 May 2023, at 16:44, Daniel Stenberg via curl-library > wrote: > So: not an easy limit to toy around with. I don't think we should raise this, there is no benefit to the vast majority of users. Anyone who has an environment where they need this have the code available to build a custom libcurl for their application. -- Daniel Gustafsson -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote: And more specifically by the 8KB limit applied to the cookier headers. Back again, having done some more thinking. The main problem with upping this limit is that a typical user don't know what the maximum allowed line length in the other end is. The limit was introduced because it was noticed that (some) servers will treat a too long line as a serious error and repond with a 400. If curl receives a set of cookies that combined needs TOO_LONG bytes to get sent over the wire, and it gets a 400 back, then curl is pretty much stuck and can't do anything against that server without some actions or when enough number of cookies expire...! So: not an easy limit to toy around with. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 17 May 2023, Daniel Stenberg via curl-library wrote: This however goes directly against RFC 6265 section 5.4 which says: I submitted this issue to the http wg: https://github.com/httpwg/http-extensions/issues/2541 -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 17 May 2023, Daniel Stenberg via curl-library wrote: Beyond 8K something HTTP servers are going to cause problems with their maximum header line lengths and then it becomes even harder to interop. Something else struck me and here's a suitable RFC reference: https://www.rfc-editor.org/rfc/rfc7540#section-8.1.2.5 To allow for better compression efficiency, the Cookie header field MAY be split into separate header fields, each with one or more cookie-pairs. If Meaning: for outgoing requests, at least for HTTP/2, we could split the header into multiple header lines. As long as each individual name + value pair is shorter than 8K combined, but I presume they usually are. This however goes directly against RFC 6265 section 5.4 which says: When the user agent generates an HTTP request, the user agent MUST NOT attach more than one Cookie header field. (almost the exact same wording is kept in the RFC 6265bis draft-12) It makes me suspect that doing this would introduce interop problems. :-( -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 17 May 2023, Benjamin Herrenschmidt wrote: In the general case, yes. That said, it could very well be that curl (or libcurl) is used in specific cases (private API gateways etc...) where the interoperability isn't a factor. At this point I don't have enough data about the specific customer use case. But I can imagine some that don't necessarily involve general purpose components (web browser etc...). Right, or they ran into this limit first so they never got around to do the second (browser) test ... :-) ... propose a reasonable value that works for them. Beyond 8K something HTTP servers are going to cause problems with their maximum header line lengths and then it becomes even harder to interop. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 2023-05-17 at 09:24 +0200, Daniel Stenberg wrote: Thanks for your reply... > On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote: > > > And more specifically by the 8KB limit applied to the cookier headers. > > > > Now I understand the value in preventing runaway header attacks and it does > > make a lot of sense to use a limit, but is there a reason not to make this > > limit configurable for use cases where 8KB is simply not sufficient ? > > Yes, because they are (probably) no longer interoperable then. .../... > > ... meaning that if you go beyond these limits, there seem to be a big chance > that they won't interoperate with other major cookie users, like browsers. > Which probably brings the question back to your users: do they *REALLY* want > larger cookies that then risk not being possible to use with other consumers > anyway? > > This said, bumping curl's limit should still be harmless even if not quite > interoperable. In the general case, yes. That said, it could very well be that curl (or libcurl) is used in specific cases (private API gateways etc...) where the interoperability isn't a factor. At this point I don't have enough data about the specific customer use case. But I can imagine some that don't necessarily involve general purpose components (web browser etc...). I will try to get some data, at the very least so that I can > > I'm generally weary of libcurl API/ABI changes, so the least disruptive > > approach I can think of would be to have an env. variable that can > > optionally raise the limit. > > I think I would rather prefer simply bumping the limit unconditionally for > everyone. For simplicity. Both in code and for users. ... propose a reasonable value that works for them. I agree, simpler is better and bumping the value wouldn't affect the "spirit" of the original change which is to avoid unbounded growth. Cheers, Ben. -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: curl tests now use perl module Memoize.pm
On Wed, May 17, 2023 at 09:48:39AM +0200, Rainer Jung via curl-library wrote: > I just wanted to note, that the test suite now uses the perl module > Memoize.pm. That module is contained in the perl base package eg. for RHEL > 7, but for RHEL 8 must be installed as perl-Memoize. I had assumed this would be available everywhere in a base perl installation and therefore safe to use, especially since nobody complained until now. Memoize just improves test performance and isn't critical, so if it's going to cause issues it could be made optional. Are there any other perl distributions that relegate it to a separate package? Dan -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: curl tests now use perl module Memoize.pm
V Wed, May 17, 2023 at 09:48:39AM +0200, Rainer Jung via curl-library napsal(a): > I just wanted to note, that the test suite now uses the perl module > Memoize.pm. That module is contained in the perl base package eg. for RHEL > 7, but for RHEL 8 must be installed as perl-Memoize. > Installing "perl(Memoize)" is compatible across all RHEL releases. -- Petr signature.asc Description: PGP signature -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl tests now use perl module Memoize.pm
Hi there, thanks for the new release! I just wanted to note, that the test suite now uses the perl module Memoize.pm. That module is contained in the perl base package eg. for RHEL 7, but for RHEL 8 must be installed as perl-Memoize. The change was introduced in https://github.com/curl/curl/commit/2039253c6e10b6f3d17d7f6dcdc6228f7b0b3784 Not a problem, just wanted to mention it in case others run into this as well. Best regards, Rainer -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
Re: Issue with MAX_COOKIE_HEADER_LEN
On Wed, 17 May 2023, Benjamin Herrenschmidt via curl-library wrote: And more specifically by the 8KB limit applied to the cookier headers. Now I understand the value in preventing runaway header attacks and it does make a lot of sense to use a limit, but is there a reason not to make this limit configurable for use cases where 8KB is simply not sufficient ? Yes, because they are (probably) no longer interoperable then. RFC 6265 section 6.1 which dictates the "limits" says that "general-use user agents SHOULD provide each of the following minimum capabilities": o At least 4096 bytes per cookie (as measured by the sum of the length of the cookie's name, value, and attributes). But in the update work, RFC6265bis section 5.4, which is not final yet the draft-10 instead says: If the sum of the lengths of the name string and the value string is more than 4096 octets, abort these steps and ignore the set-cookie-string entirely. ... meaning that if you go beyond these limits, there seem to be a big chance that they won't interoperate with other major cookie users, like browsers. Which probably brings the question back to your users: do they *REALLY* want larger cookies that then risk not being possible to use with other consumers anyway? This said, bumping curl's limit should still be harmless even if not quite interoperable. I'm generally weary of libcurl API/ABI changes, so the least disruptive approach I can think of would be to have an env. variable that can optionally raise the limit. I think I would rather prefer simply bumping the limit unconditionally for everyone. For simplicity. Both in code and for users. -- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl: CVE-2023-28322: more POST-after-PUT confusion
more POST-after-PUT confusion = Project curl Security Advisory, May 17 2023 - [Permalink](https://curl.se/docs/CVE-2023-28322.html) VULNERABILITY - When doing HTTP(S) transfers, libcurl might erroneously use the read callback (`CURLOPT_READFUNCTION`) to ask for data to send, even when the `CURLOPT_POSTFIELDS` option has been set, if the same handle previously was used to issue a `PUT` request which used that callback. This flaw may surprise the application and cause it to misbehave and either send off the wrong data or use memory after free or similar in the second transfer. The problem exists in the logic for a reused handle when it is (expected to be) changed from a PUT to a POST. INFO The code actually sending wrong data or doing a use-after-free is not present in libcurl code but are only presumed scenarios that might become the outcome of libcurl surprisingly calling the read callback in a situation where it is not expected to. This flaw cannot be triggered with the command line tool. This problem is almost identical to [CVE-2022-32221](https://curl.se/docs/CVE-2022-32221.html). A difference this time is that setting `CURLOPT_POST` for the second transfer avoids the problem, where as only setting `CURLOPT_POSTFIELDS` after the PUT still makes the second transfer to a PUT and use the callback. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28322 to this issue. CWE-440: Expected Behavior Violation Severity: Low AFFECTED VERSIONS - - Affected versions: libcurl 7.7 to and including 8.0.1 - Not affected versions: libcurl < 7.7 and >= 8.1.0 - Introduced-in: https://github.com/curl/curl/commit/546572da0457f3 libcurl is used by many applications, but not always advertised as such! SOLUTION This time the logic is improved to avoid having two separate variable fields holding info about HTTP method and behavior. Now there is only one, which should make it harder to end up in such a confused middle state. - Fixed-in: https://github.com/curl/curl/commit/7815647d6582c0a4900be2e1de RECOMMENDATIONS -- A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version C - Do not do mix using the read callback and `CURLOPT_POSTFIELDS` string on a reused easy handle TIMELINE This issue was reported to the curl project on April 19, 2023. We contacted distros@openwall on May 9, 2023. libcurl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory. CREDITS --- - Reported-by: Hiroki Kurosawa - Patched-by: Daniel Stenberg Thanks a lot! -- / daniel.haxx.se -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl: CVE-2023-28321: IDN wildcard match
IDN wildcard match == Project curl Security Advisory, May 17th 2023 - [Permalink](https://curl.se/docs/CVE-2023-28321.html) VULNERABILITY - curl supports matching of wildcard patterns when listed as "Subject Alternative Name" in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`. INFO curl's wildcard matching function is used only when curl was built to use OpenSSL, Schannel or Gskit. All other backends use the matching functions of the corresponding TLS library and are thus not vulnerable to this flaw. This flaw is lessened somewhat by two factors: - Certificates issued by Certificate Authorities for the public Internet are not allowed to use "partial" wildcards, thus completely avoiding this issue. - In many circumstances, the control of host names used and the wildcards used in issued certificates are controlled by the same entity, making this unlikely to actually become a problem. curl does not need to be built with IDN support to be vulnerable, as a user can pass in a puny coded version of the host name directly in the URL and can then trigger this flaw. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28321 to this issue. CWE-295: Improper Certificate Validation Severity: Low AFFECTED VERSIONS - This bug was introduced in curl when IDN support was first introduced, in curl 7.12.0 - June 2004. The wildcard function was subsequently updated for this case in 2012 (the IDN problem is mentioned in RFC 6125 in a far from obvious way) but was done wrongly, so the flaw remained. - Affected versions: curl 7.12.0 to and including 8.0.1 - Not affected versions: curl < 7.12.0 and curl >= 8.1.0 - Introduced-in: https://github.com/curl/curl/commit/9631fa740708b1890197fad libcurl is used by many applications, but not always advertised as such! SOLUTION curl 8.1.0 completely removes the support for "partial" patches and now only supports `*.`. No `a*`, `a*b` or `*b` matches. For all host names, IDN or not. - Fixed-in: https://github.com/curl/curl/commit/199f2d440d8659b42 RECOMMENDATIONS -- A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version TIMELINE This issue was reported to the curl project on April 17 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory. CREDITS --- - Reported-by: Hiroki Kurosawa - Patched-by: Daniel Stenberg Thanks a lot! -- / daniel.haxx.se -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl: CVE-2023-28320: siglongjmp race condition
siglongjmp race condition = Project curl Security Advisory, May 17th 2023 - [Permalink](https://curl.se/docs/CVE-2023-28320.html) VULNERABILITY - libcurl provides several different backends for resolving host names, selected at build time. If it is built to use the synchronous resolver, it allows name resolves to time-out slow operations using `alarm()` and `siglongjmp()`. When doing this, libcurl used a global buffer that was not mutex protected and a multi-threaded application might therefore crash or otherwise misbehave. INFO Most platforms and systems build libcurl to use the threaded resolver or with c-ares, neither of those suffer from this flaw. Most platforms that build with the synchronous resolver don't feature `alarm()` and `siglongjmp()` and therefor are not vulnerable either. Since `alarm()` uses signals, it is not advisable to use in a multi-threaded environment (signals and threads rarely mix very well) which reduces the risk that this flaw hurts many users. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28320 to this issue. CWE-662: Improper Synchronization Severity: Low AFFECTED VERSIONS - - Affected versions: curl 7.9.8 to and including 8.0.1 - Not affected versions: curl < 7.9.8 and curl >= 8.1.0 - Introduced-in: https://github.com/curl/curl/commit/3c49b405de4fbf1f libcurl is used by many applications, but not always advertised as such! SOLUTION The fix is to only support this timeout ability if curl has and can properly mutex protect the buffer. - Fixed-in: https://github.com/curl/curl/commit/13718030ad4b3209a7583b RECOMMENDATIONS -- A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version C - Do not use the synchronous name resolver option TIMELINE This issue was reported to the curl project on April 2 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory. CREDITS --- - Reported-by: Harry Sintonen - Patched-by: Harry Sintonen, Daniel Stenberg Thanks a lot! -- / daniel.haxx.se -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
curl: CVE-2023-28319: UAF in SSH sha256 fingerprint check
UAF in SSH sha256 fingerprint check Project curl Security Advisory, May 17th 2023 - [Permalink](https://curl.se/docs/CVE-2023-28319.html) VULNERABILITY - libcurl offers a feature to verify an SSH server's public key using a SHA 256 hash. When this check fails, libcurl would free the memory for the fingerprint before it returns an error message containing the (now freed) hash. This flaw risks inserting sensitive heap-based data into the error message that might be shown to users or otherwise get leaked and revealed. INFO This only applies to users of the `CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256` option, which is **only supported for libcurl built with libssh2** (curl optionally supports other SSH backends). Either of the options `CURLOPT_VERBOSE` or `CURLOPT_ERRORBUFFER` also need to be set to trigger the problem. The damage is somewhat limited by the extremely short time window between the free and the use of the freed memory. The largest possible info leak that can happen due to this flaw per trigger occasion, is limited to `CURL_ERROR_SIZE` - the error message prefix length (69) = 186 bytes. It will also stop at the first null byte within those 186 bytes. The Common Vulnerabilities and Exposures (CVE) project has assigned the name CVE-2023-28319 to this issue. CWE-416: Use After Free Severity: Medium AFFECTED VERSIONS - - Affected versions: curl 7.81.0 to and including 8.0.1 - Not affected versions: curl < 7.81.0 and curl >= 8.1.0 - Introduced-in: https://github.com/curl/curl/commit/3467e89bb97e6c87c7 libcurl is used by many applications, but not always advertised as such! SOLUTION - Fixed-in: https://github.com/curl/curl/commit/8e21b1a05f3c0ee098dbcb6c RECOMMENDATIONS -- A - Upgrade curl to version 8.1.0 B - Apply the patch to your local version C - Do not use `CURLOPT_SSH_HOST_PUBLIC_KEY_SHA256` TIMELINE This issue was reported to the curl project on March 21 2023. We contacted distros@openwall on May 9, 2023. curl 8.1.0 was released on May 17 2023, coordinated with the publication of this advisory. CREDITS --- - Reported-by: Wei Chong Tan - Patched-by: Daniel Stenberg Thanks a lot! -- / daniel.haxx.se -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.html
[RELEASE] curl 8.1.0
Hi team, I'm happy to announce that I just packaged, signed and uploaded another curl release. This time in association with four security advisories, which I will email about shortly. As always, get curl from here: https://curl.se/ curl and libcurl 8.1.0 Public curl releases: 217 Command line options: 251 curl_easy_setopt() options: 302 Public functions in libcurl: 91 Contributors: 2875 This release includes the following changes: o curl: add --proxy-http2 [62] o CURLPROXY_HTTPS2: for HTTPS proxy that may speak HTTP/2 [57] o hostip: refuse to resolve the .onion TLD [19] o tool_writeout: add URL component variables [41] This release includes the following bugfixes: o amiga: Fix CA certificate paths for AmiSSL and MorphOS [150] o autotools: sync up clang picky warnings with cmake [114] o aws-sigv4.d: fix region identifier in example [168] o bufq: simplify since expression is always true [72] o cf-h1-proxy: skip an extra NULL assign [80] o cf-h2-proxy: fix processing ingress to stop too early [76] o cf-socket: add socket recv buffering for most tcp cases [90] o cf-socket: Disable socket receive buffer by default [75] o cf-socket: remove dead code discovered by PVS [82] o cf-socket: turn off IPV6_V6ONLY on Windows if it is supported [123] o checksrc: check for spaces before the colon of switch labels [160] o checksrc: find bad indentation in conditions without open brace [152] o checksrc: fix SPACEBEFOREPAREN for conditions starting with "*" [115] o ci: `-Wno-vla` no longer necessary [158] o CI: fix brew retries on GHA o CI: Set minimal permissions on workflow ngtcp2-quictls.yml [153] o CI: skip Azure for commits which change only GHA o CI: use another glob syntax for matching files on Appveyor o cmake: bring in the network library on Haiku [9] o cmake: do not add zlib headers for openssl [49] o CMake: make config version 8 compatible with 7 [28] o cmake: picky-linker fixes for openssl, ZLIB, H3 and more [31] o cmake: set SONAME for SunOS too [3] o cmake: speed up and extend picky clang/gcc options [116] o CMakeLists.txt: fix typo for Haiku detection [95] o compressed.d: clarify the words on "not notifying headers" [163] o config-dos.h: fix SIZEOF_CURL_OFF_T for MS-DOS/DJGPP [52] o configure: don't set HAVE_WRITABLE_ARGV on Windows [64] o configure: fix detection of apxs (for httpd) [157] o configure: make quiche require quiche_conn_send_ack_eliciting [46] o connect: fix https connection setup to treat ssl_mode correctly [94] o content_encoding: only do transfer-encoding compression if asked to [61] o cookie: address PVS nits [74] o cookie: clarify that init with data set to NULL reads no file [99] o curl: do NOT append file name to path for upload when there's a query [58] o curl_easy_getinfo.3: typo fix (duplicated "from the") [43] o curl_easy_unescape.3: rename the argument [113] o curl_path: bring back support for SFTP path ending in /~ [130] o curl_url_set.3: mention that users can set content rather freely [105] o CURLOPT_IPRESOLVE.3: this for host names, not IP addresses [165] o data.d: emphasize no conversion [5] o digest: clear target buffer [8] o doc: curl_mime_init() strong easy binding was relaxed in 7.87.0 [26] o docs/cmdline-opts: document the dotless config path [1] o docs/examples/protofeats.c: outputs all protocols and features [110] o docs/libcurl/curl_*escape.3: rename "url" argument to "input"/"string" [131] o docs/SECURITY-ADVISORY.md: how to write a curl security advisory [128] o docs: bump the minimum perl version to 5.6 o docs: clarify that more backends have HTTPS proxy support [127] o dynbuf: never allocate larger than "toobig" [17] o easy_cleanup: require a "good" handle to act [149] o ftp: fix 'portsock' variable was assigned the same value [78] o ftp: remove dead code [79] o ftplistparser: move out private data from public struct [20] o ftplistparser: replace realloc with dynbuf [18] o gen.pl: error on duplicated See-Also fields [102] o getpart: better handle case of file not found o GHA-linux: add an address-sanitizer build [15] o GHA: add a memory-sanitizer job [2] o GHA: run all linux test jobs with valgrind [14] o GHA: suppress git clone output [89] o GIT-INFO: add --with-openssl [171] o gskit: various compile errors in OS400 [12] o h2/h3: replace `state.drain` counter with `state.dselect_bits` [141] o hash: fix assigning same value [73] o headers: clear (possibly) lingering pointer in init [167] o hostcheck: fix host name wildcard checking [134] o hostip: add locks around use of global buffer for alarm() [129] o hostip: enforce a maximum DNS cache size independent of timeout value [166] o HTTP-COOKIES.md: mention the #HttpOnly_ prefix [16] o http2: always EXPIRE_RUN_NOW unpaused http/2 transfers [139] o http2: do flow window accounting for cancelled streams [155] o http2: enlarge the connection window [101] o http2: flow control and buffer
