fetch timeout

Tue Jul 19 15:36:36 UTC 2022

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
>>>>> 
>>>> 
>>> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20220719/cd87c008/attachment.htm>