Resource not compressed when fetched using Http.get

Learn
1

I have an Elm app that loads a JSON list of stuff and displays it. I have recently noticed that the loading got much slower, so I wondered what the problem could be. After some investigation in Safari developer tools I realized the download is not using compression, whereas a standalone display in the browser does. I am using plain Http.get to download the JSON:

downloadArticles : Cmd Msg
downloadArticles =
    Http.get
        { url = "https://www.ohlasy.info/api/articles.js"
        , expect = Http.expectString ParseArticles
        }

Am I doing something wrong?

2

Can you tell whether the headers in the request are different in the request Elm makes vs the request that correctly gets a compressed response? (If so, you could use Http.request instead of Http.get to add the appropriate headers as a workaround.)

1 Like
3

Nice idea, thank you. There’s just the User Agent header and Accept. For the working, compressed version the Accept header looks like this:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

The non-compressed request sets Accept to */*. So that doesn’t look interesting with respect to response compression – or does it? Could the problem be that the working, compressed version is an ordinary display in the browser and Http.get is an XHR request?

4

Hm, it started working now, weird. The only thing I have changed was updating to elm/http 2.0.0 since I have noticed the package was out of date. So it was either some glitch or (more likely) the update. Sorry for the noise!

5

Isn’t it the Accept-Encoding header? rather than Accept

1 Like
6

Yeah, I think there is some confusion around terms here.

Accept header is what content types the client wants to get back from the server (JSON, HTML, etc).
Accept-Encoding is the format that the content is encoded with (usually what compression algorithm it is compressed with).

The Accept-Encoding header is controlled by the browser, and attempting to set it on a request will result in a Refused to set unsafe header "Accept-Encoding" error on the client.

The first thing to check is making sure gzip is enabled on the server hosting these assets, gzip can be on for some content types but not others as well.

If these assets are served through a caching layer, like a CDN, you may run into situations where different versions of a file are served up unexpectedly due to the headers that are being used for the cache key. For instance if it considers the Accept header when deciding which version of a cached file to return, you could get different results with different headers. This talks a bit more about that situation: https://blog.stackpath.com/accept-encoding-vary-important/

1 Like
7

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.