Azure Front Door strips Accept-Ranges header from origin responses

Question

Azure Front Door strips Accept-Ranges header from origin responses

Paul Mcilreavy 0

Summary

When using Azure Front Door Premium, the Accept-Ranges: bytes response header returned by our origin server is stripped before the response reaches the client. This behaviour is not explicitly documented.

Environment

Azure Front Door SKU: Premium
Origin: Azure App Service with private link
Caching & Compression: Disabled

Observed Behaviour

Direct to origin (without Front Door):

HTTP/2 206
content-type: application/octet-stream
accept-ranges: bytes
content-range: bytes 0-49/26629
...

Via Azure Front Door:

HTTP/2 206
content-type: application/octet-stream
content-range: bytes 0-49/26629
x-cache: CONFIG_NOCACHE
...

Note: accept-ranges header is missing from the Front Door response.

Testing Performed

Confirmed the origin returns Accept-Ranges: bytes when accessed directly
Confirmed the Range request functionality works correctly through Front Door (HTTP 206, correct Content-Range)

We found that Accept-Ranges is listed as a "reserved header" in the Rule set actions documentation, which states these headers "can't be modified using rules engine actions."

However:

The documentation doesn't state that Front Door actively strips this header from origin responses
The documentation doesn't explain why this header is reserved or stripped
Microsoft's own troubleshooting documentation shows example responses through Front Door that include Accept-Ranges: bytes, suggesting the behaviour may not be universal

Questions

Is Azure Front Door stripping Accept-Ranges from origin responses by design?
If yes, what is the rationale for this behaviour?
Are there any configuration options that would allow this header to pass through to clients?
Can this behaviour be documented more explicitly in the Azure Front Door documentation?

Impact

We have integration tests that validate the presence of Accept-Ranges in API responses. While we can update these tests to validate range functionality differently (by testing actual 206 responses), we would like to understand the expected behaviour for architectural documentation purposes.

Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-02-03T03:52:19.77+00:00

Hi @Paul Mcilreavy,

Azure Front Door (Standard/Premium) acts as a reverse proxy and performs internal response normalization for range request handling. While Accept‑Ranges is not a hop‑by‑hop header, it’s listed as a reserved header in Front Door rules documentation, meaning it can’t be modified or guaranteed to pass through from the origin.

There’s currently no configuration to force preservation of Accept‑Ranges. To confirm whether this is expected platform behavior for your setup, please share the details requested over Private message.
Paul Mcilreavy 0 Reputation points

2026-02-04T19:53:41.5433333+00:00

@Thanmayi Godithi Sent
Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-02-12T06:53:35.3366667+00:00

Hi @Paul Mcilreavy ,

Could you please also share the additional details requested over Private message

1 answer

Your answer

Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-02-03T03:52:19.77+00:00

Hi @Paul Mcilreavy,

Azure Front Door (Standard/Premium) acts as a reverse proxy and performs internal response normalization for range request handling. While Accept‑Ranges is not a hop‑by‑hop header, it’s listed as a reserved header in Front Door rules documentation, meaning it can’t be modified or guaranteed to pass through from the origin.

There’s currently no configuration to force preservation of Accept‑Ranges. To confirm whether this is expected platform behavior for your setup, please share the details requested over Private message.
Paul Mcilreavy 0 Reputation points

2026-02-04T19:53:41.5433333+00:00

@Thanmayi Godithi Sent
Thanmayi Godithi 11,905 Reputation points Microsoft External Staff Moderator

2026-02-12T06:53:35.3366667+00:00

Hi @Paul Mcilreavy ,

Could you please also share the additional details requested over Private message

Answer 1

Azure Front Door does not explicitly document the behavior of stripping the Accept-Ranges header from origin responses. However, it is noted that certain headers, including Accept-Ranges, are considered reserved headers and cannot be modified using rules engine actions. This implies that Azure Front Door may not allow these headers to pass through as they are, potentially as a design choice to maintain consistency or security in how headers are handled.

Is Azure Front Door stripping Accept-Ranges from origin responses by design?
Yes, it appears that Azure Front Door strips the Accept-Ranges header from origin responses, although this behavior is not explicitly documented.
If yes, what is the rationale for this behavior?
The rationale is not clearly stated in the documentation, but it may relate to the handling of reserved headers to ensure consistent behavior across different requests and responses.
Are there any configuration options that would allow this header to pass through to clients?
No, as Accept-Ranges is a reserved header, there are no configuration options available to allow it to pass through to clients.
Can this behavior be documented more explicitly in the Azure Front Door documentation?
This would be a valid request for Microsoft to consider, as clearer documentation could help users understand the expected behavior regarding reserved headers like Accept-Ranges.

This behavior impacts integration tests that validate the presence of Accept-Ranges, and while you can adjust tests to check for the functionality of range requests, understanding the expected behavior is crucial for architectural documentation.

References: