Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is what the Accept-Encoding header is for.

I ran this HTTP request (in IntelliJ's HTTP client):

    GET https://jakearchibald.com/2023/against-self-closing-tags-in-html/
    Accept: text/html
    Accept-Encoding: gzip
And got back this response:

    HTTP/1.1 200 OK
    Date: Thu, 06 Jul 2023 14:39:00 GMT
    Content-Type: text/html; charset=UTF-8
    ...
    Content-Encoding: gzip
I tried it again with "deflate" and "identity", and in each case got back a plaintext response with no compression.

Maybe your browser doesn't send the Accept-Encoding header at all? In that case, according to the spec, "If no Accept-Encoding header field is in the request, any content coding is considered acceptable by the user agent."[0] If your browser doesn't send Accept-Encoding but still relies on a specific encoding or no encoding, it's your browser that is broken, not the server.

[0] https://www.rfc-editor.org/rfc/rfc9110#field.accept-encoding



At the time I made that comment, my browser was sending "Accept-Encoding: gzip, deflate". I got "Content-Encoding: br" back.

I just re-checked, though, and it loads fine in my browser now; I'm getting "Content-Encoding: gzip" back. Perhaps it was a server misconfiguration?


Possibly? They're using Cloudflare CDN, so it's not like it's a custom niche job.

It's not a timing thing, I saw your post the minute it went up and tested it right away.


Huh.

I will say that it was weird because at the time, I also tested loading the main page and a couple other blog posts on the site. Only this particular one, however, was an issue, and I figured it was probably an anti-hug mechanism where the site forces Brotli compression for a resource if that resource was frequently being accessed over a certain threshold.

I honestly have no idea though. It's weird. What I do know is that it wasn't just my browser - I was having a similar issue with wget, where it got back encoded Brotli data without having asked for it. (wget does support Brotli, but doesn't send an Accept-Encoding header or, it seems, decode the output unless told to specifically.) But, again, I'm not having the issue now, and as you say, not sending an Accept-Encoding header means anything goes so it's not really the same thing as how it worked on my browser.


Send no Accept-Encoding leads to an uncompessed response, so I don't think that is the parents issue.


Hmm, I got br when I dropped the header (see below). Either way, the server's behavior matches the spec, so there's something up with the client if they're seeing nonsense.

Request:

    GET https://jakearchibald.com/2023/against-self-closing-tags-in-html/
    Accept: text/html
Response:

    HTTP/1.1 200 OK
    Date: Thu, 06 Jul 2023 17:01:20 GMT
    Content-Type: text/html; charset=UTF-8
    ...
    Content-Encoding: br


Huh.

  curl https://jakearchibald.com/2023/against-self-closing-tags-in-html/ -v > /dev/null
gave me:

  > GET /2023/against-self-closing-tags-in-html/ HTTP/2
  > Host: jakearchibald.com
  > user-agent: curl/7.88.1
  > accept: */*
  > 
  < HTTP/2 200 
  < date: Thu, 06 Jul 2023 17:21:26 GMT
  < content-type: text/html; charset=UTF-8
  < access-control-allow-origin: *
  < cache-control: max-age=180
  < strict-transport-security: max-age=31536000
  < vary: Accept-Encoding
  < x-frame-options: DENY
  < x-nf-request-id: 01H4P36X7YHZQC8TEVXAN3AXX7
  < cf-cache-status: REVALIDATED
  < report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=fcIbfNmFx0qEwjSBofViCahSkzz4vTSZ5tyXZpF7TEvuRsGJ8mkqo5PCX7pG1jYCJuV4a9bA%2FlJ4BA4F0dY2mLORDO%2F67OPRKT0TOaW5by%2FoUyjVIOI1Bh9pplcDXymLbgSp9Q%3D%3D"}],"group":"cf-nel","max_age":604800}
  < nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
  < server: cloudflare
  < cf-ray: 7e29862aaea23a8a-FRA
  < alt-svc: h3=":443"; ma=86400
(I also tried over http1.1, gave me the same result)


Ah, you know what, IntelliJ automatically adds an Accept-Encoding header if I leave it off, I didn't realize that until just now. Curl is a better test because it doesn't try to be clever.

There's still definitely something wrong with OP's client, because the server does exactly what it's supposed to.




Consider applying for YC's Winter 2026 batch! Applications are open till Nov 10

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: