Tags: jawah/urllib3.future
Tags
Release 2.14.903 (#284) 2.14.903 (2025-10-11) ===================== - Fixed an async performance issue under high task concurrency pressure. The best-effort multiplexing strategy has been significantly improved. Expect better performance in environments with many concurrent tasks.
Release 2.14.902 (#283) 2.14.902 (2025-10-05) ===================== - Fixed rare edge case where a server would close the socket after executing a request, thus misleading our implementation to retry. (#280) - Changed ``qh3`` dependency definition constraint to include the RISCV64 platform by default. - Added preemptive detection of closed socket when in TCP mode for most OSes. This avoid to send a request in a pending close socket. (#280) (#281)
❇️ ensure reliable environment for the in-place fork (#267) 2.14.900 (2025-09-19) ===================== - Fixed the determinism for the presence of this package. ``urllib3-future`` automatically takes precedence over upstream ``urllib3`` no matter the order of installation. This also fix the issue where a package manager would concurrently and blindly install both. Installing your dependencies like ``URLLIB3_NO_OVERRIDE=1 pip install niquests --no-binary urllib3-future`` will not trigger the post-install procedure (ie. ``urllib3-future`` automatically takes precedence). This will bring higher confidence of reproducibility, especially when the project relies on a ``lock`` file.
Release 2.13.907 (#263) 2.13.907 (2024-09-09) ===================== - Fixed unhandled error in HTTP/3 upgrade (TCP+TLS to QUIC) procedure that mainly affect Windows users. If your network silently filter QUIC packets or UDP is unreliable outside of your local network the upgrade procedure could raise an exception instead of silently giving up on QUIC. - Fixed the accidental leaking of ``MustRedialException`` error in the consumption of the response (including WS or SEE).
Release 2.13.906 (#255) 2.13.906 (2024-08-27) ===================== - Fixed charset transparency setter to not enforce ``charset=utf-8`` in Content-Type anymore due to incompatibilities found in widely requested servers that still don't parse HTTP headers appropriately. We saw a 3rd party report that a server rejected a request because it expected Content-Type to be exactly "X" and not "X; charset=utf-8".
PreviousNext