On 2023-11-28 14:48:05 +0100, Simon Tournier wrote: > Hi Ludo, > > On Thu, 16 Nov 2023 at 15:40, Ludovic Courtès <l...@gnu.org> wrote: > > > That said, if you become aware of actual breakage, we can revisit this! > > The actual breakage is my own interaction with this file. :-) > > Again, it happened to me yesterday. By habits, I do: > > $ wget https://guix.gnu.org/sources.json > $ cat sources.json | jq | head > > Then, > > --8<---------------cut here---------------start------------->8--- > parse error: Invalid numeric literal at line 1, column 16 > cat: write error: Broken pipe > --8<---------------cut here---------------end--------------->8--- > > Well, we are 6 days later my last message, 12 days after your message > and more than one month after my report; and again the same mistake. > That’s mistake because it does not jump to my eyes that the file is > compressed. Yeah, I could do many on my side as change my habits, as > use curl, as have a smarter cat, as write a note, as have a better > memory, as … > > However, the simplest still appears to me to have the extension > reflecting the format of the file. Similarly as it is ’sources.json’ > and not just ’sources’.
But the problem is that the extension does reflect the format of the file. The Content-Encoding is just for transmission, it does not describe the file itself. It should be thought of as an implementation detail. Same way you do not really care if you get the file over HTTP 1.1 or HTTP 2.0. This just sound like a bug in wget, I wonder if there is a bug report and/or good reason to behave like this... Would it be possible to provide both files? Sources.json.gz would *not* set the content-encoding (and I guess content-type would be gzip?), so that one could pick between https://guix.gnu.org/sources.json and https://guix.gnu.org/sources.json.gz depending on their preference? Have a nice day, Tomas -- There are only two hard things in Computer Science: cache invalidation, naming things and off-by-one errors.
signature.asc
Description: PGP signature
