From 30e5a9d56c8d6aae356150cfdd5452337fe00af4 Mon Sep 17 00:00:00 2001
From: Will Thompson <wjt@endlessos.org>
Date: Tue, 14 Nov 2023 10:49:23 +0000
Subject: [PATCH] Set gzipped XML Content-Type to application/gzip

Previously, the HTTP headers for the gzipped AppStream catalog on S3
looked like this:

    HTTP/1.1 200 OK
    Accept-Ranges: bytes
    Content-Length: 216930
    Content-Type: application/xml
    Date: Tue, 14 Nov 2023 10:40:50 GMT
    ETag: "88efbfd50d380deaf29d0c8c9a9a0b6f"
    Last-Modified: Mon, 13 Nov 2023 17:27:33 GMT
    Server: AmazonS3
    x-amz-expiration: expiry-date="Thu, 14 Dec 2023 00:00:00 GMT", rule-id="nightly"
    x-amz-id-2: jJi5BW3s1nMqQxHfEbUwFM0hnzvKgeHT4bRfOekIkCqOtkQhsIiIhwLapdhvvq5WEoh/1UdT3Zo=
    x-amz-request-id: 2VNRZHTWG471BZMQ
    x-amz-server-side-encryption: AES256
    x-amz-version-id: ARqOJCikc6hWy_b7n8a4Bj068vI1FWBo

Note that the Content-Type is application/xml, and there is no
Content-Encoding header. This is incorrect because the XML is
compressed. It makes web browsers sad because they try to parse the
compressed data directly as XML.

I could see two ways to fix this:

1. Set Content-Encoding: gzip so that user agents know that they are
   getting a compressed XML document.
2. Set Content-Type to application/gzip.

I liked the idea of the former, and tested manually reuploading
https://s3-us-west-2.amazonaws.com/images-dl.endlessm.com/nightly/eos-amd64-amd64/master/base/231113-161734/eos-master-amd64-amd64.231113-161734.base.appstream.xml.gz
with --content-encoding=gzip. This has the advantage that you can browse
the file in your web browser and it renders it nicely as formatted XML.
However, if you save the file you get bad results in at least two
browsers:

1. Firefox saves the original compressed file with the incorrect name
   eos-master-amd64-amd64.231113-161734.base.appstream.xml.gz.gz (note
   the double extension, even though the file has only one layer of
   compression)
2. Chromium saves the uncompressed file as
   eos-master-amd64-amd64.231113-161734.base.appstream.xml.gz (note the
   .gz extension even though the file is uncompresssed)

So we take the second route. This way both browsers just save the
compressed file to disk.

https://phabricator.endlessm.com/T35013
---
 hooks/publish/45-publish-s3 | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/hooks/publish/45-publish-s3 b/hooks/publish/45-publish-s3
index d1a08ce5..80b289ac 100644
--- a/hooks/publish/45-publish-s3
+++ b/hooks/publish/45-publish-s3
@@ -41,6 +41,11 @@ for f in "${src}"/*; do
     *.asc)
       opts+=(--content-disposition=attachment)
       ;;
+
+    *.xml.gz)
+      # By default S3 will serve the file with Content-Type: application/xml
+      opts+=(--content-type=application/gzip)
+      ;;
   esac
   aws --region="${region}" s3 cp "${opts[@]}" "${f}" "${dest}/"
 done