<div dir="ltr"><div dir="ltr">On Tue, Apr 2, 2019 at 10:38 PM Ryan Schmidt <<a href="mailto:ryandesign@macports.org">ryandesign@macports.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">On Apr 2, 2019, at 23:21, Bill Cole wrote:<br>
<br>
> On 2 Apr 2019, at 23:45, Dave Allured - NOAA Affiliate wrote:<br>
> <br>
> [snip]<br>
>> <br>
>> I have never before seen this sort of fradulent behavior, silent unpacking,<br>
>> from either an http hosted data site, or the curl command.  Can anyone else<br>
>> confirm this weird download behavior from that <a href="http://facebook.net" rel="noreferrer" target="_blank">facebook.net</a> mirror?  Is<br>
>> there an alternate explanation?<br>
> <br>
> Yes.<br>
> <br>
> It sounds like the mirror may have a wrong-ish implementation of HTTP Compression. (See <a href="https://en.wikipedia.org/wiki/HTTP_compression" rel="noreferrer" target="_blank">https://en.wikipedia.org/wiki/HTTP_compression</a>) I've seen similar oddness dependent on the client request headers.<br>
> <br>
> This might be something to bring to the attention of Facebook or GNU, since that's a GNU mirror.<br>
<br>
I agree, it is a misconfiguration of the Facebook mirror server. Dave, could you please report it to them?<br><br>
Here is what the headers should look like, from <a href="http://ftp.gnu.org" rel="noreferrer" target="_blank">ftp.gnu.org</a>:<br><br>
$ curl -I <a href="https://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz" rel="noreferrer" target="_blank">https://ftp.gnu.org/gnu/groff/groff-1.22.4.tar.gz</a><br>
HTTP/1.1 200 OK<br>
Date: Wed, 03 Apr 2019 04:32:52 GMT<br>
Server: Apache/2.4.7 (Trisquel_GNU/Linux)<br>
Strict-Transport-Security: max-age=63072000<br>
Last-Modified: Sun, 23 Dec 2018 15:06:58 GMT<br>
ETag: "3f2208-57db1d4efd451"<br>
Accept-Ranges: bytes<br>
Content-Length: 4137480<br>
Content-Security-Policy: default-src 'self'; img-src 'self' <a href="https://static.fsf.org" rel="noreferrer" target="_blank">https://static.fsf.org</a> <a href="https://gnu.org" rel="noreferrer" target="_blank">https://gnu.org</a>; object-src 'none'; frame-ancestors 'none'; child-src 'self' <a href="https://static.gnu.org" rel="noreferrer" target="_blank">https://static.gnu.org</a> <a href="https://static1p.gnu.org" rel="noreferrer" target="_blank">https://static1p.gnu.org</a> <a href="https://static1p.fsf.org" rel="noreferrer" target="_blank">https://static1p.fsf.org</a><br>
X-Frame-Options: DENY<br>
X-Content-Type-Options: nosniff<br>
Content-Type: application/x-gzip<br><br>
Here are the headers Facebook's mirror is sending:<br><br>
$ curl -I <a href="http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gzHTTP/1.1" rel="noreferrer" target="_blank">http://mirror.facebook.net/gnu/groff/groff-1.22.4.tar.gz<br>
HTTP/1.1</a> 200 OK<br>
Date: Wed, 03 Apr 2019 04:33:02 GMT<br>
Server: Apache<br>
Last-Modified: Sun, 23 Dec 2018 15:06:58 GMT<br>
Accept-Ranges: bytes<br>
Content-Length: 4137480<br>
Connection: close<br>
Content-Type: application/x-gzip<br>
Content-Encoding: x-gzip<br><br>
Note the incorrect "Content-Encoding: x-gzip". That header means that the data has been gzip-compressed for transmission by the server, and the client should un-gzip it before presenting it to the user. But that is not what anybody wants here. We want the client to receive the original unmodified .tar.gz file.<br></blockquote><div><br></div><div>Bill and Ryan,</div><div><br></div><div>Thanks for the expert diagnosis.  I will report this.  Can anyone recommend optimal bug reporting channels for <a href="http://facebook.net">facebook.net</a> and GNU, without requiring a Facebook account?</div></div></div>