Content-Encoding: gzip not preserved through Azure Front Door when caching is disabled

Question

Content-Encoding: gzip not preserved through Azure Front Door when caching is disabled

khj 0

Hello,

We are seeing an issue where pre-compressed .gz files served by NGINX are not delivered with the Content-Encoding: gzip header through Azure Front Door (AFD).

[Environment]

NGINX origin with gzip_static on;
Pre-compressed .gz files exist and serve correctly when accessed directly.
AFD configuration:
- Caching: Disabled -> after solved this problem, we'll enable
- Compression: Disabled
Domains:
- Production: static.site.co.kr (AFD)
- Origin: www.site.co.kr

[Observed Behavior]

Direct NGINX access
curl -I -H "Accept-Encoding: gzip" https://www.site.co.kr/_next/static/chunks/main.js

Content-Encoding: gzip is present.

AFD endpoint
curl -I -H "Accept-Encoding: gzip" https://static.site.co.kr/_next/static/chunks/main.js

Content-Encoding: gzip is missing.
X-Cache: CONFIG_NOCACHE indicates the request hits the origin.

It seems that there is no issue with the NGINX configuration, so why is this behavior occurring?

Anonymous

2025-09-22T06:37:28.1733333+00:00

Hi khj,

Hope you find my above comment helpful, if yes, please “up-vote” for the information provided , this can be beneficial to community members.

Kindly let us know if you have any additional questions

Thanks
khj 0 Reputation points

2025-09-23T00:30:29.6266667+00:00
Thank you for your response.

First, as you suggested, we enabled AFD’s compression feature and observed that the Content-Encoding header was set to br (Brotli) instead of gzip. Additionally, we noticed that the Content-Length header reflected the original file size, not the Brotli-compressed size.

Regarding the suggestion to avoid Chunked Transfer Encoding:

We have already confirmed that when not using the CDN, the origin correctly calculates and serves the Content-Length.

In the current setup, even though the Content-Encoding is no longer gzip, the file is being served without chunked encoding.

We have not yet tested Rules Engine changes, but without any explicit rules configured, shouldn’t AFD by default preserve and forward the origin headers as-is? If it does not, wouldn’t this behavior be considered a bug?
khj 0 Reputation points

2025-09-23T00:34:45.87+00:00

For additional context, here is our architecture and observed behavior:

Client -> AFD -> Service -> Pod [NGINX -> Next.js app]

Our goal is to copy the pre-compressed .gz files generated by Next.js to NGINX and have them cached and delivered via AFD.Previously, when NGINX was not used and AFD connected directly to the Next.js app, the responses used Transfer-Encoding: chunke d.

After introducing NGINX with gzip_static on; to serve pre-compressed files, the responses are now delivered with Content-Length instead of chunked transfer.In this situation, when integrated with AFD, the original (uncompressed) file is being delivered to the client instead of the pre-compressed .gz file. (For reference, the NGINX server contains the original .js, .br, and .gz files.)

Is there anything else we can check or configure to resolve this issue?

Thank you.
khj 0 Reputation points

2025-09-23T00:39:02.58+00:00

Due to a bug in the Q&A “Add Comment” feature, my response was delayed—apologies for that. I found that including “T ransfer-Encoding: chunked” (without a space) causes an error.

2 answers

Your answer

Anonymous

2025-09-22T06:37:28.1733333+00:00

Hi khj,

Hope you find my above comment helpful, if yes, please “up-vote” for the information provided , this can be beneficial to community members.

Kindly let us know if you have any additional questions

Thanks
khj 0 Reputation points

2025-09-23T00:30:29.6266667+00:00

Thank you for your response.

First, as you suggested, we enabled AFD’s compression feature and observed that the Content-Encoding header was set to br (Brotli) instead of gzip. Additionally, we noticed that the Content-Length header reflected the original file size, not the Brotli-compressed size.

Regarding the suggestion to avoid Chunked Transfer Encoding:

We have already confirmed that when not using the CDN, the origin correctly calculates and serves the Content-Length.

In the current setup, even though the Content-Encoding is no longer gzip, the file is being served without chunked encoding.

We have not yet tested Rules Engine changes, but without any explicit rules configured, shouldn’t AFD by default preserve and forward the origin headers as-is? If it does not, wouldn’t this behavior be considered a bug?
khj 0 Reputation points

2025-09-23T00:34:45.87+00:00

For additional context, here is our architecture and observed behavior:

Client -> AFD -> Service -> Pod [NGINX -> Next.js app]

Our goal is to copy the pre-compressed .gz files generated by Next.js to NGINX and have them cached and delivered via AFD.Previously, when NGINX was not used and AFD connected directly to the Next.js app, the responses used Transfer-Encoding: chunke d.

After introducing NGINX with gzip_static on; to serve pre-compressed files, the responses are now delivered with Content-Length instead of chunked transfer.In this situation, when integrated with AFD, the original (uncompressed) file is being delivered to the client instead of the pre-compressed .gz file. (For reference, the NGINX server contains the original .js, .br, and .gz files.)

Is there anything else we can check or configure to resolve this issue?

Thank you.
khj 0 Reputation points

2025-09-23T00:39:02.58+00:00

Due to a bug in the Q&A “Add Comment” feature, my response was delayed—apologies for that. I found that including “T ransfer-Encoding: chunked” (without a space) causes an error.

Answer 1

Hi khj,

Thank you for reaching out on Microsoft Q&A forum.

We came across some of the findings which may be the causes of error & can be verified by your end

AFD Compression Disabled: Since compression is disabled in AFD, it does not add or preserve the Content-Encoding header unless explicitly configured to do so.

Pre-compressed Files with gzip_static: NGINX serves .gz files correctly when gzip_static on is set. However, AFD may strip or fail to forward the Content-Encoding header

It happens because

The origin uses chunked transfer encoding.
The request lacks a valid Accept-Encoding header.
The file type is not eligible for compression under AFD rules

To ensure .gz files are served with the correct Content-Encoding: gzip header through AFD, we can try some of the fixes below

Enable Compression in AFD

Go to Azure Portal > Front Door > Routes.

Enable compression for the route serving static files.

Wait up to 10 minutes for propagation.

Use Rules Engine to Preserve Headers

Create a rule to preserve Accept-Encoding and forward Content-Encoding.

Ensure the rule applies to requests with .gz extensions or specific paths like /static/.

Avoid Chunked Transfer Encoding

Ensure NGINX is not using chunked encoding for .gz files.

Pre-compressed files should have a known Content-Length to avoid chunked responses.

If you find this comment helpful, please “up-vote” for the information provided , this can be beneficial to community members.

Kindly let us know if you have any additional questions

Thanks

Answer 2

Hi Khj,

Sorry for the delayed response

Please try to execute below steps

Use Rules Engine to Explicitly Preserve Headers
- As you mentioned in above comment not yet tested Rules Engine changes, though AFD should forward headers by default, explicitly configuring Rules Engine to preserve Content-Encoding and Content-Length can help avoid unexpected behavior.
Enable Caching on AFD (if feasible)
- Caching helps AFD preserve headers like Content-Encoding. If caching is disabled, AFD may strip or ignore these headers.

Hope you find my above comment helpful, if yes, please “up-vote” for the information provided ,this can be beneficial to community members.

Kindly let us know if you have any additional questions

Thanks

Share via

Content-Encoding: gzip not preserved through Azure Front Door when caching is disabled

2 answers

Your answer