How to Stream Large Files with ASP.NET Core and Range Requests

Large media assets place unnecessary pressure on an application server when a client requests a multi-gigabyte recording, archive, or software package. HTTP range requests solve this by letting the client request only the bytes it needs. ASP.NET Core can expose that capability with little custom parsing, while browsers use it automatically for media playback and seeking. The practical goal is to deliver the smallest useful representation and make seeking feel immediate rather than pushing a complete file through every network hop.

A browser playing an MP4 will often send Range: bytes=... when a viewer jumps to another part of the recording. The server answers with 206 Partial Content, identifies the selected interval with Content-Range, and sends only that interval. A request without a range still receives the full entity, usually with 200 OK. Range processing is separate from chunked transfer encoding, so it also works over HTTP/2 without relying on chunked framing.

Developers attending technical events such as the C# Corner Annual Conference can compare these transport-level techniques with broader topics in C#, Azure, data, and DevOps. In Australia, the design is shaped by large distances between cities, a mixed enterprise cloud market, and teams spread from Sydney and Melbourne to Brisbane, Perth, and regional sites. Good range handling turns those conditions into an architectural advantage rather than a reason to serve oversized payloads from one origin.

Understanding HTTP range requests

Range is an HTTP request header whose value identifies a byte interval in the target representation. The common form is bytes=0-1048575, which requests the first 1,048,576 bytes. An open-ended value such as bytes=1048576- asks for everything from that offset, while bytes=-500 requests the final 500 bytes. Byte offsets describe the stored file, not pixels, frames, or compressed video packets. A media player therefore asks for storage boundaries, and the server remains responsible for decoding those bytes as the appropriate media type.

For example, a client might issue:

GET /media/interview.mp4 HTTP/1.1
Range: bytes=0-1048575

The matching response can look like:

HTTP/1.1 206 Partial Content
Content-Range: bytes 0-1048575/734003200
Content-Length: 1048576
Accept-Ranges: bytes
Content-Type: video/mp4

Content-Range ties the local interval to the full file length, while Accept-Ranges advertises that the server supports byte selection.

Not every request should become a partial response. If no Range header is present, return the normal 200 OK representation. If the requested start lies beyond the file length, return 416 Range Not Satisfiable and include Content-Range: bytes */734003200. Multi-range requests are an edge case: many clients ask for one interval at a time, and a server may decline or coalesce multiple ranges. Avoid promising multipart responses until the endpoint and CDN have been tested with that exact request shape.

Building a safe ASP.NET Core endpoint

ASP.NET Core provides range handling for physical files, so an application does not need to parse offsets, seek a stream, or calculate response lengths by hand. PhysicalFileResult and the path-based Results.File helper support partial delivery when enableRangeProcessing is enabled. For public assets in wwwroot, Static File Middleware is often simpler and already understands range headers. A custom endpoint becomes useful when access decisions, licence checks, audit rules, or per-user delivery policies must run before the file is served.

var mediaRoot = Path.GetFullPath(Path.Combine(
    builder.Environment.ContentRootPath, "media"));

app.MapGet("/media/{fileName}", (string fileName) =>
{
    var filePath = Path.GetFullPath(Path.Combine(mediaRoot, fileName));

    var comparison = OperatingSystem.IsWindows()
        ? StringComparison.OrdinalIgnoreCase
        : StringComparison.Ordinal;

    var rootPrefix = mediaRoot.TrimEnd(Path.DirectorySeparatorChar) +
        Path.DirectorySeparatorChar;

    if (!filePath.StartsWith(rootPrefix, comparison) ||
        !System.IO.File.Exists(filePath))
    {
        return Results.NotFound();
    }

    var contentType = Path.GetExtension(filePath).ToLowerInvariant() switch
    {
        ".mp4" => "video/mp4",
        ".webm" => "video/webm",
        ".mp3" => "audio/mpeg",
        ".wav" => "audio/wav",
        _ => "application/octet-stream"
    };

    return Results.File(
        filePath,
        contentType,
        enableRangeProcessing: true);
});

This handler keeps file selection inside a known media directory and rejects paths that escape it after canonicalisation. Returning Results.File lets the framework stream from disk instead of materialising the object in memory. A production version should also resolve or prohibit symbolic links, avoid exposing internal filenames, and map an opaque media identifier to a trusted record when possible. Never pass an arbitrary user-supplied path to Results.File.

Authentication can be applied with standard authorisation policies before the handler runs. For private media, issue short-lived signed URLs or tokens that bind access to a specific object and expiry. Apply the same authorisation decision to every range: fetching bytes 100–199 should not bypass a rule that would block the complete file. Keep unauthorised responses indistinguishable where appropriate, and redact sensitive tokens from logs and telemetry.

Status codes, headers, and browser behaviour

Status codes form part of the delivery contract. 200 OK means the client received the full representation, 206 Partial Content means it received the requested interval, and 416 Range Not Satisfiable means the interval cannot be served. A 404 Not Found remains preferable to revealing whether a protected object exists. Do not return 206 with an incorrect Content-Length: clients use these values to decide whether playback can continue, and a mismatch can produce a stalled player or failed seek.

Cache validators make seeking efficient without retransmitting unchanged bytes. An ETag or Last-Modified value lets the client send If-Range; when the representation has not changed, the server can return the requested interval, while a changed entity causes the range condition to be ignored and a full response to be returned. Give fingerprinted, immutable assets long-lived Cache-Control directives, and use private caching rules for authorised content. At a CDN, verify that range responses, validators, and query-string cache keys behave as intended instead of assuming origin behaviour is preserved unchanged.

Cross-origin delivery adds another layer. If browser code on another origin needs to inspect the response, expose Content-Range, Content-Length, and Accept-Ranges through the CORS policy; add Content-Disposition when the filename matters. Avoid gzip for MP4, WebM, archives, and other already-compressed payloads because compression changes byte offsets and wastes CPU. A HEAD request should return the same entity metadata as GET without a body, which helps players and CDNs assess the object before requesting media.

Delivering files across Australia

Australian geography makes origin placement and edge caching central to a smooth experience. A visitor in Perth can face materially different latency from a viewer in Sydney or Melbourne, and regional fixed-wireless or mobile connections may be less consistent than metropolitan broadband. Place frequently requested objects in a CDN with edge presence in major cities, including Perth where the chosen provider supports it, and use an Australian origin when data residency or latency requires it. A web application in Sydney can issue redirects or signed URLs to Azure Blob Storage, Azure Front Door, AWS, or Google Cloud instead of pushing every byte through the app server.

The Australian market is not Azure-only: many .NET-heavy organisations use Microsoft identity and Azure, while AWS and Google Cloud also serve substantial enterprise workloads. Design the endpoint around portable HTTP behaviour, then choose the storage and CDN products that fit existing contracts and team skills. Compare request charges, egress, storage replication, and support coverage because a range request can reduce transferred bytes while still creating multiple billable origin or edge requests. For regulated data, assess Australian Privacy Act obligations and Australian Signals Directorate guidance where relevant; keep personal information in approved locations and use encryption, short-lived access, and auditable retrieval.

Local work patterns reinforce the value of partial retrieval. Teams often collaborate across eastern capitals while field staff, mine sites, and regional education providers operate far from a metropolitan data centre. In Australian technical discussions, “stream it” usually means progressive delivery, whereas “download it” signals that the whole file is wanted. Supporting the first request with a small range and the second with a normal entity lets one endpoint serve both intentions without forcing large transfers over constrained links.

Practical recommendations for production delivery

A production implementation is easier to trust when the same file is exercised through several access paths. Before releasing the endpoint, verify its behaviour against the application’s real clients and CDN configuration.

• Serve public, immutable assets through Static File Middleware or object storage, with fingerprinted URLs and long-lived caching, rather than occupying application workers for every byte.
• Return correct Content-Type, Content-Length, Content-Range, Accept-Ranges, ETag, and Last-Modified values; reject unsatisfiable ranges with 416.
• Keep file paths server-controlled, authorise the complete object, and bind every range request to the same access decision.
• Test ordinary downloads, seeking, repeated ranges, invalid offsets, HEAD requests, expired credentials, and clients that omit the Range header.
• Monitor range-request success, origin and edge latency, transferred bytes, cache hit rate, egress cost, and playback failures rather than relying only on request counts.

Range handling works best as one part of an ordinary HTTP delivery design. ASP.NET Core supplies the mechanics, but correct status codes, safe path resolution, cache policy, and observability determine the user experience. The result is responsive playback across Australian networks, consistent access to protected files, and origin infrastructure that handles only the bytes clients actually request.