Mark Brethen <mark.bret...@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 <n...@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.bret...@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 <n...@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.bret...@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.bret...@gmail.com >>>>> >>>>> >>>>> >>>>>> On Jul 19, 2022, at 4:46 AM, Mark Brethen <mark.bret...@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.bret...@gmail.com >>>>>> >>>>>> >>>>>> >>>>>>> On Jul 18, 2022, at 11:56 AM, Mark Brethen <mark.bret...@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.bret...@gmail.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>> wias-berlin.de >>>>>>> >>>>>> >>>>> >
