5.3.1

Patch release: cross-origin redirects no longer receive credential headers.

Fixed

• Credential headers are no longer replayed onto cross-origin redirect targets (#126 follow-up). The redirect handler shared by the persistent streaming reader and both size probes reapplied every caller-supplied header, including Authorization, to whatever URL a redirect landed on. A media server 307-redirecting to a cross-origin presigned object-storage URL (query-string authentication) then rejected the request with 400 because two authentication mechanisms collided. With every probe blind, fileSize resolved to -1, the reader degraded to forward-only streaming mode, and a moov-at-end MP4 failed against a target that is fully byte-seekable when requested normally.

  The new per-header policy (RedirectHeaderPolicy, shared by all three redirect delegates):

  • Range and non-credential extra headers still survive cross-host redirects, so header-dependent proxies (the #8 AIOStreams class) keep working unchanged.
  • Credential headers (Authorization, Proxy-Authorization, Cookie, X-Emby-Token, X-Emby-Authorization, X-MediaBrowser-Token) are replayed only to a same-host target with no TLS downgrade. Ports may differ only across an http to https upgrade (Emby-style 8096 to 8920); within the same scheme a port change counts as a different origin.
  • Credential headers URLSession itself carries over on a redirect are scrubbed when the target does not qualify.

  Beyond restoring direct play on such sources, this stops disclosing the media-server token to arbitrary redirect targets.

  Thanks to @YangHanqing for the precise diagnosis, including the A/B measurement (Authorization replayed: 17.1 s startup, forced software path, playback error; omitted: 3.2 s, native VideoToolbox direct play) that pinned the failure to the redirect header replay.

Compatibility

No API changes. Hosts that rely on redirects to a different host that itself requires the same Authorization header (an unusual split-auth deployment) would previously work by accident and will now see the credential withheld; such setups should front the target behind the same host or use URL-carried auth.