tunnelfetch 1.6.0 → 1.6.1

package/README.md

@@ -427,7 +427,8 @@ pinned in `test/tls/fingerprint.test.js` and `test/http2/fingerprint.test.js`.
 | Signature algorithms | ECDSA and RSA-PSS/PKCS#1 over SHA-256/384/512 | `tls.sigSchemes` |
 | ALPN | `h2, http/1.1` | `tls.alpn` |
 | HTTP/2 `SETTINGS` ids **and order** | curl's: `MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, ENABLE_PUSH` | `http2Settings` |
-| h2 preface, `WINDOW_UPDATE`, pseudo-header order, HPACK representation | curl's, byte-for-byte | fixed |
+| h2 preface, `WINDOW_UPDATE`, pseudo-header order | curl's, byte-for-byte | `http2ConnectionWindow`, `http2PseudoHeaderOrder` |
+| HPACK representation | curl's (`:path` without indexing, the rest incremental) | `http2HpackIndexing` |
 | `Accept-Encoding` | `gzip, deflate` — curl's | `decoders` appends |
 
 Extension order matters because JA3 and JA4 hash the extension list **in wire order**, so it is most

package/README.zh-CN.md

@@ -335,7 +335,8 @@ curl（8.7.1 / nghttp2），照线上抓包原样复刻。这么做是实证需
 | 签名算法 | SHA-256/384/512 上的 ECDSA 与 RSA-PSS/PKCS#1 | `tls.sigSchemes` |
 | ALPN | `h2, http/1.1` | `tls.alpn` |
 | HTTP/2 `SETTINGS` 的 id **与顺序** | curl 的：`MAX_CONCURRENT_STREAMS, INITIAL_WINDOW_SIZE, ENABLE_PUSH` | `http2Settings` |
-| h2 前导、`WINDOW_UPDATE`、伪头顺序、HPACK 表示 | curl 的，逐字节一致 | 固定 |
+| h2 前导、`WINDOW_UPDATE`、伪头顺序 | curl 的，逐字节一致 | `http2ConnectionWindow`、`http2PseudoHeaderOrder` |
+| HPACK 表示 | curl 的（`:path` 不索引，其余 incremental） | `http2HpackIndexing` |
 | `Accept-Encoding` | `gzip, deflate`——curl 的 | `decoders` 会追加 |
 
 扩展顺序之所以要紧，是因为 JA3 和 JA4 哈希的正是**线上顺序**的扩展列表，那是指纹识别读到的主要内容。`pre_shared_key` 无论你怎么配都强制排最后：RFC 8446 §4.2.11 把 binder 的转录定义为"截到 binder 之前的那段 hello"，只有后面不跟东西时这个范围才成立。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "tunnelfetch",
-  "version": "1.6.0",
+  "version": "1.6.1",
   "description": "A fetch-shaped HTTP client that can route through HTTP CONNECT / HTTPS / SOCKS5 proxies on runtimes with only raw TCP, such as Cloudflare Workers. Implements TLS in userland because the runtime cannot verify a tunnelled peer.",
   "keywords": [
     "fetch",

package/src/client.js

@@ -501,6 +501,15 @@ function registerHttp2(client, key, conn) {
       // `tls`, and one being reachable while the other was not made "the fingerprint is
       // configurable" only half true.
       ...(client.options.http2Settings ? { settings: client.options.http2Settings } : {}),
+      // The connection-level WINDOW_UPDATE that follows the preface. It is part of the h2
+      // fingerprint and it was DEAD: `profiles.chrome` declared `http2ConnectionWindow`, nothing
+      // copied it out of the profile, nothing passed it here, and the connection reads an option
+      // spelled `connectionWindow`. The identifier appeared in exactly two places in the whole
+      // repository — the profile and its type declaration — so a Chromium ClientHello was followed
+      // by curl's 1000 MiB window increment, which is about as distinctive as an h2 client gets.
+      ...(client.options.http2ConnectionWindow
+        ? { connectionWindow: client.options.http2ConnectionWindow }
+        : {}),
       ...(client.options.http2PseudoHeaderOrder
         ? { pseudoHeaderOrder: client.options.http2PseudoHeaderOrder }
         : {}),

package/src/profiles.js

@@ -95,6 +95,19 @@ export const chrome = Object.freeze({
   // both fingerprints are exactly what the browser normally sends.
   http2Settings: Object.freeze([[1, 65536], [2, 0], [4, 6291456], [6, 262144]]),
   http2ConnectionWindow: 15663105 + 65535,
+  // NOT captured: http2HpackIndexing. So this identity currently presents curl's HPACK
+  // representation (`:path` without indexing, everything else incremental) under a Chromium
+  // ClientHello, which is the split identity this whole module exists to prevent — narrowed to one
+  // field, but real, and named here rather than left to be discovered. It is not in `requires`
+  // because refusing the profile outright over one uncaptured field would take away the working
+  // 90% of the identity, and because the honest fix is a capture rather than a guess: this package
+  // does not invent fingerprint values. See test/http2/fingerprint.test.js, which pins the absence
+  // so that supplying it later is a deliberate act.
+  //
+  // The connection window immediately above was DEAD until 1.6.1 — declared here, copied by
+  // nothing, passed by nothing, and read under a different name — so every connection using this
+  // profile sent curl's 1000 MiB increment. Four places had to agree and no test checked that they
+  // did. There is one now.
   // m,a,s,p — NOT curl's m,s,a,p. Measured, and a difference that would have been easy to miss.
   http2PseudoHeaderOrder: Object.freeze([':method', ':authority', ':scheme', ':path']),
   headerOrder: Object.freeze([
@@ -174,7 +187,11 @@ export function applyProfile(options) {
   for (const kind of ['ciphers', 'groups', 'decoders']) {
     if (p[kind]) out[kind] = { ...p[kind], ...(options[kind] ?? {}) };
   }
-  for (const key of ['headerOrder', 'http2Settings', 'http2PseudoHeaderOrder', 'http2HpackIndexing']) {
+  // Every h2 fingerprint field a profile can carry must be listed here. `http2ConnectionWindow`
+  // was missing, which made it dead config: the chrome profile declared Chromium's ~15 MiB window
+  // and every chrome connection sent curl's 1000 MiB one.
+  for (const key of ['headerOrder', 'http2Settings', 'http2ConnectionWindow',
+                     'http2PseudoHeaderOrder', 'http2HpackIndexing']) {
     if (options[key] === undefined && p[key] != null) out[key] = p[key];
   }
   // Profile headers are DEFAULTS: a request that sets its own User-Agent keeps it. They are folded