Closed brianmathews closed 1 week ago
It doesn't appear that api2.sota.uk.org will respect compression requests.
For example, consider:
curl --compressed -i https://api2.sota.org.uk/api/spots/24/all
The --compressed
flag will add Accept-Encoding: gzip header
to the request.
The server responds with these headers:
HTTP/1.1 200 OK
date: Fri, 28 Jun 2024 04:21:45 GMT
content-type: application/json; charset=utf-8
server: Kestrel
transfer-encoding: chunked
followed, of course by the content.
Regrettably, it is missing the crucial Content-Encoding: gzip
header. And so, the content arrives uncompressed. The server ignored our request for compression.
Now, different case for POTA.
curl --compressed -i https://api.pota.app/spot/activator
responds with headers that include
content-encoding: br
That's great news - Brotli compression, even better than gzip.
So, I'll change the fetches to request compression. We won't get it yet for SOTA, but perhaps someday. We'll get it immediately for POTA. It won't degrade performance, and we'll be set up for compression, and even improved compression when it arrives. It'll all be handled transparently by inclusion of the Accept-encoding
header, as in
const response = await fetch(`${baseurl}/${summitCode}`, {
headers: {
'Accept-Encoding': 'gzip'
}
});
Sounds great.
Problem: when in remote areas where cell phone reception is week, it can be difficult to download the "recent spots" list from the server API. Reducing the amount of data required through compression can help.
Proposal: