tests.reproducible-builds.org: build logs sent as gzip but no content-encoding, but only sometimes?

[наб]

webmaster@ bounced, so posting here instead.

Keep me in CC please.

----- Forwarded message from наб <nabijaczleweli at nabijaczleweli.xyz> -----

Date: Tue, 14 Nov 2023 23:00:51 +0100
From: наб <nabijaczleweli at nabijaczleweli.xyz>
To: webmaster at reproducible-builds.org
Subject: Build logs sent as gzip but no content-encoding, but only sometimes?
User-Agent: NeoMutt/20231103

Hi!

On opening
  https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd-cron.html
I see garbage in the log view
(screenshot at https://101010.pl/@nabijaczleweli/111410835559109343).

In the network log I see a request for
  https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/systemd-cron_2.3.0-1.rbuild.log.gz
which returns an expectedly-gzipped answer, but with no
Content-Encoding: gzip header.

This reproduces when opening it directly.

Weirder still, this is consistent, machine-bound, and not
user-agent-derived.

For example, my firefox sees:
  GET https://tests.reproducible-builds.org/debian/rbuild/unstable/amd64/systemd-cron_2.3.0-1.rbuild.log.gz
  Accept-Encoding: gzip, deflate, br
  Accept-Language: en-GB,en;q=0.8,en-US;q=0.5,pl;q=0.3
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
  Cache-Control: no-cache
  Connection: keep-alive
  Host: tests.reproducible-builds.org
  Pragma: no-cache
  Referer: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd-cron.html
  Upgrade-Insecure-Requests: 1
  User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0
  
  Accept-Ranges: bytes
  Connection: Keep-Alive
  Content-Type: text/plain; charset=utf-8
  Date: Tue, 14 Nov 2023 21:40:14 GMT
  ETag: "7a1-6083d365a896c-gzip"
  Keep-Alive: timeout=5, max=100
  Last-Modified: Sat, 21 Oct 2023 17:20:58 GMT
  Server: Apache/2.4.57 (Debian)
  Strict-Transport-Security: max-age=15552000
  Transfer-Encoding: chunked
  Vary: Accept-Encoding
  X-Content-Encoding-Over-Network: gzip

See the random x-prefixed header, and no content-length.

But another user's firefox sees
  GET /debian/rbuild/unstable/amd64/systemd-cron_2.3.0-1.rbuild.log.gz HTTP/1.1
  Accept-Encoding: gzip, deflate, br
  Accept-Language: fr-FR,en;q=0.5
  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
  Cache-Control: no-cache
  Connection: keep-alive
  DNT: 1
  Host: tests.reproducible-builds.org
  Pragma: no-cache
  Referer: https://tests.reproducible-builds.org/debian/rb-pkg/unstable/amd64/systemd-cron.html
  Sec-Fetch-Dest: document
  Sec-Fetch-Mode: navigate
  Sec-Fetch-Site: same-origin
  Sec-Fetch-User: ?1
  Upgrade-Insecure-Requests: 1
  User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0
  
  Accept-Ranges: bytes
  Connection: Keep-Alive
  Content-Encoding: gzip, gzip
  Content-Length: 1976
  Content-Type: text/plain; charset=utf-8
  Date: Tue, 14 Nov 2023 21:41:59 GMT
  ETag: "7a1-6083d365a896c-gzip"
  Keep-Alive: timeout=5, max=100
  Last-Modified: Sat, 21 Oct 2023 17:20:58 GMT
  Server: Apache/2.4.57 (Debian)
  Strict-Transport-Security: max-age=15552000
  Vary: Accept-Encoding

See present content-length and Content-Encoding: gzip, gzip.

I tested this on four machines total:
  my own           (win32   firefox, "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Firefox/87.0"):   bad
  my brother's     (x11     firefox):                                                                                     good
  my father's      (win32   firefox, "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/119.0"): bad
  another tester's (wayland firefox, "Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/119.0"):           good
the first three are the same exit address so this is not IP-bound,
the only correlation I see with the data is that it's good when calling
from UNIX and bad when calling from Win32?

Requesting with curl/7.88.1 I see Content-Encoding: gzip.
But adding --compressed I see Content-Encoding: gzip, gzip.
Either way it's valid, but not an ideal approach.

Requesting with lynx I also see garbage.

Best,
наб



----- End forwarded message -----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.reproducible-builds.org/pipermail/rb-general/attachments/20231114/25d55d39/attachment.sig>