fetch timeout
Nils Breunese
nils at breun.nl
Tue Jul 19 16:31:28 UTC 2022
Mark Brethen <mark.brethen at gmail.com> wrote:
> it has the file name and extensions but you’re right, it’s not a compressed file.
The -O flag will write whatever body gets returned by the server into a file with the same name as the 'file name’ part of the URL, regardless of whether the HTTP status code of the response indicates success, a redirect, a client error or a server error.
You’ll see that the 273 bytes that get returned by requesting http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz are just HTML saying the the document should be requested via HTTPS:
❯ curl -O http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 273 100 273 0 0 1122 0 --:--:-- --:--:-- --:--:— 1181
❯ cat tetgen1.5.1.tar.gz
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>301 Moved Permanently</title>
</head><body>
<h1>Moved Permanently</h1>
<p>The document has moved <a href="https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz">here</a>.</p>
</body></html>
When you tell curl to follow redirects, you’ll see a second request being made and 275k getting downloaded:
❯ curl -OL http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 273 100 273 0 0 194 0 0:00:01 0:00:01 --:--:-- 195
100 275k 100 275k 0 0 75618 0 0:00:03 0:00:03 --:--:— 249k
❯ file tetgen1.5.1.tar.gz
tetgen1.5.1.tar.gz: gzip compressed data, was "tetgen1.5.1.tar", last modified: Tue Aug 21 14:40:36 2018, max compression, from Unix, original size modulo 2^32 1528832
This works fine for me on macOS 12.4 Intel.
Nils.
> I tried two different intel-based Macs with clean installs of Catalina and Big Sur (both use LibreSSL 2.8.3 btw) and was able to repeat that error. However, it works correctly on an M1 installed with Big Sur. Since this is the only host that I have run into problems with fetch, I’m not sure it’s worth the time spent.
>
>> On Jul 19, 2022, at 10:36 AM, Nils Breunese <nils at breun.nl> wrote:
>>
>> It doesn’t look like the .tar.gz file downloaded successfully, it looks like the HTML for the 301 redirect was downloaded.
>>
>> Nils.
>>
>>> Op 19 jul. 2022 om 17:20 heeft Mark Brethen <mark.brethen at gmail.com> het volgende geschreven:
>>>
>>> Understood. Using HTTP instead of HTTPS doesn’t invoke SSL/TLS. If you look at the command line output (not port), that error didn’t occur and the file downloaded successfully. I was curious what the fetch curl command looked like vs the command line?
>>>
>>> Sent from my iPhone
>>>
>>>> On Jul 19, 2022, at 9:57 AM, Nils Breunese <nils at breun.nl> wrote:
>>>>
>>>>
>>>> This depends on your definition of succeeding. The request to the HTTP URL returns a 301 redirect, which is not necessarily a ‘success’ status code. This response points to the HTTPS URL and the TLS/SSL error only occurs when requesting that URL.
>>>>
>>>> Nils.
>>>>
>>>>> Op 19 jul. 2022 om 11:58 heeft Mark Brethen <mark.brethen at gmail.com> het volgende geschreven:
>>>>>
>>>>> Please tell me why fetch still fails when /usr/bin/curl succeeds in terminal?
>>>>>
>>>>> :notice:fetch ---> Attempting to fetch tetgen1.5.1.tar.gz from http://wias-berlin.de/software/tetgen/1.5/src/
>>>>> :debug:fetch Fetching distfile failed: error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure
>>>>>
>>>>> Mark Brethen
>>>>> mark.brethen at gmail.com
>>>>>
>>>>>
>>>>>
>>>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen <mark.brethen at gmail.com> wrote:
>>>>>>
>>>>>> HTTPS uses TLS (SSL) to encrypt normal HTTP requests and responses. Use HTTP instead:
>>>>>>
>>>>>> ~ $ cd Downloads
>>>>>> Downloads $ /usr/bin/curl -vO http://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>>>>> % Total % Received % Xferd Average Speed Time Time Time Current
>>>>>> Dload Upload Total Spent Left Speed
>>>>>> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 62.141.177.111...
>>>>>> * TCP_NODELAY set
>>>>>> * Connected to wias-berlin.de (62.141.177.111) port 80 (#0)
>>>>>> > GET /software/tetgen/1.5/src/tetgen1.5.1.tar.gz HTTP/1.1
>>>>>> > Host: wias-berlin.de
>>>>>> > User-Agent: curl/7.64.1
>>>>>> > Accept: */*
>>>>>> >
>>>>>> < HTTP/1.1 301 Moved Permanently
>>>>>> < Date: Tue, 19 Jul 2022 09:37:56 GMT
>>>>>> < Server: Apache
>>>>>> < Location: https://wias-berlin.de/software/tetgen/1.5/src/tetgen1.5.1.tar.gz
>>>>>> < Content-Length: 273
>>>>>> < Content-Type: text/html; charset=iso-8859-1
>>>>>> <
>>>>>> { [273 bytes data]
>>>>>> 100 273 100 273 0 0 291 0 --:--:-- --:--:-- --:--:-- 291
>>>>>> * Connection #0 to host wias-berlin.de left intact
>>>>>> * Closing connection 0
>>>>>>
>>>>>> Mark Brethen
>>>>>> mark.brethen at gmail.com
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen <mark.brethen at gmail.com> wrote:
>>>>>>>
>>>>>>> It’s more likely that curl 7.64.1 succeeds to connect while openssl 2.8.3 fails with alert number 40 (see below). It might be related to the server which has several virtual hosts. openssl 3.0.5 (mp) seems to handle it fine compared to openssl 2.8.3.
>>>>>>>
>>>>>>> Downloads $ openssl version
>>>>>>> OpenSSL 3.0.5 5 Jul 2022 (Library: OpenSSL 3.0.5 5 Jul 2022)
>>>>>>>
>>>>>>> Downloads $ openssl s_client -connect wias-berlin.de:443 -servername wias-berlin.de
>>>>>>> CONNECTED(00000005)
>>>>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>>>>> verify return:1
>>>>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>>>>>> verify return:1
>>>>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>>>>> verify return:1
>>>>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN = www.wias-berlin.de
>>>>>>> verify return:1
>>>>>>>
>>>>>>> Downloads $ /usr/bin/openssl version
>>>>>>> LibreSSL 2.8.3
>>>>>>>
>>>>>>> Downloads $ /usr/bin/openssl s_client -connect wias-berlin.de:443 -servername wias-berlin.de
>>>>>>> CONNECTED(00000005)
>>>>>>> depth=3 C = DE, O = T-Systems Enterprise Services GmbH, OU = T-Systems Trust Center, CN = T-TeleSec GlobalRoot Class 2
>>>>>>> verify return:1
>>>>>>> depth=2 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Certification Authority 2
>>>>>>> verify return:1
>>>>>>> depth=1 C = DE, O = Verein zur Foerderung eines Deutschen Forschungsnetzes e. V., OU = DFN-PKI, CN = DFN-Verein Global Issuing CA
>>>>>>> verify return:1
>>>>>>> depth=0 C = DE, ST = Berlin, L = Berlin, O = Forschungsverbund Berlin e.V., OU = Weierstrass-Institut f. Angewandte Analysis u. Stochastik (WIAS), OU = RT, CN = www.wias-berlin.de
>>>>>>> verify return:1
>>>>>>> 4381900460:error:14008410:SSL routines:CONNECT_CR_KEY_EXCH:sslv3 alert handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:1200:SSL alert number 40
>>>>>>> 4381900460:error:140080E5:SSL routines:CONNECT_CR_KEY_EXCH:ssl handshake failure:/System/Volumes/Data/SWE/macOS/BuildRoots/880a0f6e74/Library/Caches/com.apple.xbs/Sources/libressl/libressl-56.60.4/libressl-2.8/ssl/ssl_pkt.c:585:
>>>>>>> ---
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Mark
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> On Jul 18, 2022, at 8:11 AM, Mark Brethen <mark.brethen at gmail.com> wrote:
>>>>>>>>
>>>>>>>> wias-berlin.de
>>>>>>>
>>>>>>
>>>>>
>
More information about the macports-dev
mailing list