Nonsensical Content-Type and Content-Encoding are set for .gz archives

Checklist

I confirm that this is an issue with aurweb's code and not a user-uploaded package.
I have described the bug in complete detail in the Description section.
I have specified steps in the Reproduction section.
I have included any logs related to the bug in the Logs section.
I have included the versions which are affected in the Version(s) section.

Description

AUR web server serves various .gz files with both:

Content-Type header set to application/gzip
Content-Encoding header set to gzip

These files include, but not limit to:

The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed in the message content or the selected representation, as determined by the message semantics. The indicated media type defines both the data format and how that data is intended to be processed by a recipient, within the scope of the received message semantics, after any content codings indicated by Content-Encoding are decoded.

So the header combination used by AUR indicates the served file is a gzip archive after decompression (i.e., double gzipping), which is clearly not true.

I also came across #175 . According to it, AUR used to set Content-Type: text/plain at the time. So this is a regression from the earlier settings.

Reproduction

$ curl -I https://aur.archlinux.org/packages.gz
HTTP/1.1 200 OK
Server: nginx
Date: Mon, 24 Nov 2025 00:40:25 GMT
Content-Type: application/gzip
Content-Length: 479308
Last-Modified: Mon, 24 Nov 2025 00:38:24 GMT
Connection: keep-alive
ETag: "6923a900-7504c"
Expires: Mon, 24 Nov 2025 00:45:25 GMT
Cache-Control: max-age=300
Strict-Transport-Security: max-age=31536000; includeSubdomains; preload
Alt-Svc: h3=":443"; ma=3600
Content-Encoding: gzip
Accept-Ranges: bytes

Logs

N/A

Version(s)

aurweb v6.2.18

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information