CloudFront is dropping Content-Length (might relate to Content-Encoding)

Question

while **s3** url - https://test-content-length.s3.amazonaws.com/sample.pdf **has Content-Length response header**
its **CloudFront** url - https://d3je9z6q60prpt.cloudfront.net/sample.pdf **doesn't have Content-Length**

* why is it? 
* is there a way to set CloudFront distribution to return Content-Length? 
* if so, please provide details
* if not, please explain how we can solve it

Thanks,
Michal

additional edit after the first response - curl request should imitate the way a browser request this url with Accept-Encoding: gzip, deflate, br

```
curl https://d3je9z6q60prpt.cloudfront.net/sample.pdf -I -H "Accept-Encoding: gzip, deflate, br"
```

Answer

Both responses include Content-Length, do you and I have different ways of checking?

**S3**
```
curl https://test-content-length.s3.amazonaws.com/sample.pdf -I
HTTP/1.1 200 OK
x-amz-id-2: R8XPq5+/2riIlM+GLUJVrWepJ5yYL8xWZSQrqTLZ70gnIHiqxqllgB9LfX6kmAlNtDz2chSH7Mc=
x-amz-request-id: 479BMV3A70J0F17B
Date: Mon, 03 Jul 2023 13:28:57 GMT
Last-Modified: Mon, 03 Jul 2023 12:53:14 GMT
ETag: "4b41a3475132bd861b30a878e30aa56a"
x-amz-server-side-encryption: AES256
Accept-Ranges: bytes
Content-Type: application/pdf
Server: AmazonS3
Content-Length: 3028
```
**CloudFront**
```
curl https://d3je9z6q60prpt.cloudfront.net/sample.pdf -I
HTTP/2 200
content-type: application/pdf
content-length: 3028
date: Mon, 03 Jul 2023 13:29:20 GMT
last-modified: Mon, 03 Jul 2023 12:53:14 GMT
etag: "4b41a3475132bd861b30a878e30aa56a"
x-amz-server-side-encryption: AES256
accept-ranges: bytes
server: AmazonS3
vary: Accept-Encoding
x-cache: Miss from cloudfront
via: 1.1 9bf92639763e2dc7c1ea8eb4814a239e.cloudfront.net (CloudFront)
x-amz-cf-pop: NRT20-C1
x-amz-cf-id: FNExZ36GtBm1afRWJJUY0Fax8q0Tda6JTJW5kvRQTzeDD3UQsxVlwg==
```

Answer

Updates: I contacted AWS and according to them this is the current behavior

**using compression instead of using Content-Length header, we add the "Transfer-Encoding" header with the value as "Chunked"**

`
Because compression is happening on the fly, Cloudfront is unable to get the final length of the compressed content. Adding a Content-Length header would require storing the full response and calculating its length and then returning it back to the client which is not possible since it would cause latency if the original response itself was large. That is why when using compression instead of using Content-Length header, we add the "Transfer-Encoding" header with the value as "Chunked". This indicates that the data is sent in a series of chunks. If you are using HTTP/1.1, the Content-Length header is omitted and the "Transfer-Encoding: Chunked" is added instead, in the response headers. However, if you are using HTTP/2 for compressed contented, neither "Content-Length" nor "Transfer-Encoding" is used. HTTP/2 uses its own mechanism to convey to the client that the response is chunked.
`

I suggested them to provide settings or either not compressing file types or defines file types that requires Content-Length - they opened internal ticket

`
Thank you for your suggestions. I have gone ahead and made a feature request to our internal Cloudfront team and whilst I do not have an ETA to share, updates are often posted in the Cloudfront Console, Blog and AWS Announcement pages. You can track new features and updates for AWS services at https://aws.amazon.com/new/
`

Answer

Content-Encoding is also missing and it's causing some problems with audit tools that review the webs and detect the content as not compressed.

CloudFront is dropping Content-Length (might relate to Content-Encoding)

Relevant content