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.




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

Search: