bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#66135: Unable to download Guile tar file


From: tomas
Subject: bug#66135: Unable to download Guile tar file
Date: Sun, 24 Sep 2023 11:14:54 +0200

On Sat, Sep 23, 2023 at 02:18:24PM +0530, ahmad khizir wrote:

Hi, Ahmad

> Operate system is redhat 7.4
> I tried to download via wget command
> I am using institute network.
> I am ok with this point that you mentioned regarding, let me check with my
> personal network and let you know.

Thank you for the details!

You may try the "-S" options to wget: this will print the HTTP
headers, which might help in identifying the problem.

If I do that, this is what I see:

 | tomas@trotzki:/tmp$ wget -S https://ftp.gnu.org/gnu/guile/guile-3.0.9.tar.gz
 | --2023-09-24 11:07:42--  https://ftp.gnu.org/gnu/guile/guile-3.0.9.tar.gz
 | Resolving ftp.gnu.org (ftp.gnu.org)... 2001:470:142:3::b, 209.51.188.20
 | Connecting to ftp.gnu.org (ftp.gnu.org)|2001:470:142:3::b|:443... connected.
 | HTTP request sent, awaiting response... 
 |   HTTP/1.1 200 OK
 |   Date: Sun, 24 Sep 2023 09:07:44 GMT
 |   Server: Apache/2.4.29 (Trisquel_GNU/Linux)
 |   Strict-Transport-Security: max-age=63072000
 |   Last-Modified: Wed, 25 Jan 2023 13:51:41 GMT
 |   ETag: "948a4f-5f316eea157b8"
 |   Accept-Ranges: bytes
 |   Content-Length: 9734735
 |   Content-Security-Policy: default-src 'self'; img-src 'self' 
https://static.fsf.org https://static.gnu.org https://gnu.org 
http://static.fsf.org http://static.gnu.org http://gnu.org; object-src 'none'; 
frame-ancestors 'none'
 |   X-Frame-Options: DENY
 |   X-Content-Type-Options: nosniff
 |   Keep-Alive: timeout=5, max=100
 |   Connection: Keep-Alive
 |   Content-Type: application/x-gzip
 | Length: 9734735 (9.3M) [application/x-gzip]
 | Saving to: ‘guile-3.0.9.tar.gz’

[then it proceeds to download the file]

I could imagine that your institution has a HTTP proxy between you and the
internet, and that this just refuses to forward HTTPS.

Alas, trying the "http://"; URL, the server insists (HSTS policy) in upgrading
that to the "https://"; one, so if my guess is right above, we'd need a "Plan B".

This would be one of the cases where blindly applying something perceived to
be secure in spite of the users leads to bad results. Sigh.

Cheers
-- 
t

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]