Skip to content

Update dependency Downloader to v5#1344

Open
renovate[bot] wants to merge 1 commit into
dev8from
renovate/downloader-5.x
Open

Update dependency Downloader to v5#1344
renovate[bot] wants to merge 1 commit into
dev8from
renovate/downloader-5.x

Conversation

@renovate

@renovate renovate Bot commented Jun 12, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

This PR contains the following updates:

Package Change Age Confidence
Downloader 3.3.4 → 5.9.0 age confidence

Release Notes

bezzad/Downloader (Downloader)

v5.9.0: — Resolve file name & size without downloading

Downloader v5.9.0

✨ Resolve a remote file's name and size — without downloading it

This release exposes the engine's internal "what is this remote file?" logic as a clean public API, so you can preview a file's name and size (and whether it supports ranged/resumable downloads) from a single lightweight header probe — no need to start and immediately stop a real download just to learn its name. Perfect for populating a queue/grid of pending downloads.

// Just the name (resilient — falls back to the URL name on a network/server error):
string name = await RemoteFileResolver.GetFileNameAsync(url);

// Full metadata in one probe:
RemoteFileInfo info = await RemoteFileResolver.GetFileInfoAsync(url);
// info.FileName, info.FileSize (-1 if unknown), info.SupportsRange, info.Address (final, post-redirect)

Both methods accept an optional DownloadConfiguration (headers, proxy, credentials, cookies, redirect policy) and a CancellationToken.

🆕 What's new
  • RemoteFileResolver (new public static helper) — GetFileNameAsync(url) and GetFileInfoAsync(url) returning the new RemoteFileInfo record { FileName, FileSize, SupportsRange, Address }. Name resolution: Content-Disposition → URL path → GUID. Size: Content-Range → Content-Length.
  • IDownloadService.GetFileInfoAsync(url) — the same lookup on the download service, using that service's configuration, without disturbing any download in progress.
🔧 Internal
  • Filename/size/range resolution is now unified behind the canonical SocketClient.GetFileInfoAsync, consumed by both the download pipeline (DownloadService) and RemoteFileResolver — removing duplicated probing logic.
  • No behavior change to existing downloads (verified against the full test suite: 165 regression tests + new resolver tests, green on .NET 8/9/10).
📦 Install
dotnet add package Downloader --version 5.9.0

Full Changelog: bezzad/Downloader@v5.8.1...v5.9.0

v5.8.1: version 5.8.1

  • Fixed downloads failing on CDN cookie-challenge links (e.g. ArvanCloud/Cloudflare "307 to self" walls): the downloader now follows same-URL redirects — bounded by MaximumAutomaticRedirections — instead of refusing a redirect whose Location equals the current address, and clears the stale 3xx response headers before re-probing so the redirect target is actually fetched (previously the cached-headers guard short-circuited and the redirect was skipped).
  • RequestConfiguration.CookieContainer now defaults to a new CookieContainer, so session/challenge cookies issued mid-redirect are stored and replayed on the follow-up request. Set it to null to disable cookie handling entirely. (Note: this is a minor behavior change — cookies are now enabled by default within a download session.)
  • Limitations: this does not defeat JavaScript-based bot challenges (the cookie value must be computed by a browser) nor revive expired signed links — such URLs return a small HTML page with HTTP 200, so inspect the response before assuming a download bug.

v5.8.0: version 5.8.0

  • Fixed issue #​226 (AOT downloads failing with HTTP 428): the real cause was that some CDNs (e.g. BunnyCDN) return 428 as a per-client concurrency throttle for parallel chunks, and error classification relied on Exception.Source, which is empty under AOT/trimming — making the 428 fatal only in AOT. Error retry-ability is now decided by exception type and HTTP status code, deterministically across JIT and AOT.

  • Retries now use exponential backoff with full jitter instead of a fixed delay, so chunks throttled together (428/429/503) disperse on retry instead of repeating the burst.

  • 428 Precondition Required and transport-level HttpRequestExceptions (no HTTP status) are now treated as transient/retryable; permanent client errors (400/401/403/404) and 500/502 remain non-retryable.

  • Fixed issue #​231 (follow-up): in environments where a TLS-inspecting proxy/antivirus breaks concurrent HTTPS connections, parallel/range chunk downloads failed (SEC_E_DECRYPT_FAILURE, "response ended prematurely", aborted sockets) even though a single sequential connection worked. The download service now automatically falls back to a single connection and completes the download instead of failing, when a multi-connection attempt fails with a transient transport error.

v5.6.0: version 5.6.0

Full Changelog: bezzad/Downloader@v5.4.0...v5.6.0

  • Fixed issue #​225: A download cancelled under poor network conditions now ends as Stopped instead of Failed, even when a network/SSL error is thrown during cancellation.
  • Fixed issue #​230: DownloadProgressChanged no longer reports 100% immediately when the server omits Content-Length; progress stays at 0% (unknown size) until the download completes.
  • Fixed issue #​231: A response stream that ends prematurely (before the advertised size) is no longer silently treated as a completed download; it now retries/resumes and, when it cannot, fails with an IncompleteDownloadException instead of leaving an unfinished .download file.

v5.4.0: version 5.4.0

  • Fixed issue #​228: IsAotCompatible and PublishAot properties added to enable AOT compilation for .NET 8 and later.

Full Changelog: bezzad/Downloader@v5.3.0...v5.4.0

v5.3.0: version 5.3.0

What's Changed

  • Fix #​223: URI encode links by @​XanderLuciano in #​224
    • The issue was caused by incorrect URL encoding of square brackets in the download URL.
    • This has been resolved to ensure proper handling of such URLs.

New Contributors

Full Changelog: bezzad/Downloader@v5.2.0...v5.3.0

v5.2.0: version 5.2.0

Fixed issue #​220: Some servers don't like the Range header and respond with errors like 403, 404 or 503. even though the file is perfectly downloadable with a normal request (no Range header).

Full Changelog: bezzad/Downloader@v5.1.1...v5.2.0

v5.1.1: version 5.1.1

What's Changed

New Contributors

Full Changelog: bezzad/Downloader@v5.1.0...v5.1.1

v5.1.0: version 5.1.0

What's Changed

Full Changelog: bezzad/Downloader@v5.0.0...v5.1.0

v5.0.0: version 5.0.0

What's Changed

New Contributors

Full Changelog: bezzad/Downloader@v4.1.1...v5.0.0

v4.1.1: version 4.1.1

What's Changed

New Contributors

Full Changelog: bezzad/Downloader@v4.0.3...v4.1.1

v4.1.0: version 4.1.0 pre-release

What's Changed

New Contributors

Full Changelog: bezzad/Downloader@v4.0.3...v4.1.0

v4.0.3: version 4.0.3

Add MinimumChunkSize to set minimum size a single chunk should have

v4.0.2: version 4.0.2

  • Add support for .NET 8.0
  • Remove support for .NET Standard and Framework
  • Refactor code to use HttpClient instead of HttpWebRequest
  • Improve performance and reliability
  • Fix bugs and improve error handling

Configuration

📅 Schedule: (in timezone Asia/Shanghai)

  • Branch creation
    • "before 1am,before 5am,before 9am"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Enabled.

♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

@renovate renovate Bot force-pushed the renovate/downloader-5.x branch from a4848f2 to cf417c6 Compare June 16, 2026 16:59
@renovate renovate Bot force-pushed the renovate/downloader-5.x branch from cf417c6 to da12f76 Compare June 19, 2026 16:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

🤖 Automatic

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

0 participants