Can Bamboo interpret an HTTP 400 Bad request as a failure - bamboo

We are using CURL to make an external API request to one of our applications. If that request comes back with something other than a 200 we want bamboo to fail the "build". Currently, it is passing. Also, the message in the response has the word "error" in it. My hope was that Bamboo was parsing the script outcome and reporting pass or fail based on the response. We could possibly leverage postman and have it run a test if bamboo is unable to interpret the actual request.
Here is the log:
simple 01-Mar-2018 08:43:29 Build Comcept.Net - Test Web API - Default Job #3 (COM-TWA-JOB1-3) started building on agent Default Agent
simple 01-Mar-2018 08:43:29
simple 01-Mar-2018 08:43:29 Build working directory is D:\bamboo-home\xml-data\build-dir\COM-TWA-JOB1
simple 01-Mar-2018 08:43:29 Executing build Comcept.Net - Test Web API - Default Job #3 (COM-TWA-JOB1-3)
simple 01-Mar-2018 08:43:29 Running pre-build action: VCS Version Collector
simple 01-Mar-2018 08:43:29 Starting task 'Test Curl' of type 'com.atlassian.bamboo.plugins.scripttask:task.builder.script'
command 01-Mar-2018 08:43:29 Beginning to execute external process for build 'Comcept.Net - Test Web API - Default Job #3 (COM-TWA-JOB1-3)'\n ... running command line: \nD:\bamboo-home\temp\COM-TWA-JOB1-3-ScriptBuildTask-4890011895813643563.bat\n ... in: D:\bamboo-home\xml-data\build-dir\COM-TWA-JOB1\n ... using extra environment variables: \nbamboo_capability_system_builder_msbuild_MSBuild_v2_0__32bit_=C:\Windows\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe\nbamboo_capability_system_builder_msbuild_MSBuild_v14_0__64bit_=C:\Program Files (x86)\MSBuild\14.0\bin\amd64\MSBuild.exe\nbamboo_capability_system_builder_msbuild_MSBuild_2017=C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe\nbamboo_resultsUrl=http://britten.hq.comcept.net:8085/browse/COM-TWA-JOB1-3\nbamboo_capability_system_builder_msbuild_MSBuild_v4_0__32bit_=C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe\nbamboo_capability_system_builder_msbuild_MSBuild_v3_5__32bit_=C:\Windows\Microsoft.NET\Framework\v3.5\MSBuild.exe\nbamboo_dependenciesDisabled=false\nbamboo_buildFailed=false\nbamboo_build_working_directory=D:\bamboo-home\xml-data\build-dir\COM-TWA-JOB1\nbamboo_buildKey=COM-TWA-JOB1\nbamboo_shortPlanName=Test Web API\nbamboo_capability_system_builder_msbuild_MSBuild_v3_5__64bit_=C:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe\nbamboo_agentWorkingDirectory=D:\bamboo-home\xml-data\build-dir\nbamboo_buildNumber=3\nbamboo_shortJobName=Default Job\nbamboo_buildResultsUrl=http://britten.hq.comcept.net:8085/browse/COM-TWA-JOB1-3\nbamboo_capability_system_builder_msbuild_MSBuild_v2_0__64bit_=C:\Windows\Microsoft.NET\Framework64\v2.0.50727\MSBuild.exe\nbamboo_capability_system_builder_node_Node_exe=C:\Program Files\nodejs\node.exe\nbamboo_capability_system_jdk_JDK_1_8_0_151__JRE_=C:\Program Files\Java\SE851\nbamboo_capability_system_jdk_JDK=C:\Program Files\Java\SE851\nbamboo_agentId=196609\nbamboo_planName=Comcept.Net - Test Web API\nbamboo_capability_system_builder_devenv_Visual_Studio_2010=C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\nbamboo_plan_storageTag=plan-3309569\nbamboo_shortPlanKey=TWA\nbamboo_ManualBuildTriggerReason_userName=ddivita\nbamboo_shortJobKey=JOB1\nbamboo_capability_system_builder_msbuild_MSBuild_v14_0__32bit_=C:\Program Files (x86)\MSBuild\14.0\bin\MSBuild.exe\nbamboo_capability_system_builder_msbuild_MSBuild_v4_0__64bit_=C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe\nbamboo_buildTimeStamp=2018-03-01T08:43:29.444-05:00\nbamboo_working_directory=D:\bamboo-home\xml-data\build-dir\COM-TWA-JOB1\nbamboo_planKey=COM-TWA\nbamboo_capability_system_jdk_JDK_1_8=C:\Program Files\Java\SE851\nbamboo_buildResultKey=COM-TWA-JOB1-3\nbamboo_buildPlanName=Comcept.Net - Test Web API - Default Job\n
build 01-Mar-2018 08:43:29
build 01-Mar-2018 08:43:29 D:\bamboo-home\xml-data\build-dir\COM-TWA-JOB1>c:\curl\curl.exe -v https://api-qa.comcept.net/token
error 01-Mar-2018 08:43:29 % Total % Received % Xferd Average Speed Time Time Time Current
error 01-Mar-2018 08:43:29 Dload Upload Total Spent Left Speed
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 192.168.0.220...
error 01-Mar-2018 08:43:29 * TCP_NODELAY set
error 01-Mar-2018 08:43:29 * Connected to api-qa.comcept.net (192.168.0.220) port 443 (#0)
error 01-Mar-2018 08:43:29 * ALPN, offering h2
error 01-Mar-2018 08:43:29 * ALPN, offering http/1.1
error 01-Mar-2018 08:43:29 * Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
error 01-Mar-2018 08:43:29 * successfully set certificate verify locations:
error 01-Mar-2018 08:43:29 * CAfile: c:\curl\ca-bundle.crt
error 01-Mar-2018 08:43:29 CApath: none
error 01-Mar-2018 08:43:29 * TLSv1.2 (OUT), TLS header, Certificate Status (22):
error 01-Mar-2018 08:43:29 } [5 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
error 01-Mar-2018 08:43:29 } [512 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS handshake, Server hello (2):
error 01-Mar-2018 08:43:29 { [81 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS handshake, Certificate (11):
error 01-Mar-2018 08:43:29 { [3180 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS handshake, Server key exchange (12):
error 01-Mar-2018 08:43:29 { [587 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS handshake, Server finished (14):
error 01-Mar-2018 08:43:29 { [4 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (OUT), TLS handshake, Client key exchange (16):
error 01-Mar-2018 08:43:29 } [70 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (OUT), TLS change cipher, Client hello (1):
error 01-Mar-2018 08:43:29 } [1 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (OUT), TLS handshake, Finished (20):
error 01-Mar-2018 08:43:29 } [16 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS change cipher, Client hello (1):
error 01-Mar-2018 08:43:29 { [1 bytes data]
error 01-Mar-2018 08:43:29 * TLSv1.0 (IN), TLS handshake, Finished (20):
error 01-Mar-2018 08:43:29 { [16 bytes data]
error 01-Mar-2018 08:43:29 * SSL connection using TLSv1.0 / ECDHE-RSA-AES256-SHA
error 01-Mar-2018 08:43:29 * ALPN, server did not agree to a protocol
error 01-Mar-2018 08:43:29 * Server certificate:
error 01-Mar-2018 08:43:29 * subject: CN=*.comcept.net
error 01-Mar-2018 08:43:29 * start date: Feb 24 00:00:00 2018 GMT
error 01-Mar-2018 08:43:29 * expire date: Jul 18 12:00:00 2020 GMT
error 01-Mar-2018 08:43:29 * subjectAltName: host "api-qa.comcept.net" matched cert's "*.comcept.net"
error 01-Mar-2018 08:43:29 * issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=RapidSSL RSA CA 2018
error 01-Mar-2018 08:43:29 * SSL certificate verify ok.
error 01-Mar-2018 08:43:29 } [5 bytes data]
error 01-Mar-2018 08:43:29 > GET /token HTTP/1.1
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 > Host: api-qa.comcept.net
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 > User-Agent: curl/7.53.1
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 > Accept: */*
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 >
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 { [5 bytes data]
error 01-Mar-2018 08:43:29 < HTTP/1.1 400 Bad Request
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Cache-Control: no-cache
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Pragma: no-cache
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Content-Length: 34
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Content-Type: application/json;charset=UTF-8
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Expires: -1
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Server: Microsoft-IIS/7.5
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < X-Powered-By: ASP.NET
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 < Date: Thu, 01 Mar 2018 13:44:21 GMT
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 <
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 { [34 bytes data]
error 01-Mar-2018 08:43:29
error 01-Mar-2018 08:43:29 100 34 100 34 0 0 241 0 --:--:-- --:--:-- --:--:-- 241
error 01-Mar-2018 08:43:29 * Connection #0 to host api-qa.comcept.net left intact
build 01-Mar-2018 08:43:29 {"error":"unsupported_grant_type"}
simple 01-Mar-2018 08:43:29 Finished task 'Test Curl' with result: Success
simple 01-Mar-2018 08:43:29 Running post build plugin 'NCover Results Collector'
simple 01-Mar-2018 08:43:29 Running post build plugin 'Artifact Copier'
simple 01-Mar-2018 08:43:29 Running post build plugin 'npm Cache Cleanup'
simple 01-Mar-2018 08:43:29 Running post build plugin 'Clover Results Collector'
simple 01-Mar-2018 08:43:29 Running post build plugin 'Docker Container Cleanup'
simple 01-Mar-2018 08:43:29 Finalising the build...
simple 01-Mar-2018 08:43:29 Stopping timer.
simple 01-Mar-2018 08:43:29 Build COM-TWA-JOB1-3 completed.
simple 01-Mar-2018 08:43:29 Running on server: post build plugin 'NCover Results Collector'
simple 01-Mar-2018 08:43:29 Running on server: post build plugin 'Build Hanging Detection Configuration'
simple 01-Mar-2018 08:43:29 Running on server: post build plugin 'Clover Delta Calculator'
simple 01-Mar-2018 08:43:29 Running on server: post build plugin 'Maven Dependencies Postprocessor'
simple 01-Mar-2018 08:43:29 All post build plugins have finished
simple 01-Mar-2018 08:43:29 Generating build results summary...
simple 01-Mar-2018 08:43:29 Saving build results to disk...
simple 01-Mar-2018 08:43:29 Logging substituted variables...
simple 01-Mar-2018 08:43:29 Indexing build results...
simple 01-Mar-2018 08:43:29 Finished building COM-TWA-JOB1-3.

The Bamboo Script task determines its success or failure based on the shell's exit code, which equals the exist code of the last executed command (i.e. 0 for success, everything else for failure). However, curl does not consider any non 2xx HTTP responses to be an error by default, because even for 4xx and 5xx status codes curl itself worked correctly. You can tweak this via the --fail command line flag (from the curl man page):
-f, --fail
(HTTP) Fail silently (no output at all) on server errors. This is
mostly done to better enable scripts etc to better deal with failed
attempts. In normal cases when an HTTP server fails to deliver a
document, it returns an HTML document stating so (which often also
describes why and more). This flag will prevent curl from outputting
that and return error 22.
This method is not fail-safe and there are occasions where
non-successful response codes will slip through, especially when
authentication is involved (response codes 401 and 407).
If the curl command is not the last one executed in the script, you could either save its exit code in a variable and return that, or if the shell is Bash, use e.g. set -e at the top of your script to make the shell "exit immediately if a command exits with a non-zero status". (more detailed explanation).

Related

curl says OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to s3.ap-south-1.amazonaws.com:443

I am trying to download a file over https TLS from aws using libcurl.
I am using below options
curl_easy_setopt(curl, CURLOPT_URL, url.c_str());
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, NULL);
curl_easy_setopt(curl, CURLOPT_WRITEDATA, fp);
curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);
curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_CONTROL);
curl_easy_setopt(curl, CURLOPT_CAINFO, "cert.pem");
curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256");
and I get the below output when I try to connect.
* Trying 52.219.158.33...
* TCP_NODELAY set
* Connected to s3.ap-south-1.amazonaws.com (52.219.158.33) port 443 (#0)
* ALPN, offering http/1.1
* Cipher selection: TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
* successfully set certificate verify locations:
* CAfile: cert.pem
CApath: /etc/ssl/certs
* OpenSSL SSL_connect: SSL_ERROR_ZERO_RETURN in connection to s3.ap-south-1.amazonaws.com:443
* stopped the pause stream!
* Closing connection 0*
but when I try to do the same thing using curl command line it works fine
$curl --cacert cert.pem -o final.bin -v
I get a detailed output below
% 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 52.219.66.33...
* TCP_NODELAY set
* Connected to s3.ap-south-1.amazonaws.com (52.219.66.33) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: cert.pem
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [91 bytes data]
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [5304 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.s3.ap-south-1.amazonaws.com
* start date: Mar 26 00:00:00 2021 GMT
* expire date: Mar 5 23:59:59 2022 GMT
* subjectAltName: host "s3.ap-south-1.amazonaws.com" matched cert's "s3.ap-south-1.amazonaws.com"
* issuer: C=US; O=Amazon; OU=Server CA 1B; CN=Amazon
* SSL certificate verify ok.
} [5 bytes data]
> GET /<url> HTTP/1.1
> Host: s3.ap-south-1.amazonaws.com
> User-Agent: curl/7.58.0
> Accept: */*
>
{ [5 bytes data]
< HTTP/1.1 200 OK
< x-amz-id-2: g/Q+ZRBzQktcquk2elmt1j5fA6w+WCJtJert44SXh4oeEGIZ6y55OcClxQwN/P+QaznzcMjjo=
< x-amz-request-id: MF91MY53D47PST6
< Date: Mon, 29 Nov 2021 08:27:39 GMT
< Last-Modified: Fri, 26 Nov 2021 09:47:49 GMT
< ETag: "33fd329aa6dsf3cdfcf9d7e010c3485e2"
< Accept-Ranges: bytes
< Content-Type: binary/octet-stream
< Server: AmazonS3
< Content-Length: 6304448
<
{ [5 bytes data]
100 6156k 100 6156k 0 0 322k 0 0:00:19 0:00:19 --:--:-- 485k
* Connection #0 to host s3.ap-south-1.amazonaws.com left intact
How do I get the same output using libcurl APIs?
Any other configuration is missing as part of curl config?
There is no such cipher TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 for OpenSSL listed in the manual SSL Ciphers. This caused the attempt to use TLS with the empty list of ciphers. You would know it if you had checked the returned value of curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"). The curl dump shows you the correct cipher.
curl_easy_setopt(curl, CURLOPT_SSL_CIPHER_LIST, "ECDHE-RSA-AES128-GCM-SHA256");
Additionally, curl_easy_setopt(curl, CURLOPT_USE_SSL, CURLUSESSL_CONTROL) has no affect. CURLOPT_USE_SSL is for the protocols FTP, SMTP, POP3, IMAP.

Artifactory Curl -X PUT large file - 502 Bad Gateway The proxy server received an invalid response from an upstream server / 403 Bad props auth token

Artifactory version:
EnterpriseX license 7.15.3 rev 71503900
I have admin level access on the target repository. I'm trying to upload an artifact which is close to 10GB long (air-gapped .tgz) file. I'm getting the following error.
When I try to upload the file using Artifactory UI (clicking Deploy button on the target repo), It kicks me out back to login screen, while the upload says 100% complete but check-box/options for deploying artifact as "bundle artifact" or as per user defined "Layout" is not showing up, Deploy button at the bottom of that pop-up window is also grayed out.
Tried curl using Access Key as per documentation here: https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API but it gives me an error mesg after a very long time (12-13+ hours) about 502 Bad Gateway.
I also tried using -x "" option to bypass proxy or prefixed the same command with no_proxy="10.20.30.40" curl .... but getting the same error. Tried -u user:pass, gives same error. Artifactory settings/DB configuration has been changed to allow for more connections and longer time allotted before timeout but still getting the same error.
PS: Notice that 0 under 258M in the 2nd line, i.e. line under We are completely uploaded and fine that tells me, nothing is getting uploaded.
$ curl -H "X-JFrog-Art-Api:akfljkljkALDJALKDALKJDALKDJLASJDLAKDJALKDJALKDJALKDJALKDJALJKDLKAJFLANCMNLLgoEjcfZ-c7v58FmyaAUsJ8c0gFV6VVHp2WpvYbU7IftRyzirHEmsGJ3MRL0eZqCkyZYI_pkrcgXb3H2QcQ6RxDpbY2UYgX5AKQlrLhtb644wlBtK1VelsJ90d-6TPrr59ss-igGDhS-HUpSMAYMBl9cXQtT5hAR8Q" -X PUT "https://artifactory.company.com/artifactory/AlphaPipeline-PRJ-ProjectABCPipeline-Production-Local/Pipeline-release-3.0.0.tgz" -T Pipeline-release-3.0.0.tgz -v
% 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 10.20.30.40...
* TCP_NODELAY set
* Connected to artifactory.company.com (10.20.30.40) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:#STRENGTH
* successfully set certificate verify locations:
* CAfile: C:/tools/installed/Git/mingw64/ssl/certs/ca-bundle.crt
CApath: none
* TLSv1.2 (OUT), TLS header, Certificate Status (22):
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [76 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4146 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
{ [1 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ABCDE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=US; ST=Denver; L=Centennial; O=Spotair Technologies; CN=artifactory.company.com
* start date: Feb 24 20:54:47 2021 GMT
* expire date: Feb 24 20:54:46 2022 GMT
* subjectAltName: host "artifactory.company.com" matched cert's "artifactory.company.com"
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2012 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1K
* SSL certificate verify ok.
} [5 bytes data]
> PUT /artifactory/AlphaPipeline-PRJ-ProjectABCPipeline-Production-Local/Pipeline-release-3.0.0.tgz HTTP/1.1
> Host: artifactory.company.com
> User-Agent: curl/7.60.0
> Accept: */*
> X-JFrog-Art-Api:akfljkljkALDJALKDALKJDALKDJLASJDLAKDJALKDJALKDJALKDJALKDJALJKDLKAJFLANCMNLLgoEjcfZ-c7v58FmyaAUsJ8c0gFV6VVHp2WpvYbU7IftRyzirHEmsGJ3MRL0eZqCkyZYI_pkrcgXb3H2QcQ6RxDpbY2UYgX5AKQlrLhtb644wlBtK1VelsJ90d-6TPrr59ss-igGDhS-HUpSMAYMBl9cXQtT5hAR8Q
> Content-Length: 11629208547
> Expect: 100-continue
>
{ [5 bytes data]
< HTTP/1.1 100 Continue
} [5 bytes data]
99 10.8G 0 0 99 10.7G 0 357M 0:00:31 0:00:30 0:00:01 258M* We are completely uploaded and fine
100 10.8G 0 0 100 10.8G 0 239k 13:11:33 13:11:33 --:--:-- 0{ [5 bytes data]
< HTTP/1.1 502 Bad Gateway
< Date: Wed, 07 Jul 2021 18:55:33 GMT
< Server: Apache/2.4.46 (Unix) OpenSSL/1.1.1k
< Content-Length: 232
< Content-Type: text/html; charset=iso-8859-1
<
{ [232 bytes data]
100 10.8G 0 232 100 10.8G 0 239k 13:11:33 13:11:33 --:--:-- 54<!DOCTYPE HTML PUBLIC "-//IETF//DPRJ HTML 2.0//EN">
<html><head>
<title>502 Bad Gateway</title>
</head><body>
<h1>Bad Gateway</h1>
<p>The proxy server received an invalid
response from an upstream server.<br />
</p>
</body></html>
* Connection #0 to host artifactory.company.com left intact
Another odd/annoying thing: If I use the same API Access Key on a small file (like few KBs) then I instantly hit the following 403 Bad props auth token error. If I pass another file (ex: > 2MB) without changing anything in the command, it gives me the above 502 Bad Gateway error.
{ [824 bytes data]
100 2576 100 824 100 1752 675 1437 0:00:01 0:00:01 --:--:-- 2113{
"errors" : [ {
"status" : 403,
"message" : "Bad props auth token: apiKey=my_long_apiAccessKeyHere."
} ]
}
PS: Related post when using Artifactory GUI to upload the file.
Artifactory - Can't upload or see DEPLOY button getting highlighted - can't upload artifact .tar .tgz
One thing to notice is the API key being used, I see this in the header,
"X-JFrog-Art-Api:akfljkljkALDJALKDALKJDALKDJLASJDLAKDJALKDJALKDJALKDJALKDJALJKDLKAJFLANCMNLLgoEjcfZ-c7v58FmyaAUsJ8c0gFV6VVHp2WpvYbU7IftRyzirHEmsGJ3MRL0eZqCkyZYI_pkrcgXb3H2QcQ6RxDpbY2UYgX5AKQlrLhtb644wlBtK1VelsJ90d-6TPrr59ss-igGDhS-HUpSMAYMBl9cXQtT5hAR8Q"
From where did you generated the API key? As a test, can you use the credentials as -u :.
Also, generate the API key from the profile page and use that in the header.

Debugging SSL Handshake problems of kubernetes pods with the internet

I recently installed k3s on debian 10 and I am having problems connecting to the internet from inside the pods. Ping, DNS, HTTP, works but TLS is having problems with the Handshake. I made a tcpdump and see ClientHello's and then immediatly a response from the server with internal error SSL error 80. On the VM where cluster runs on everything works fine, just not inside the pods.
Example in container:
pacman -Syu
:: Synchronizing package databases...
error: failed retrieving file 'core.db' from mirror.pkgbuild.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'core.db' from mirror.rackspace.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'core.db' from mirror.leaseweb.net : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed to update core (download library error)
error: failed retrieving file 'extra.db' from mirror.pkgbuild.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'extra.db' from mirror.rackspace.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'extra.db' from mirror.leaseweb.net : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed to update extra (download library error)
error: failed retrieving file 'community.db' from mirror.pkgbuild.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'community.db' from mirror.rackspace.com : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed retrieving file 'community.db' from mirror.leaseweb.net : error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
error: failed to update community (download library error)
error: failed to synchronize all databases
curl -4 -v https://www.google.com
* Trying 157.230.127.168:443...
* Connected to www.google.com (157.230.127.168) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS alert, internal error (592):
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
On VM:
curl -4 -v https://www.google.com
* Expire in 0 ms for 6 (transfer 0x556e74843fb0)
<snip>A lot of these expire messages</snip>
* Expire in 10 ms for 1 (transfer 0x556e74843fb0)
* Trying 172.217.23.100...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x556e74843fb0)
* Connected to www.google.com (172.217.23.100) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_256_GCM_SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google LLC; CN=www.google.com
* start date: Mar 11 15:00:19 2021 GMT
* expire date: Jun 3 15:00:18 2021 GMT
* subjectAltName: host "www.google.com" matched cert's "www.google.com"
* issuer: C=US; O=Google Trust Services; CN=GTS CA 1O1
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x556e74843fb0)
> GET / HTTP/2
> Host: www.google.com
> User-Agent: curl/7.64.0
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* old SSL session ID is stale, removing
* Connection state changed (MAX_CONCURRENT_STREAMS == 100)!
< HTTP/2 200
< date: Fri, 26 Mar 2021 01:32:52 GMT
< expires: -1
< cache-control: private, max-age=0
< content-type: text/html; charset=ISO-8859-1
< p3p: CP="This is not a P3P policy! See g.co/p3phelp for more info."
< server: gws
< x-xss-protection: 0
< x-frame-options: SAMEORIGIN
< set-cookie: NID=212=0Nbn1MMUvMRUNa8iBWgekw-YrWof3yeeBb22v94ZrQ4KkMeVm5wouwkK9ElA353VmZCp_TOXah6KfC_KQX7S48W-IgXlQUz1z4ytqKnDzSXM7X40rLw8tBwMi4oH7eLyE4nGGAfsSlUne28lwMNLobMxYls54iUbgM4x9-kuMCA; expires=Sat, 25-Sep-2021 01:32:52 GMT; path=/; domain=.google.com; HttpOnly
< alt-svc: h3-29=":443"; ma=2592000,h3-T051=":443"; ma=2592000,h3-Q050=":443"; ma=2592000,h3-Q046=":443"; ma=2592000,h3-Q043=":443"; ma=2592000,quic=":443"; ma=2592000; v="46,43"
< accept-ranges: none
< vary: Accept-Encoding
<hmtl>...,</html>
Does anybody have an idea how I can debug this or fix it?
UPDATE
Here a curl from inside the VM and a pod. I fixed the Webserver to a known working one on the Internet (Vercel Hosted Website) aswell so we debug the same server. But it is always the same error inside the pod. no matter which server I contact.
kubectl run -i --tty --rm debug --image=archlinux --restart=Never -- bash
Pod:
[root#debug /]# curl -v --tlsv1.2 --tls-max 1.2 https://wegmueller.it/ > /dev/null
% 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 157.230.127.168:443...
* Connected to wegmueller.it (157.230.127.168) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
* CApath: none
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [229 bytes data]
* TLSv1.2 (IN), TLS alert, internal error (592):
{ [2 bytes data]
* error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0
* Closing connection 0
curl: (35) error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
[root#debug /]#
VM:
curl -v --tlsv1.2 --tls-max 1.2 https://wegmueller.it/ > /dev/null
* Expire in 0 ms for 6 (transfer 0x559d896cafb0)
* Expire in 1 ms for 1 (transfer 0x559d896cafb0)
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Expire in 0 ms for 1 (transfer 0x559d896cafb0)
* Expire in 1 ms for 1 (transfer 0x559d896cafb0)
<snip a ton of expire messages>
* Expire in 50 ms for 1 (transfer 0x559d896cafb0)
* Trying 76.76.21.21...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x559d896cafb0)
* Connected to wegmueller.it (76.76.21.21) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
} [5 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
} [223 bytes data]
* TLSv1.2 (IN), TLS handshake, Server hello (2):
{ [106 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2458 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [300 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [37 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=wegmueller.it
* start date: Mar 16 21:08:10 2021 GMT
* expire date: Jun 14 21:08:10 2021 GMT
* subjectAltName: host "wegmueller.it" matched cert's "wegmueller.it"
* issuer: C=US; O=Let's Encrypt; CN=R3
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
} [5 bytes data]
* Using Stream ID: 1 (easy handle 0x559d896cafb0)
} [5 bytes data]
> GET / HTTP/2
> Host: wegmueller.it
> User-Agent: curl/7.64.0
> Accept: */*
>
{ [5 bytes data]
* Connection state changed (MAX_CONCURRENT_STREAMS == 128)!
} [5 bytes data]
< HTTP/2 200
< date: Sun, 28 Mar 2021 15:24:59 GMT
< content-type: text/html; charset=utf-8
< content-disposition: inline; filename="index"
< cache-control: public, max-age=0, must-revalidate
< content-length: 3154
< access-control-allow-origin: *
< etag: W/"637eb49039bc1f6a7aa9e4d88a56b0708b722983f403c3c2f717371b2b25a472"
< accept-ranges: bytes
< x-vercel-cache: MISS
< age: 0
< server: Vercel
< x-vercel-id: cdg1::z6h9l-1616945098788-71384c5744be
< strict-transport-security: max-age=63072000
<
{ [1112 bytes data]
100 3154 100 3154 0 0 3604 0 --:--:-- --:--:-- --:--:-- 3600
* Connection #0 to host wegmueller.it left intact
error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error
openssl error code contains 3 parts.
First 8 bits is module serial number. 14(HEX) means ssl module which has serial number 20.
The next 12 bits is function SN. 094(HEX) is SSL_SRP_CTX_init func with SN 148(DEC).
The next 12 bits 438(HEX) is error reason SSL_R_TLSV1_ALERT_INTERNAL_ERROR with 1080(DEC).
To sum up,code 14094438 means that server error occurred when it tried to initiate SSL context.
But what's the reason?
client side
client side send CLIENT HELLO with its tls version, ciphers suite and etc to server side.
what's the difference of 2 CLIENT HELLO packets on pods or VM? This need to be clear.
Here you use newest version tls 1.3. For more infomation, you may downgrade client version.
curl has options to control the TLS version used. if you want to specify that TLS 1.2 is used but not 1.1 or 1.3 etc, you need something like
curl --tlsv1.2 --tls-max 1.2 ...
server side
I also noticed that www.google.com (157.230.127.168) is different from www.google.com (172.217.23.100).
Does server side's difference lead to this situation? We can confirm with sending a curl to the same IP.
I assume either you and/or the server uses an unmatched openssl library.But before drawing conclusion, we need more debug info.

autodesk-forge, 2-legged Authentication (OAuth): oauth

Not sure what I did wrong, for 2 legged authentication. I am using cygwin terminal for curl.
Cullback URL is
http://localhost:3000/api/forge/callback/oauth
Please see the code below and let me know what is wrong. Not sure what is wrong.
jq version is 1.6, curl 7.64.1
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
To me it looks like, HTTP version is the reason of the error.I am very new for forge. So give me some idea, about what is wrong here.
$ curl -v 'https://developer.api.autodesk.com/authentication/v1/authenticate' -H 'Content-Type: application/x-www-form-urlencoded' -d 'client_id=qWSjFdCYTfhWsLZCSsLcSZCrDY2GsVSq' -d 'client_secret=PChX1GbaPFG42hQi' -d 'grant_type=client_credentials' -d 'scope=data:all'
output error report as below:
* STATE: INIT => CONNECT handle 0x8000770d8; line 1356 (connection #-5000)
* Added connection 0. The cache now contains 1 members
* STATE: CONNECT => WAITRESOLVE handle 0x8000770d8; line 1397 (connection #0)
* Trying 34.212.2.95:443...
* TCP_NODELAY set
* STATE: WAITRESOLVE => WAITCONNECT handle 0x8000770d8; line 1476 (connection #0)
* Connected to developer.api.autodesk.com (34.212.2.95) port 443 (#0)
* STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x8000770d8; line 1532 (connection #0)
* Marked for [keep alive]: HTTP default
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* STATE: SENDPROTOCONNECT => PROTOCONNECT handle 0x8000770d8; line 1547 (connection #0)
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: businessCategory=Private Organization; jurisdictionC=US; jurisdictionST=Delaware; serialNumber=2401504; C=US; ST=California; L=San Rafael; O=Autodesk, Inc.; OU=MCP-ASRD-CP; CN=developer.api.autodesk.com
* start date: Mar 22 00:00:00 2019 GMT
* expire date: Mar 22 12:00:00 2020 GMT
* subjectAltName: host "developer.api.autodesk.com" matched cert's "developer.api.autodesk.com"
* issuer: C=US; O=DigiCert Inc; OU=www.digicert.com; CN=DigiCert SHA2 Extended Validation Server CA
* SSL certificate verify ok.
* STATE: PROTOCONNECT => DO handle 0x8000770d8; line 1566 (connection #0)
> POST /authentication/v1/authenticate HTTP/1.1
> Host: developer.api.autodesk.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Type: application/x-www-form-urlencoded
> Content-Length: 118
>
* upload completely sent off: 118 out of 118 bytes
* STATE: DO => DO_DONE handle 0x8000770d8; line 1621 (connection #0)
* STATE: DO_DONE => PERFORM handle 0x8000770d8; line 1743 (connection #0)
* Mark bundle as not supporting multiuse
* HTTP 1.1 or later with persistent connection
< HTTP/1.1 400 Bad Request
< Content-Type: application/json
< Date: Thu, 22 Aug 2019 05:58:08 GMT
< Content-Length: 210
< Connection: keep-alive
<
* STATE: PERFORM => DONE handle 0x8000770d8; line 1933 (connection #0)
* multi_done
* Connection #0 to host developer.api.autodesk.com left intact
{"developerMessage":"Requested scopes must be blank or a subset of the provided scopes.","userMessage":"","errorCode":"AUTH-004","more info":"http://developer.api.autodesk.com/documentation/v1/errors/AUTH-004"}
As the error message suggests data:all is not a valid scope...
See the Resource Information section of the endpoints you are accessing to see what scopes are required - you can specify multiple scopes so long as they are valid delimited by space:
scope=data:read data:write bucket:read code:all

servers returns "Invalid Host header" inside alpine when connecting via ssl

First of all, this question is not about how to fix this, but rather about why it happens.
Exact same curl (exact same version curl/7.65.1) with exact same request produces different results.
Why the certificate chain is different?
How server response depends on ssl connection flow? (Alpine get response body "Invalid host header", host OS downloads file w/o any issues)?
Why http version is different? How do the server and client agree on protocol version? Running the same command with --http curl flag fixes the issue.
docker run -i -t alpine /bin/sh:
apk add curl
curl -kfSL https://nginx.org/download/nginx-1.15.3.tar.gz -o nginx.tar.gz -vvv
Output:
* Trying 95.211.80.227:443...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: CN=localhost
* start date: Jul 8 19:13:11 2019 GMT
* expire date: Aug 7 19:13:11 2019 GMT
* issuer: CN=localhost
* SSL certificate verify result: self signed certificate (18), continuing anyway.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* Using Stream ID: 1 (easy handle 0x55e3e4a37540)
> GET /download/nginx-1.15.3.tar.gz HTTP/2
> Host: nginx.org
> User-Agent: curl/7.65.1
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 4294967295)!
< HTTP/2 200
< x-powered-by: Express
< content-type: text/html; charset=utf-8
< content-length: 19
< etag: W/"13-OxsTL6IB85fkJxv9HO8uum0slCI"
<
* Connection #0 to host nginx.org left intact
Invalid Host header
Same curl command works completely fine from my host machine (Archlinux bleeding edge) even without insecure (-k)option.
% 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 95.211.80.227:443...
* TCP_NODELAY set
* Connected to nginx.org (95.211.80.227) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [108 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [2621 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=nginx.org
* start date: May 14 19:45:30 2019 GMT
* expire date: Aug 12 19:45:30 2019 GMT
* subjectAltName: host "nginx.org" matched cert's "nginx.org"
* issuer: C=US; O=Let's Encrypt; CN=Let's Encrypt Authority X3
* SSL certificate verify ok.
} [5 bytes data]
> GET /download/nginx-1.15.3.tar.gz HTTP/1.1
> Host: nginx.org
> User-Agent: curl/7.65.1
> Accept: */*
>
{ [5 bytes data]
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Server: nginx/1.15.7
< Date: Wed, 10 Jul 2019 13:03:16 GMT
< Content-Type: application/octet-stream
< Content-Length: 1022881
< Last-Modified: Tue, 28 Aug 2018 15:40:55 GMT
< Connection: keep-alive
< Keep-Alive: timeout=15
< ETag: "5b856d07-f9ba1"
< Accept-Ranges: bytes
P.S. I'm aware of this response