Linux curl not working - linux

I am trying to access a remote server which responds properly in one network but not in another. I can access it on my local machine(In some networks) but not on aws:
Working Curl:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=**; ST=***; L=***; x.x.x.x.x.x.x.x.x.x=**; x.x.x.x.x.x.x.x.x.x=ABCD; x.x.x.x.x.x.x.x.x.x.x=def; O=abc def ghi; businessCategory=abc def; serialNumber=123456; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '******'
> POST /abc/def HTTP/1.1
> Authorization: Basic *********************
> User-Agent: curl/7.38.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Date: Sat, 23 Apr 2016 07:31:25 GMT
* Server Oracle-Application-Server-11g is not blacklisted
< Server: Oracle-Application-Server-11g
< X-ORACLE-DMS-ECID: *************************
< SOAPAction: "http://ghi.services//abc"
< X-Powered-By: Servlet/2.5 JSP/2.1
< Vary: Accept-Encoding,User-Agent
< Content-Type: text/xml; charset=utf-8
< Content-Language: en
< Transfer-Encoding: chunked
<
<XML>SUCCESSFUL OUTPUT</XML>
Not working CURL:
curl -vvv https://abc.example.com -H 'Content-Type:text/xml' --user ******:***** -d '<XML></XML>'
Output:
* Hostname was NOT found in DNS cache
* Trying xx.xx.xx.xx...
* Connected to abc.example.com (xx.xx.xx.xx) port 443 (#0)
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, Client key exchange (16):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSLv3, TLS change cipher, Client hello (1):
* SSLv3, TLS handshake, Finished (20):
* SSL connection using ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
* subject: C=XX; ST=XXXXXXX; L=XXXXXXX; x.x.x.x.x.x.x=XX; x.x.x.x.x.x.x=XXXXXXX; x.x.x.x.x.x.x.x.x.x.x.x=XXXXX; O=Some company name; businessCategory=My unit; serialNumber=12345; CN=abc.example.com
* start date: 2016-04-04 07:19:41 GMT
* expire date: 2018-04-04 07:49:39 GMT
* subjectAltName: abc.example.com matched
* issuer: C=US; O=Entrust, Inc.; OU=See www.entrust.net/legal-terms; OU=(c) 2014 Entrust, Inc. - for authorized use only; CN=Entrust Certification Authority - L1M
* SSL certificate verify ok.
* Server auth using Basic with user '**********'
> POST /abc/def HTTP/1.1
> Authorization: Basic ******************
> User-Agent: curl/7.35.0
> Host: abc.example.com
> Accept: */*
> Content-Type:text/xml
> Content-Length: 16783
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 400 Bad Request
< Date: Sat, 23 Apr 2016 07:37:47 GMT
* Server Apache is not blacklisted
< Server: Apache
< Content-Length: 226
< Connection: close
< Content-Type: text/html; charset=iso-8859-1
<
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
* Closing connection 0
* SSLv3, TLS alert, Client hello (1):
I don't have any idea what's going on. Please help

Related

shopify is not accepting image src when the downloadable image content type (image/jpeg;charset=UTF-8)

Here is the source URL of the image -
https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg
curl result for the image file -
curl -v 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg'
* Trying 62.245.203.125:443...
* Connected to erp.guu-portal.de (62.245.203.125) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/cert.pem
* CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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 change cipher, Change cipher spec (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: CN=*.guu-portal.de
* start date: Jan 5 00:00:00 2021 GMT
* expire date: Feb 5 23:59:59 2022 GMT
* subjectAltName: host "erp.guu-portal.de" matched cert's "*.guu-portal.de"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=Sectigo Limited; CN=Sectigo RSA Domain Validation Secure Server CA
* SSL certificate verify ok.
> GET /erp/dokumente/download/759927?filename=9783835408241.jpg HTTP/1.1
> Host: erp.guu-portal.de
> User-Agent: curl/7.77.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 14 Jan 2022 17:55:16 GMT
< Server: Apache-Coyote/1.1
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: SAMEORIGIN
< Last-Modified: Thu, 18 Oct 2018 20:32:21 GMT
< Content-Disposition: attachment; filename=9783835408241.jpg
< Content-Type: image/jpeg;charset=UTF-8
< Content-Length: 182163
< Set-Cookie: JSESSIONID=30BDB73806080AEF778934ABEBADFFCE.worker1; Path=/erp; HttpOnly
<
Warning: Binary output can mess up your terminal. Use "--output -" to tell
Warning: curl to output it to your terminal anyway, or consider "--output
Warning: <FILE>" to save to a file.
* Failure writing output to destination
* Closing connection 0
* TLSv1.2 (OUT), TLS alert, close notify (256):
I was sending payload in post request -
payload = {'image': {'src': 'https://erp.guu-portal.de/erp/dokumente/download/759927?filename=9783835408241.jpg', 'filename': '399_1.jpg'}}
Posting images to rest API URL -
requests.session.put(base_url + f"products/{product_id}.json",payload))
Response:
Status Code 422 with Message: {"errors":{"image":["Could not process image: [\"\/erp\/dokumente\/download\/759927 (image\/jpeg;charset=UTF-8) is not a recognized format\"]"]}}
I have tried other public images and they work... however, they had content-type image/jpeg only

Websockets on Node-server hosted in Azure fails

I have a barebone simple example that works locally but not in Azure. My original question was a bit specific to an cors-error, that i have now worked around, and therefor edited away that part. But i still cant manage to make WS work on azure. And i need help.;
var server = http.Server(app);
const wss = new WebSocket.Server({server});
server.listen(8070, () => {
console.log("Listening on " + port)
});
wss.on('connection', (socket) => {
console.log('a user connected');
socket.on('message', (msg) => {
console.log(msg)
socket.send(JSON.stringify({hey:'you'}))
})
});
client connection-string:
SOCKET_ENDPOINT = 'wss://******.azurewebsites.net/';
I've turned on websockets in my app-configuration.
EDIT:
So i have now turned every stone. Even switched library from socket.io to ws. Same problem. I came a little further i think when trying different things, now i get following error "Firefox can’t establish a connection to the server at wss://*******.azurewebsites.net:8070/."
Edit2:
The http-upgrade is fine
Here's the error
Edit 3: Curl command:
* TCP_NODELAY set
* Connected to *******.azurewebsites.net (20.40.202.6) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: /etc/ssl/certs
* 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-AES256-GCM-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: CN=*.azurewebsites.net
* start date: Sep 28 19:00:01 2020 GMT
* expire date: Sep 28 19:00:01 2021 GMT
* subjectAltName: host "********.azurewebsites.net" matched cert's "*.azurewebsites.net"
* issuer: C=US; O=Microsoft Corporation; CN=Microsoft RSA TLS CA 01
* SSL certificate verify ok.
> GET /socket.io/?EIO=4 HTTP/1.1
> Host: *********.azurewebsites.net
> User-Agent: curl/7.68.0
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 401 Unauthorized
< Server: Kestrel
< WWW-Authenticate: Bearer realm="********.azurewebsites.net" authorization_uri="https://login.windows.net/<tenant>/oauth2/authorize" resource_id="<resource>"
< Date: Tue, 22 Jun 2021 05:56:15 GMT
< Content-Length: 0
<
* Connection #0 to host *******.azurewebsites.net left intact
I am guessing that you host your app in Azure AppService?
Make sure you have websocket option turned on in platform:
AppService resource -> Settings -> General settings tab -> Platform settings section

axios SSL error with Node 12 : SSL routines:ssl_choose_client_version:unsupported protocol

I’m running into an issue with axios and Node 12. As I’m not sure this error is only related to axios, I followed the advice to ask on SO rather than opening a bug on axios’ GitHub.
Here is the code I’m trying to run :
const axios = require('axios')
axios({
method: 'get',
url: 'https://www.colisprive.com/moncolis/pages/detailColis.aspx?numColis=12345',
responseType: 'text'
}).then((response) => {
console.log(response)
})
This code fails on Node 12 with following error :
Error: write EPROTO 140121214769024:error:1425F102:SSL routines:ssl_choose_client_version:unsupported protocol:../deps/openssl/openssl/ssl/statem/statem_lib.c:1929:
at WriteWrap.onWriteComplete [as oncomplete] (internal/stream_base_commons.js:87:16)
Same code ran against Node 11 doesn’t throw any error.
When I curl -v I got this :
* Trying 91.208.224.32:443...
* TCP_NODELAY set
* Connected to www.colisprive.com (91.208.224.32) 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.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-AES256-SHA384
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: serialNumber=391029345; jurisdictionC=FR; businessCategory=Private Organization; C=FR; postalCode=13290; ST=Bouches-du-Rh�ne; L=AIX EN PROVENCE; street=1330 AV J R G GAUTIER DE LA LAUZIERE; street=ZI MILLES EUROPARC PICHAURY; O=COLIS PRIVE SAS; OU=0002 391029345; CN=www.colisprive.com
* start date: Sep 3 00:00:00 2018 GMT
* expire date: Sep 2 23:59:59 2020 GMT
* subjectAltName: host "www.colisprive.com" matched cert's "www.colisprive.com"
* issuer: C=GB; ST=Greater Manchester; L=Salford; O=COMODO CA Limited; CN=COMODO RSA Extended Validation Secure Server CA
* SSL certificate verify ok.
> GET /moncolis/pages/detailColis.aspx?numColis=12345 HTTP/1.1
> Host: www.colisprive.com
> User-Agent: curl/7.65.3
> Accept: */*
>
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 Found
< Cache-Control: private
< Content-Type: text/html; charset=utf-8
< Location: /moncolis/Default.aspx?numColis=12345&cp=
< Server: Microsoft-IIS/7.5
< Set-Cookie: ASP.NET_SessionId=eln3cq143d35lfj5tpqkkwcg; path=/; HttpOnly
< X-Powered-By: Colis Priv�
< Date: Fri, 24 Jan 2020 13:48:35 GMT
< Content-Length: 162
<
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
* Connection #0 to host www.colisprive.com left intact
As you can see, it gives a 302 Found with a Location header pointing to another endpoint. I agree it should answer a 301 Moved to indicate document has moved, but this is not the case and it is handled as expected by axios on Node 11 (fetching endpoint under Location header).
I saw that Node 12 now includes TLS 1.3 as default, so this could be related to that…
Also, there is an unknown character in X-Powered-By header.
I tried to :
reproduce this issue with an express server always replying 302 Found with same headers : works as expected
fetch another .aspx web page with axios : works as expected
The problem is not just with axios but with got as well.
Node.js 12's default TLS settings are stricter now. The site doesn't handle TLS v1.2. Node 12 by default need 1.2.
You can change this via a command line flag (--tls-min-v1.0) when running your app.
something like this
node --tls-min-v1.0 app.js

Istio throwing 404 for URL mapped in Virtual Service

Cloud Provider: Azure
Istio Version: 1.19
Kubernetes Version: 1.12.8
Below is my Virtual Service and Gateway yaml
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
name: app-ingress-rules
namespace: istio-system
# Define the routes less restrictive first to more restrictive. this file gets read from bottom to top.
spec:
# https://istio.io/docs/reference/config/istio.networking.v1alpha3/#VirtualService
gateways: # The default `mesh` value for when left blank is doesn't seem to propigate the rule properly. For now, always use a list of FQDN gateways
- tls-gateway
hosts:
- "dev.myapp.westus.cld.something.com" # This host is part of installed HTTPS cert
- "nonprod.westus.cloudapp.azure.com" # This host is NOT part of installed HTTPS cert
http:
# Routes
- match:
- uri:
prefix: /myapp/status
rewrite:
uri: /status
route:
- destination:
host: myapp.myapp-ns.svc.cluster.local
--------------------------------------------
apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
name: tls-gateway
namespace: istio-system
spec:
selector:
istio: ingressgateway
servers:
- port:
name: https
number: 443
protocol: HTTPS
tls:
mode: SIMPLE
serverCertificate: /etc/istio/ingressgateway-certs/tls.crt
privateKey: /etc/istio/ingressgateway-certs/tls.key
hosts:
- "*"
If I do
curl -Iv https://dev.myapp.westus.cld.something.com/myapp/status
I get HTTP 404 as below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to dev.myapp.westus.cld.something.com (123.12.123.12.) 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: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=***; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GM
* subjectAltName: host "dev.myapp.westus.cld.something.com" matched cert's "dev.myapp.westus.cld.something.com"
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* 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 0x7f995e006600)
> HEAD /myapp/status HTTP/2
> Host: dev.myapp.westus.cld.something.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 404
HTTP/2 404
< location: https://dev.myapp.westus.cld.something.com/myapp/status
location: https://dev.myapp.westus.cld.something.com /myapp/status
< date: Wed, 31 Jul 2019 19:10:13 GMT
date: Wed, 31 Jul 2019 19:10:13 GMT
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host dev.myapp.westus.cld.something.com left intact
However when I try with
curl -Iv --insecure https://nonprod.westus.cloudapp.azure.com/myapp/status
I get HTTP 200. see below
* Trying 123.12.123.12...
* TCP_NODELAY set
* Connected to nonprod.westus.cloudapp.azure.com (123.12.123.12) 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: /etc/ssl/cert.pem
CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (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, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-CHACHA20-POLY1305
* ALPN, server accepted to use h2
* Server certificate:
* subject: C=US; ST=****; L=*****; O=******, Inc.; CN=*********
* start date: Jul 26 20:32:59 2019 GMT
* expire date: Jul 26 20:32:59 2021 GMT
* issuer: C=BE; O=GlobalSign nv-sa; CN=GlobalSign RSA OV SSL CA 2018
* 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 0x7fb4b7003c00)
> HEAD /myapp/status HTTP/2
> Host: nonprod.westus.cloudapp.azure.com
> User-Agent: curl/7.54.0
> Accept: */*
>
* Connection state changed (MAX_CONCURRENT_STREAMS updated)!
< HTTP/2 200
HTTP/2 200
< request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
request-context: appId=cid-v1:39296fe8-1dc6-4049-bb31-e7816e83b9ec
< access-control-allow-origin: *
access-control-allow-origin: *
< access-control-expose-headers: Content-Disposition
access-control-expose-headers: Content-Disposition
< content-type: text/plain;charset=ISO-8859-1
content-type: text/plain;charset=ISO-8859-1
< content-length: 69
content-length: 69
< date: Wed, 31 Jul 2019 19:07:54 GMT
date: Wed, 31 Jul 2019 19:07:54 GMT
< x-envoy-upstream-service-time: 7
x-envoy-upstream-service-time: 7
< server: istio-envoy
server: istio-envoy
<
* Connection #0 to host nonprod.westus.cloudapp.azure.com left intact
Is my VS configuration wrong with regards to accepting HTTPS traffic? I am unable to look at envoy logs to see if there is any error.
How can I pinpoint where the issue is?
Update
dev.myapp.westus.cld.something.com is a CName record which ultimately points to nonprod.westus.cloudapp.azure.com
nonprod.westus.cloudapp.azure.com is a actual DNS which is mapped to a public IP.
Note sure if that makes any difference.

running curl in alpine takes too long to start

I have a node:8.9.2-alpine image where I try to run
curl -o /dev/null -s -w 'Total: %{time_total}\n' 'https://feed.theplatform.com/' -v
The call takes 6 sec. If I run the same curl locally it takes like 0.5 sec.
I found out that nslookup takes some time, so I ran
RUN apk add --update --no-cache bind-tools
however my curl still takes 6 sec.
/ # curl -o /dev/null -s -w 'Total: %{time_total}\n' 'https://feed.theplatform.com/' -v --trace-time
10:13:54.843110 * Trying 199.27.170.188...
10:13:54.843198 * TCP_NODELAY set
10:13:54.938974 * Connected to feed.theplatform.com (199.27.170.188) port 443 (#0)
10:13:54.939222 * ALPN, offering http/1.1
10:13:54.950969 * successfully set certificate verify locations:
10:13:54.951041 * CAfile: /etc/ssl/certs/ca-certificates.crt
CApath: none
10:13:54.951198 * TLSv1.2 (OUT), TLS handshake, Client hello (1):
10:13:54.951222 } [512 bytes data]
10:13:55.046650 * TLSv1.2 (IN), TLS handshake, Server hello (2):
10:13:55.046875 { [85 bytes data]
10:13:55.047031 * TLSv1.2 (IN), TLS handshake, Certificate (11):
10:13:55.047063 { [3984 bytes data]
10:13:55.047965 * TLSv1.2 (IN), TLS handshake, Server finished (14):
10:13:55.047990 { [4 bytes data]
10:13:55.048175 * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
10:13:55.048197 } [262 bytes data]
10:13:55.048233 * TLSv1.2 (OUT), TLS change cipher, Client hello (1):
10:13:55.048253 } [1 bytes data]
10:13:55.048338 * TLSv1.2 (OUT), TLS handshake, Finished (20):
10:13:55.048358 } [16 bytes data]
10:13:55.147028 * TLSv1.2 (IN), TLS change cipher, Client hello (1):
10:13:55.147077 { [1 bytes data]
10:13:55.147205 * TLSv1.2 (IN), TLS handshake, Finished (20):
10:13:55.147227 { [16 bytes data]
10:13:55.147273 * SSL connection using TLSv1.2 / AES256-SHA256
10:13:55.147295 * ALPN, server did not agree to a protocol
10:13:55.147339 * Server certificate:
10:13:55.147395 * subject: C=US; ST=Washington; L=Seattle; O=thePlatform, LLC; OU=Network Operations; CN=feed.theplatform.com
10:13:55.147423 * start date: Oct 22 22:05:39 2015 GMT
10:13:55.147451 * expire date: Jan 5 22:35:38 2019 GMT
10:13:55.147495 * subjectAltName: host "feed.theplatform.com" matched cert's "feed.theplatform.com"
10:13:55.147531 * 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
10:13:55.147553 * SSL certificate verify ok.
10:13:55.147650 > GET / HTTP/1.1
10:13:55.147650 > Host: feed.theplatform.com
10:13:55.147650 > User-Agent: curl/7.60.0
10:13:55.147650 > Accept: */*
10:13:55.147650 >
10:13:55.244488 < HTTP/1.1 403 Forbidden
10:13:55.244544 < Date: Fri, 13 Jul 2018 10:13:55 GMT
10:13:55.244576 < Content-Type: text/html;charset=ISO-8859-1
10:13:55.244606 < Cache-Control: must-revalidate,no-cache,no-store
10:13:55.244637 < Content-Length: 1365
10:13:55.244668 < Connection: close
10:13:55.244699 < Server: Jetty(8.1.16.2)
10:13:55.244730 <
10:13:55.244760 { [1225 bytes data]
10:13:55.244901 * Closing connection 0
10:13:55.245043 * TLSv1.2 (OUT), TLS alert, Client hello (1):
10:13:55.245079 } [2 bytes data]
Total: 5.915162
enter code here
enter code here
If I call the http version it still takes too long time:
/ # curl -o /dev/null -s -w 'Total: %{time_total}\n' 'http://feed.theplatform.com/' -v --trace-time
10:12:29.865144 * Trying 199.27.170.188...
10:12:29.865215 * TCP_NODELAY set
10:12:29.961021 * Connected to feed.theplatform.com (199.27.170.188) port 80 (#0)
10:12:29.961119 > GET / HTTP/1.1
10:12:29.961119 > Host: feed.theplatform.com
10:12:29.961119 > User-Agent: curl/7.60.0
10:12:29.961119 > Accept: */*
10:12:29.961119 >
10:12:30.057339 < HTTP/1.1 403 Forbidden
10:12:30.057395 < Date: Fri, 13 Jul 2018 10:12:30 GMT
10:12:30.057425 < Content-Type: text/html;charset=ISO-8859-1
10:12:30.057453 < Cache-Control: must-revalidate,no-cache,no-store
10:12:30.057482 < Content-Length: 1365
10:12:30.057505 < Connection: close
10:12:30.057527 < Server: Jetty(8.1.16.2)
10:12:30.057554 <
10:12:30.057578 { [1365 bytes data]
10:12:30.057666 * Closing connection 0
Total: 5.705922
I have the same issue if I use node:8.11.3-alpine
As the time shows, it is the start of the call that has an issue.
How do I fix this?
It was an issue with my name server.
By adding %{time_namelookup} and running
curl -o /dev/null -s -w 'Total: %{time_total}\nTime Namelookup: %{time_namelookup}\n' 'http://feed.theplatform.com/' -v --trace-time
I got Time Namelookup: 5.514205
I tried changing the nameserver to googles and then I got the result in 0.5 sec.

Resources