I work on OnePassApps, the team behind app.onepassapps.com. This is our own site's own HTTP transfer layer, measured on 10 November 2026 from one server with plain HTTPS requests - no browser, no cookies, no JavaScript.
Every figure below was measured with an HTTP/1.1 client that asked for each page twice: once with Accept-Encoding: identity and once with Accept-Encoding: gzip.
56 pages, one shape
Our sitemap names 56 URLs. All 56 answered 56 on 200.
Every one of the 56 identity responses carried Transfer-Encoding: chunked.
Not one of them carried a Content-Length header. The body arrives as a stream of chunks and the length is only known when the last chunk lands.
That is the whole transfer contract on the identity path: chunked, no declared length, and the same on every page.
Vary appears only when we compress
None of the 56 identity responses carried a Vary header at all.
All 56 gzip responses came back with Content-Encoding: gzip, and all 56 of them carried Vary: accept-encoding.
So the two responses for the same URL differ in their headers, not only in their bytes: the compressed one declares that it varies by Accept-Encoding, the uncompressed one declares nothing. A shared cache that stores the uncompressed copy and later hands it to a client that asked for gzip is fine. The other direction is the one that needs the header, and it is the compressed response that carries it.
The compressed responses are chunked too - 56 of 56 - so the same streaming shape holds on both paths.
They carry no Content-Length either.
One content type, one Alt-Svc line
Every response carried Content-Type: text/html; charset=utf-8 - 1 distinct value across the 56 pages.
Every response carried the same Alt-Svc line:
Alt-Svc: h3=":443"; ma=86400 That line advertises HTTP/3 on this host. I did not test it: this client asked for HTTP/1.1 and the pages answered over HTTP/1.1 every time.
What this means in a browser
A client that loads one of these pages cannot know the document's length before the body starts arriving, because no page declares one. With Transfer-Encoding: chunked the size is only known once the final zero-length chunk closes the stream.
The Vary split matters for the same reason: the site serves two different byte streams for one URL, and it marks the compressed one so a cache does not mix them up.
The other half of this question
How we answer each of the 21 values a client can put in Accept-Encoding - including the one we ignore - is a separate post:
What I did not measure
This is one server, one region and one HTTP/1.1 client on one day. I did not test HTTP/3, I did not put a shared cache in front of the host, I did not compare the API host, and I did not change anything on the site.
If you want to look for yourself, read the headers of one page twice - once with Accept-Encoding: identity, once with Accept-Encoding: gzip - and compare them:
Our home page: https://app.onepassapps.com/?utm_source=devto&utm_medium=community&utm_campaign=transfer-layer&utm_content=home-link
Our app guides: https://app.onepassapps.com/guides?utm_source=devto&utm_medium=community&utm_campaign=transfer-layer&utm_content=guides-link
