<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Thu, Apr 4, 2019 at 11:27 AM Bill Cole <<a href="mailto:macportsusers-20171215@billmail.scconsult.com">macportsusers-20171215@billmail.scconsult.com</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 4 Apr 2019, at 12:45, Dave Allured - NOAA Affiliate via <br>
macports-users wrote:<br>
<br>
> On Wed, Apr 3, 2019 at 11:11 PM Mojca Miklavec <<a href="mailto:mojca@macports.org" target="_blank">mojca@macports.org</a>> <br>
> wrote:<br>
><br>
>> On Thu, 4 Apr 2019 at 06:34, <<a href="mailto:macports@raf.org" target="_blank">macports@raf.org</a>> wrote:<br>
>>><br>
>>> it's wierd. i'm seeing the same Content-Encoding header<br>
>>> but curl doesn't un-gzip the download for me. neither<br>
>>> /usr/bin/curl (7.43.0) nor /opt/local/bin/curl (7.64.1).<br>
>>> neither does wget. i wonder what the difference is.<br>
>><br>
>> Probably not relevant for this, but some time ago I also had the same<br>
>> issue of auto-extracting tarballs; I thought it was the firewall <br>
>> (some<br>
>> content / antivirus checking software there) as I only had this<br>
>> problem in my office; everywhere else it worked as expected.<br>
>><br>
>> Mojca<br>
>><br>
><br>
> That *is* relevant.  My Mac is behind an institutional firewall, so <br>
> this<br>
> might be aggravating the problem.  Also I am not able to duplicate the<br>
> headers as Ryan showed using curl -I, not with the <a href="http://facebook.net" rel="noreferrer" target="_blank">facebook.net</a> URL.  <br>
> I<br>
> will ask our network admins about this.<br>
><br>
> It sounds like Raf and Mojca are reporting correct, compressed <br>
> downloads<br>
> from this site, and I am the only one so far that has actually <br>
> reported<br>
> incorrect, uncompressed downloads.  (I checked; my mac gets the same<br>
> malfunction with all .tar.gz files from <a href="http://facebook.net" rel="noreferrer" target="_blank">facebook.net</a>, not just the <br>
> groff<br>
> file.)  Does anyone else here get the incorrect, uncompressed result, <br>
> which<br>
> is 17 Mb rather than the expected 4 Mb?<br>
<br>
Nope.<br>
<br>
Does ~/.curlrc exist? If so, what's in it?<br>
I can reproduce the behavior with the "--compress" option on the command <br>
line or in the .curlrc file.<br></blockquote><div><br></div><div>Bill, thanks for these hints.  I do not have any ~/.curlrc.  On my mac, the behavior was not affected in any way by --compress, --compressed, --compressed-ssh, or --tr-encoding (two different curl versions).  This was true for both the misbehaving <a href="http://mirror.facebook.net">mirror.facebook.net</a>, as well as for a normal mirror site.  It was as if our gateway was disabling or bypassing all of these command line options, regardless of the target website.</div></div></div></div></div>