Conversation
Edited 4 days ago

Yeah, cool shit Caddy, just yeet the Content-Length header from random files for no reason

1
0
0

Has Content-Length: https://volpeon.ink/_astro/_category_.DTW9tSzV.css
Doesn’t have Content-Length: https://volpeon.ink/_astro/about.ArvwJ6Ft.css

You can verify both are precompressed by appending “.br”.

5
0
0

@volpeon I got the length on both of those? Did you fixed this already?

1
0
0

@lnkr Are you sure you’re looking for the Content-Length header? All browsers can figure out the length once the file is downloaded, but I specifically need the header

1
0
0
Missing media descriptions
Show content

@volpeon On my side I see content-length on all of them

1
0
0
Missing media descriptions
Show content

@forst What the heck. I’m looking at the files in Firefox and Chromium with caching disabled, and some files don’t have this header according to them.

0
0
0
Missing media descriptions
Show content

@volpeon somewhat sure. It's https://websniffer.com/ but I never caught it lying before

1
0
0

@lnkr Someone else said they’re getting the header, too. This is so weird. I was checking with Firefox and Chromium with caching disabled, and both of them say the header is absent

2
0
0

@lnkr @forst
Wait a second, I think you didn’t request any compression so Caddy serves the uncompressed file. If you add Accept-Encoding: br, the header will be gone

1
0
0

@volpeon Oh neat you use Astro. Was a pretty neat thing when i tried it.

1
0
0

@catraxx I’m very happy with the experience drgn_happy

0
0
0

@volpeon Second one sends as "transfer-encoding: chunked" for me, which means the length header can't be present with the response, the length is instead sent with each chunk.

1
0
0

@volpeon tbf I just did a quick test with httpie from the terminal and that seemingly used HTTP/1.1, so the behaviour might be different with h2

0
0
0

@volpeon @lnkr maybe it only happens on http/3?

0
0
0
Missing media descriptions
Show content

@volpeon @lnkr I think the question has to be posed differently: why does Caddy not serve a precompressed version?
On the screenshot, "live.br" is compressed on the fly and "prep.br" is the precompressed one.
Is there some sort of a rewrite rule, a regex, a wildcard that would affect this?

1
0
0

@forst @lnkr Wait, you’re saying that Caddy is compressing the file itself even though I added a precompressed one? What the fuck

1
0
0

@volpeon > You can verify both are precompressed by appending ".br".

BRAZIL MENTIONED 🇧🇷 🎉 🇧🇷 🎆

1
0
0

@volpeon @lnkr Correct, that's my current hypothesis. Content-Length would be unknown at the start of the transfer, since it's compressing on the fly.

1
0
0

@forst @lnkr

I think Caddy is serving the precompressed file after all. I ran

curl -so /dev/null "https://volpeon.ink/_astro/about.ArvwJ6Ft.css.br" -w '%{size_download}'
curl -so /dev/null "https://volpeon.ink/_astro/about.ArvwJ6Ft.css" -H "Accept-Encoding: br" -w '%{size_download}' 

and both commands yielded the same size.

1
0
0

@volpeon @lnkr Blegh, the headers from "-i" go into stdout, that's why my results are messed up.

0
0
1