v0.1.11

bumping version no. in Cargo.toml and updating Changelog

v0.1.10

http-quik v0.1.10

This patch release establishes absolute default transport parity with the Chrome 148 stable identity profile, details the protocol settings alignment (including HTTP/3 settings optimization and dynamic QPACK table deallocation), integrates a mock TLS interceptor validation test, and comprehensively refactors developer comments and inline specifications across all modified modules.

---

Chrome 148 Upgrade: Stealth Rationale

In cryptographic and protocol-level evasion contexts, matching the most representative active user-agent version on the web is paramount.

• The Shift from 147 to 148: Chrome 147 was launched in early April 2026, followed by Chrome 148 on April 22, 2026. As of mid-May 2026, live telemetry and global browser market share data confirmed that Chrome 148 has completed its multi-week progressive auto-update rollout, becoming the highly dominant stable Chrome build on the web.
• WAF client-Hint Cross-Checks: Modern Web Application Firewalls (such as Cloudflare and Akamai) cross-examine the sec-ch-ua and sec-ch-ua-platform-version Client Hints against live, active browser release indexes. Spoofing Chrome 147 while the global population has fully transitioned to Chrome 148 triggers anomalies in client entropy calculations, causing increased security classification scores. Bumping our default persona to Chrome 148 ensures absolute alignment with standard internet traffic signatures.

---

New Features

Chrome 148 Stable Transport Profile (src/profile/chrome_148.rs)

Delivers a bit-perfect implementation of the Chrome 148 identity signature, capturing exact cryptographic and application-layer settings observed globally:

• Unified ALPS Payload Structure: Chrome 148 removes the platform-specific 0x7A9A (31386) settings payload previously appended on Windows and Linux clients. The ALPS settings block has been unified globally to a platform-invariant 24-byte payload.
• Post-Quantum Cryptographic Key Shares: Maintains strict prioritization of the X25519MLKEM768 hybrid group (id=4588) in the advertised ClientHello curves to match BoringSSL specifications.
• Stateful Client Hints Realignment: Aligns default User-Agent strings and Client Hint platforms ("macOS", "Windows", "Linux") with the "148" version footprint, and preserves the "13.0.0" platform version spoof for Windows 11 target systems.

HTTP/3 and QPACK Settings Optimization (src/client/h3.rs)

Updated application-layer setups to match Chrome 148's HTTP/3 stack:

• QPACK Table Deallocation: Configures the dynamic QPACK compression table capacity to 0 (unlimited size limit) and sets decoder blocked stream thresholds to 0. Declaring bounded constraints instantly exposes custom bot-frameworks; matching Chrome's unbounded memory allowance preserves stealth.
• GREASE Settings Overhaul: Removed obsolete HTTP/3 GREASE configurations to prevent protocol-compliance mismatches.

Unified Interception Verification Test (tests/fingerprint.rs)

• Added test_tls_client_hello_initiated_with_correct_header_chrome_148 which boots a raw local TCP listener, intercepts outbound ClientHello byte-streams, and asserts valid TLS Handshake encapsulation (Byte 0 = 0x16), protocol versions, and ClientHello headers (Byte 5 = 0x01).

---

Optimizations and Documentation

Codebase Comment Architecture

Extensively refactored doc-comments and module documentation in all touched source files (src/client/h3.rs, src/client/quic.rs, src/client/pool.rs, src/profile/mod.rs, src/lib.rs):

• WAF Considerations: Added deep technical commentary explaining the forensic implications of flow-control parameters, ALPS payload shapes, and QPACK table caps.
• Spec Mapping: Documented protocol standards (RFC 8441 for H3 extended connect, RFC 9114 for QPACK mechanics) natively within the configuration drivers.

---

Upgrading

Update your Cargo.toml dependencies to pull the Chrome 148 defaults:

[dependencies]
http-quik = "0.1.10"

v0.1.9

http-quik v0.1.9

This release deprecates the legacy Chrome 134 profiles and establishes absolute identity parity with the Chrome 147 network footprint. It also introduces a massive architectural overhaul to the internal documentation of our multiplexing engine, formalizing our transport abstractions to strict systems engineering standards.

---

New Features

Chrome 147 Transport Profile Parity (src/profile/chrome_147.rs)

Delivers a bit-perfect implementation of the Chrome 147 transport identity footprint, matching observed network parameters across macOS, Windows, and Linux environments:

• Post-Quantum Cryptography Integration: Implements exact X25519MLKEM768 curve prioritization (id=4588) to conform with the latest stable Chrome ClientHello signatures.
• Legacy Signature Fallback: Appends the legacy 0x0201 (RSA-PKCS1-SHA1) signature algorithm to the TLS Handshake to accurately spoof passive TLS interception heuristics.
• HTTP/2 Transport Fingerprints: Replicates the exact Chromium SETTINGS frame structure, pseudo-header sequences, and connection window increments (Akamai passive fingerprint parity).
• Dynamic GREASE Randomization: Generates highly evasive sec-ch-ua GREASE properties mapping version 147 against a randomized brand version 8, while aligning platform-specific Client Hints (sec-ch-ua-platform) perfectly with the host OS.

Engine Default Promotion (src/client/pool.rs)

• The chrome_147 identity has been promoted to the default profile globally. The ClientBuilder::build() and profile_auto() constructors now seamlessly default to Chrome 147 identity spoofing without breaking backwards compatibility.

---

Optimizations and Architecture

Connection Pool Documentation Architecture (src/client/pool.rs)

Extensively rewrote inline architectural documentation for the Client connection pool to rigorous engineering standards:

• Transport Decoupling: Formalized the PooledConnection abstraction boundaries, detailing how the polymorphic send interface guarantees transparent HTTP/2 and HTTP/3 request dispatch without leaking transport constraints.
• Lock Topologies: Documented the concurrent reader-writer lock (RwLock) contention models governing the AltSvcCache and cookie persistence mechanisms to explain wait-free reads on the hot path.
• Fallback State Machine: Defined the exact execution flow of the execute_with_redirects algorithm, illustrating the deterministic graceful degradation topology (UDP drop detection $\to$ Alt-Svc eviction $\to$ immediate TCP/H2 fallback).
• RFC Adherence: Added explicit specification mapping, documenting how the engine adheres strictly to RFC 9114 for Alt-Svc discovery and RFC 7231 for 301/302 method rotation semantics.

---

Upgrading

Update your Cargo.toml dependencies:

[dependencies]
http-quik = "0.1.9"

0.1.8

http-quik v0.1.8

This major release delivers a bit-perfect Chrome-fingerprinted HTTP/3 and QUIC dual-stack transport engine, stateful fallback connection pooling with HTTP/2 TCP stream reuse, a hermetic dual-stack simulation integration test suite, and critical connection degradation bug fixes.

---

New Features

Chrome-Fingerprinted HTTP/3 + QUIC Transport Engine (src/client/quic.rs, src/client/h3.rs)

Delivers stealth-optimized HTTP/3 application-layer and QUIC transport-layer parameters matching modern Google Chrome (v134-136) browser fingerprints:

• IETF Transport Alignment: Enforces exact Chromium-identical flow control windows (15 MiB global data limit, 6 MiB per-stream limit) and stream allocations (100 bidirectional / 103 unidirectional streams).
• Chrome client Identity: Maps an empty client connection ID (quiche::ConnectionId::from_ref(&[])) to comply with browser wire specifications and protect against passive edge-layer tracking.
• Unified Event Loop Driver: Spawns an asynchronous tokio actor executing continuous UDP read/write pacing under quiche event tickers.
• QPACK & GREASE Parity: Implements static Chrome compression thresholds (64 KiB dynamic table capacity, 256 KiB field section size, 100 blocked streams) alongside dynamic anti-ossification GREASE settings (0x157).
• JA4H Pseudo-Header Sorting: Strictly orders HTTP/3 headers to align with the Akamai/Cloudflare browser fingerprint signature (:method, :scheme, :authority, :path).

Resilient Fallback and Reuse Engine (src/client/pool.rs)

Integrates our dual-stack transport fallback state machine:

• In-Memory AltSvc Cache: Dynamically registers server-emitted Alt-Svc solicitation headers to transition from H2 to H3 seamlessly.
• Multiplexed Fallback Reuse: If connection or packet transmission fails (such as firewall UDP blockages or packet loss), the pool statefully degrades the cache and rolls back immediately to HTTP/2/TCP.
• Multiplexed Session Reuse: On fallback, the pool checks for active cached H2 TCP sessions to multiplex streams directly, preventing redundant TLS handshakes.

Hermetic Integration Test Suite (tests/h3_scenarios.rs)

• Implemented a dynamic dual-stack mock test test_alt_svc_caching_and_h2_fallback_flow verifying the entire H2-solicit $\to$ H3-cache $\to$ UDP-dial $\to$ transparent H2 fallback lifecycle offline without relying on external networking.

---

Optimizations and Bug Fixes

Fallback Connection Storming & Multiplexing (src/client/pool.rs)

• Issue: Previously, when an HTTP/3 UDP handshake or packet transmission failed (e.g. UDP port blocked), the client fell back to HTTP/2 by dialing a fresh, new TCP connection even if an active HTTP/2 session for the target origin was already active in the pool. This caused redundant handshakes, broke connection multiplexing, and risked triggering WAF rate-limiting blocks.
• Resolution: Refactored the fallback block to check the connection pool first for active HTTP/2 multiplexed sockets and reuse them directly for outbound streams.
• Result: Preserves the established TCP socket, maintains multiplexing efficiency, and eliminates connection storm signatures.

Alt-Svc Cache Degradation Lag (src/client/pool.rs)

• Issue: If an endpoint had UDP or QUIC access blocked, the client would suffer a redundant QUIC handshake timeout delay on every subsequent request because the Alt-Svc cache entries were not dynamically degraded on transmission failures.
• Resolution: Implemented automatic host eviction from the AltSvcCache instantly upon QUIC dial failure or mid-connection transmission error, degrading the state back to TCP/H2 immediately.
• Result: Eliminates path latency overhead for degraded UDP networks.

---

Upgrading

Update your Cargo.toml dependencies:

[dependencies]
http-quik = "0.1.8"

v0.1.7

http-quik v0.1.7

This release delivers critical enhancements to the TLS client profile, completes the Fetch metadata spec coverage for subresources, implements a stateful origin Client Hint caching machine, and resolves connection pool HoL blocking.

---

New Features

Stateful Client Hints Caching (src/client/pool.rs)

Outbound HTTP Client Hints have been upgraded to operate statefully, exactly mirroring a real web browser's handling of solicited metadata:

• Implemented a thread-safe HintCache (Arc<RwLock<HashSet<String>>>) inside the main Client engine.
• Added automatic parsing of incoming server-side Accept-CH headers during standard requests and redirect chains.
• Solicited high-entropy platform version hints (sec-ch-ua-platform-version) are cached per origin and transmitted statefully on all subsequent origin connections.

Comprehensive Fetch Metadata Parity (src/client/request.rs)

Expanded subresource fetch coverage to eliminate passive WAF detection flags on non-document requests:

• Expanded RequestContext with 8 new variants (Iframe, NoCorsScript, NoCorsStyle, NoCorsImage, NoCorsFont, NoCorsMedia, Worker, ServiceWorker, Prefetch).
• Automated matching for exact sec-fetch-dest, sec-fetch-mode, and context-specific Accept headers (e.g., AVIF/WebP preference for images, font-specific payloads, worker script mappings).
• Re-exported RequestContext at the crate root to allow programmatically overriding outbound request metadata.

---

Optimizations and Bug Fixes

Post-Quantum TLS Parity (src/tls/connector.rs, Cargo.toml)

• Issue: The TLS group list regression forced post-quantum hybrid curve 4588 to transmit under the obsolete draft code 25497 (X25519Kyber768Draft00), creating a passive JA3 fingerprint anomaly.
• Resolution: Enabled pq-experimental on the boring crate and updated the connector curves list to resolve 4588 to "X25519MLKEM768".
• Result: Restores perfect alignment with standard Chrome 134 ClientHello post-quantum signatures.

Connection Pool Multiplexing Optimization (src/client/pool.rs)

• Issue: The origin-level connection pool locked conn_mutex while awaiting stream readiness (ready().await), causing head-of-line blocking for high-throughput concurrent requests targeting the same host.
• Resolution: Refactored H2 client stream acquisition to clone active connection instances outside of the pool's async locking context, freeing concurrent tasks to multiplex streams immediately without serialization.

Cross-Origin Referer Stripping (src/client/pool.rs)

• Resolution: Implemented dynamic strict-origin-when-cross-origin policy enforcement, ensuring path and query parameters are stripped down to the root origin during cross-site redirect hops.

GREASE Brand Shuffling & Platform Update (src/profile/chrome_134.rs, Cargo.toml)

• Issue: The time-modulo brand generator introduced population correlations and failed to cover all 3 potential brand slot order configurations.
• Resolution: Upgraded to the modern rand 0.10.1 API to independently randomize brand names, GREASE version tags (8/24/99), and array index position slots uniformly.
• Platform Update: Bumped the Windows platform version from "13.0.0" to "15.0.0" (Windows 11 24H2) to eliminate EOL fingerprint flags.

---

Upgrading

Update your Cargo.toml dependencies:

[dependencies]
http-quik = "0.1.7"

v0.1.6

http-quik v0.1.6

This release introduces improvements to the connection pooling layer, completes the TLS signature algorithm preference alignment for Chrome 134 profiles, and refactors request header generation to support stateful fetch contexts.

---

New Features

Stateful Request Contexts (src/client/request.rs)

Outbound HTTP request header generation has been updated to dynamically configure sec-fetch-dest and sec-fetch-mode headers based on the request origin context.

• Added a RequestContext enum (Navigate, Xhr, Form) representing different fetch profiles.
• Automated Referer header propagation and preservation across redirect hops in the redirection loop.

Delimiter and Brand Randomization in Client Hints (src/profile/chrome_134.rs)

To match Chrome's non-deterministic user-agent brand fingerprinting, the sec-ch-ua generation now dynamically randomizes:

• Delimiter styling (rotating between delimiters such as Not:A-Brand and Not;A=Brand).
• Simulated brand versions (8, 24, and 99).
• The index slot of the GREASE brand within the structured array (alternating between slot 0 and slot 1).

Concurrent HTTP/2 Connection Pool Multiplexing (src/client/pool.rs)

Redesigned connection pool synchronization to prevent concurrent requests to the same origin from spawning redundant TCP/TLS dials:

• Wrapped connection entries inside Arc<tokio::sync::Mutex<Option<QuikConnection>>>.
• Implemented origin-level locking so that concurrent tasks to the same host wait asynchronously for a single active TLS handshake to complete, then clone and multiplex HTTP/2 streams over the resulting connection.

---

Optimizations and Bug Fixes

TLS Signature Algorithm Preferences (src/tls/connector.rs)

Resolved a silent configuration issue where legacy OpenSSL signature algorithm APIs failed under BoringSSL.

• Issue: The legacy function SSL_CTX_set1_sigalgs expects (hash_nid, pkey_type) pairs rather than raw algorithm identifiers, causing it to return 0 (failure) and fall back to system defaults.
• Resolution: Refactored the signature algorithm preference configuration to directly use modern BoringSSL FFI functions:
  • SSL_CTX_set_signing_algorithm_prefs
  • SSL_CTX_set_verify_algorithm_prefs
• Result: Enforces the exact signature algorithm list expected for the Chrome 134 profile (0403,0804,0401,0503,0805,0501,0806,0601).

Client Hints Isolation

Outbound sec-ch-ua-platform-version headers are now suppressed on initial requests and only sent when explicitly requested by the server via accept-ch.

Refactoring & Quality Gate Cleanups

Audited the codebase under strict Clippy quality gate rules:

• Extracted nested connection pool fields in src/client/pool.rs into SharedConnection and ConnectionPool type aliases to reduce complexity.
• Aligned modulo operations with usize::is_multiple_of in src/profile/chrome_134.rs.
• Standardized compiler diagnostic directives across module definitions.

---

Upgrading

Update your Cargo.toml dependencies:

[dependencies]
http-quik = "0.1.6"

v0.1.5

http-quik v0.1.5 (Stability & Quality Update)

This release focuses on cross-platform stability, particularly for Windows environments, and introduces a long-requested feature for developer debugging. It also hardens the CI/CD pipeline to ensure consistent quality across all supported operating systems.

New Features

Configurable TLS Verification

We’ve introduced a safe-by-default mechanism to bypass certificate verification. This is essential for developers using local man-in-the-middle proxies (e.g., mitmproxy, Charles, or Fiddler) or running integration tests in environments without a system root CA store.

• ClientBuilder::danger_accept_invalid_certs(bool): Enables or disables peer verification.
• TlsProfile::verify_peer: A new control field in the transport profile.
• Safety Note: Real browsers always verify certificates. This toggle should only be used in non-production environments.

Bug Fixes

Windows OS Stability

Resolved the CERTIFICATE_VERIFY_FAILED errors encountered on Windows GitHub Actions runners and some local Windows development environments. The boring crate (BoringSSL) occasionally struggles to locate the system root CA store on Windows; the internal test suite now utilizes the new verification toggle to ensure tests pass reliably on all kernels.

Documentation Refinement

The "Getting Started" guide has been restored to its high-level Client::new() simplicity. We've implemented a "stealth" doc-test hack that allows the documentation to remain clean for users while ensuring the underlying test runner passes on CI.

Infrastructure Improvements

Modular Quality Gate

A new, strict CI workflow (test.yml) has been implemented as a reusable quality gate. Every push to main and every Pull Request now triggers parallel validation on:

• Ubuntu Latest
• Windows Latest
• macOS Latest

The publish.yml workflow is now strictly locked behind this quality gate—if any test fails on any platform, a crates.io release is automatically blocked.

Upgrading

To upgrade, update your Cargo.toml:

[dependencies]
http-quik = "0.1.5"

v0.1.4 (Emergency Hotfix)

http-quik v0.1.4 (Emergency Hotfix)

This is an emergency patch released immediately after v0.1.3 to resolve a critical initialization failure. All users of v0.1.3 are strongly advised to upgrade to v0.1.4 immediately, as v0.1.3 will panic on startup.

What's Fixed

BoringSSL Curve Name Revert

In v0.1.3, we updated the Post-Quantum curve string to "X25519MLKEM768" to align with the finalized cryptography standard used by Chrome 134. However, the current v4 bindings of the boring crate do not yet contain the string parser update for this finalized name, resulting in a TlsBuild error and an empty ErrorStack when Client::new() is called.

• Resolution: The curve mapping has been reverted to "X25519Kyber768Draft00".
• Impact on Stealth: None. The underlying protocol ID sent over the wire remains 4588 (0x11EC), perfectly matching Chrome 134's ML-KEM network signature. The change is purely internal to satisfy the local rust compiler string parser.

Why the Rapid Release?

v0.1.3 was published to crates.io containing the string parser bug. Because crates.io is an immutable, append-only registry, we cannot edit or replace a published crate. The standard and safest procedure in the Rust ecosystem for a broken release is to immediately publish a patch version (v0.1.4). This ensures that anyone running cargo build automatically pulls down a stable, working version without experiencing the v0.1.3 crash.

To upgrade, just ensure your Cargo.toml is pulling the latest patch:

[dependencies]
http-quik = "0.1.4"

v0.1.3

http-quik v0.1.3 (Parity & Stability Patch)

This release focuses on hardening the http-quik transport engine by resolving edge-case stability issues and tightening the Chrome 134 fingerprint fidelity. The changes ensure that the OS-aware auto-detection features introduced in v0.1.2 operate flawlessly under all conditions.

What's Fixed

Post-Quantum Group Identity

Chrome 134 Stable relies on the finalized ML-KEM protocol for its post-quantum hybrid group (Group ID 0x11EC / 4588). Previously, http-quik was mapping this ID to an outdated draft name (X25519Kyber768Draft00).

• Resolution: The curve mapping has been updated to the standardized BoringSSL name (X25519MLKEM768), ensuring the ClientHello advertises the exact post-quantum footprint expected by WAFs.

ALPS Injection Stability

The raw BoringSSL FFI call used to inject Application-Layer Protocol Settings (ALPS) was previously ignoring its return value.

• Resolution: SSL_add_application_settings is now explicitly checked. If ALPS injection fails (e.g., due to memory constraints or invalid FFI state), the connection will safely abort with an Error::Connect rather than silently emitting a non-Chrome-compliant handshake.

Intelligent HTTP Port Routing

The automated redirect state machine and connection pooler previously defaulted to port 443 for all target authorities.

• Resolution: The connection pool now inspects the URL scheme, correctly defaulting to port 80 for standard http:// targets while maintaining 443 for https://.

User-Agent Patch Version Fidelity

The OS-specific Chrome 134 profiles previously used a generic .0.0.0 patch version in the User-Agent string.

• Resolution: The User-Agent strings for macOS, Windows, and Linux have been updated to carry the exact Chrome 134 Stable patch version (134.0.6998.35), reducing detectability against heuristic analyzers that check for active release channel correlations.

Getting Started

To upgrade, simply bump your Cargo.toml dependency:

[dependencies]
http-quik = "0.1.3"

No API changes are required. The Client::new() constructor continues to use intelligent OS auto-detection.

v0.1.2

http-quik v0.1.2 (Cross Platform Profile Support)

This release marks a significant milestone in our quest for perfect network identity parity. v0.1.2 introduces the Total Consistency strategy, aligning the TLS and HTTP/2 persona with the host operating system's TCP/IP stack to eliminate passive fingerprinting mismatches (p0f) used by high-tier WAFs.

What's New

Cross-Platform Chrome 134 Profiles

We have expanded the identity engine to support bit-perfect replication of Chrome 134 on all major desktop platforms:

• macOS (Apple Silicon/Intel): Uses the standard 24-byte ALPS payload and reports macOS Sequoia (15.0.0) metadata.
• Windows 11 (x86-64): Injects the extra 0x7A9A setting into the ALPS payload (30 bytes) and reports Windows kernel version 13.0.0.
• Linux (x86-64): Matches the Windows ALPS payload size and reports generic 0.0.0 version hints to match Ubuntu/Debian behavior.

Intelligent OS Auto-Detection

The Client::new() constructor now defaults to profile_auto(), which uses compile-time cfg! macros to detect the host environment. This ensures that a developer running on Linux automatically emits a Linux-native Chrome identity, preventing "Impossible Identity" flags (e.g., a Linux server claiming to be a MacBook).

Platform-Specific ALPS & Client Hints

Advanced WAFs (Akamai, Cloudflare) now cross-check the sec-ch-ua-platform-version header and the ALPS handshake length against the declared User-Agent.

• Dynamic ALPS Serialization: The TLS connector now appends OS-specific settings to the ALPS payload, ensuring the ClientHello length is bit-perfect for the target OS.
• Platform Version Injection: Every request now carries the correct sec-ch-ua-platform-version Client Hint, matching the hardware-specific constants identified in our forensic research.

Internal Refactoring

The profile management system has been overhauled to support multi-platform targeting with minimal code duplication. Internal configurations for TLS and H2 are now managed through shared base constructors, ensuring that core identity markers (cipher lists, curve preferences, pseudo-header order) remain consistent across all OS variants.

Getting Started

To leverage the new auto-detection, simply use the default constructor:

use http_quik::Client;

let client = Client::new(); // Automatically picks the right profile for your OS

To target a specific platform regardless of the host:

let client = Client::builder()
    .profile(http_quik::profile::chrome_134::profile(Platform::WindowsX64))
    .build()?;

Migration Guide

This release is backwards compatible. Update your Cargo.toml:

http-quik = "0.1.2"