I have installed a local Kubernetes cluster using minikube following the instructions here.
I'm under a corporate proxy. Therefore I have set the http_proxy and https_proxy env vars. Once the cluster is started after minikube start command I also added the value of minikube ip to the no_proxy env var. However still kubectl cannot connect to the cluster.
ubuntu#ros-2:~$ kubectl -v=7 get pods
I0105 10:31:47.773801 17607 loader.go:354] Config loaded from file /home/ubuntu/.kube/config
I0105 10:31:47.775151 17607 round_trippers.go:296] GET https://192.168.42.22:8443/api
I0105 10:31:47.778533 17607 round_trippers.go:303] Request Headers:
I0105 10:31:47.778606 17607 round_trippers.go:306] Accept: application/json, */*
I0105 10:31:47.778676 17607 round_trippers.go:306] User-Agent: kubectl/v1.5.1 (linux/amd64) kubernetes/82450d0
I0105 10:31:47.783069 17607 round_trippers.go:321] Response Status: in 4 milliseconds
I0105 10:31:47.783166 17607 helpers.go:221] Connection error: Get https://192.168.42.22:8443/api: Forbidden port
F0105 10:31:47.783181 17607 helpers.go:116] Unable to connect to the server: Forbidden port
I'm assuming this is because of kubectl not being aware of the no_proxy settings. A simple curl to the cluster goes through fine.
ubuntu#ros-2:~$ curl -v -k https://192.168.42.22:8443/api
* Hostname was NOT found in DNS cache
* Trying 192.168.42.22...
* Connected to 192.168.42.22 (192.168.42.22) port 8443 (#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, Request CERT (13):
* SSLv3, TLS handshake, Server finished (14):
* SSLv3, TLS handshake, CERT (11):
* 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-AES128-GCM-SHA256
* Server certificate:
* subject: CN=minikube
* start date: 2017-01-04 16:04:47 GMT
* expire date: 2018-01-04 16:04:47 GMT
* issuer: CN=minikubeCA
* SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
> GET /api HTTP/1.1
> User-Agent: curl/7.35.0
> Host: 192.168.42.22:8443
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Content-Type: text/plain; charset=utf-8
< X-Content-Type-Options: nosniff
< Date: Thu, 05 Jan 2017 10:33:45 GMT
< Content-Length: 13
<
Unauthorized
* Connection #0 to host 192.168.42.22 left intact
Any ideas on how to fix this?
Fixed this. The fix was to have the no_proxy details in NO_PROXY as well.
export NO_PROXY=$no_proxy,$(minikube ip)
Relevant thread. Hope this will be useful to someone.
Related
I am trying to do buy/sell orders after some computation in the unix-BASH environment by application of www.api.coinex.com data. Therefore, I wrote s simple BASH code to put a market order for DOGEUSDT.
I use the following official guidelines:
API Invocation Instruction
Place Market Order
-I use VPN IN MINT 20. Linux.
-The codes to get data work well, but have problems with POST data.
#!/bin/bash
#A code to put a market order in the www.coinex.com exchange pairs
#My Access ID in www.coinex.com
access_id="xxxx"
#My secrect Key in www.coinex.com
secret_key="xxxx"
#Request Url
get_url="https://api.coinex.com/v1/order/market"
#Any Amount
amount="100.0"
#Any pair in the Market
marketpair="DOGEUSDT"
#buy or sell
market_type="sell"
#the market price
price="0.041"
#Get servertime, Tonce is a timestamp with a positive Interger that represents the number of milliseconds from Unix epoch to the current time. Error between tonce and server time can not exceed plus or minus 60s
tonce=`curl -X GET https://api.coinex.com/v1/market/ticker/all | jq .data.date`
#authorization code using 32-bit MD5 Algorithm Signature
authorization=`echo -n 'access_id='$access_id'&amount='$amount'&market='$marketpair'&tonce='$tonce'&type='$market_type'&secret_key='$secret_key''|md5sum`
#Convert authorization to UPPERCASE
authorization1=`echo ${authorization^^}`
#Place market order
curl -v -H "authorization:'$authorization1'" -H "Content-Type: application/json" -d '{"access_id":"'$access_id'", "amount": "'$amount'","market":"'$market'", "tonce": "'$tonce'", "type": "'$market_type'"}' -X -POST "'$get_url'"
I got following error:
* Could not resolve host: 'https
* Closing connection 0
curl: (6) Could not resolve host: 'https
Edition
I got the following error after running the latest proposals in the comments.
` `++ curl -v -H 'authorization: 5EB8EFD237AC301BB854D32407C39AF8 -' -H 'Content-Type: application/json' -d '{
"access_id": "03391998195A4A3EAD0D6C59336CF1D1",
"amount": "0.1",
"market": "ARUSDT",
"tonce": "1636216102004",
"type": "sell"
}' --url https://api.coinex.com/v1/order/market
* Trying 104.18.30.180:443...
* TCP_NODELAY set
* Connected to api.coinex.com (104.18.30.180) 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.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=San Francisco; O=Cloudflare, Inc.; CN=coinex.com
* start date: Nov 1 00:00:00 2021 GMT
* expire date: Oct 31 23:59:59 2022 GMT
* subjectAltName: host "api.coinex.com" matched cert's "*.coinex.com"
* issuer: C=US; O=Cloudflare, Inc.; CN=Cloudflare Inc ECC CA-3
* 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 0x562e9c3c3c80)
> POST /v1/order/market HTTP/2
> Host: api.coinex.com
> user-agent: curl/7.68.0
> accept: */*
> authorization: 5EB8EFD237AC301BB854D32407C39AF8 -
> content-type: application/json
> content-length: 140
>
* We are completely uploaded and fine
* 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 == 256)!
< HTTP/2 200
< date: Sat, 06 Nov 2021 16:28:24 GMT
< content-type: application/json
< content-length: 54
< cf-cache-status: DYNAMIC
< expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
< server: cloudflare
< cf-ray: 6a9fb1d72a0c6283-OTP
<
* Connection #0 to host api.coinex.com left intact
{"code": 25, "data": {}, "message": "Signature error"} `
`
I propose you format your JSON data with jq tool. It's a better and sure formatter than bash or whatelse.
Your cURL last line became:
# The JSON data format for jq command
# Important: $token are not for bash variables but for jq arguments
# So, DATA_FORMAT must be defined between simple cotes (not double)
declare DATA_FORMAT='{"access_id": $access_id, "amount": $amount, "market": $market, "tonce": $tonce, "type": $market_type}'
# jq call to format JSON data
# The jq arguments in data format will be replaced by bash variable values (in this example, with the same name)
declare DATA_CONTENT=$(jq \
--null-input \
--arg access_id "${access_id}" \
--arg amount "${amount}" \
--arg market "${market}" \
--arg tonce "${tonce}" \
--arg market_type "${market_type}" \
"${DATA_FORMAT}" \
)
# cURL call
curl \
-v \
-H "authorization: $authorization1" \
-H "Content-Type: application/json" \
-d "${DATA_CONTENT}" \
--url "$get_url"
According to the latest reply I received from the www.coinex.com support team, the code must be written in node language, they didn’t mention BASH. It seems BASH is not supported.
Also, I found a python package to connect with spot pairs at www.coinex.com. I traded crypto pairs with this repository successfully.
https://github.com/imanmousaei/coinexpy
Based on Sending Push Notifications Using Command-Line Tools, I set the following shell variables after making a new CSR, App ID, and obtaining a new provider certificate from Apple:
CERTIFICATE_FILE_NAME=/Users/developer/desktop/aps.cer
CERTIFICATE_KEY_FILE_NAME=/Users/developer/desktop/PushChatKey.p12
TOPIC=com.domainname.appname
DEVICE_TOKEN=af59ba83a511f21f343df63ebd1bcd32225878e7d9401a4e933a3caf0cf55a63
APNS_HOST_NAME=api.sandbox.push.apple.com
I input the following terminal command to send a test push notification:
curl -v --header apns-topic: com.domainname.appname --header apns-push-type: alert --cert aps.cer --cert-type DER --key PushChatKey.pem --key-type PEM --data '{"aps":{"alert":"test"}}' --http2 https://api.sandbox.push.apple.com/3/device/45822f2c09e0dbdfa6659b08f0b35ab8bda910d29f4abb107dfbf88f323e34f1
This was the resulting terminal output:
curl -v --header apns-topic: com.domainname.appname --header apns-push-type: alert --cert aps.cer --cert-type DER --key PushChatKey.pem --key-type PEM --data '{"aps":{"alert":"test"}}' --http2 https://api.sandbox.push.apple.com/3/device/45822f2c09e0dbdfa6659b08f0b35ab8bda910d29f4abb107dfbf88f323e34f1
* Could not resolve host: com.domainname.appname
* Closing connection 0
curl: (6) Could not resolve host: com.domainname.appname
* Could not resolve host: alert
* Closing connection 1
curl: (6) Could not resolve host: alert
* Trying 17.188.138.71...
* TCP_NODELAY set
* Connected to api.sandbox.push.apple.com (17.188.138.71) port 443 (#2)
* ALPN, offering h2
* ALPN, offering http/1.1
Enter PEM pass phrase:
* 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, Request CERT (13):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS handshake, CERT verify (15):
* 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 h2
* Server certificate:
* subject: CN=api.development.push.apple.com; OU=management:idms.group.533599; O=Apple Inc.; ST=California; C=US
* start date: Feb 8 21:41:22 2021 GMT
* expire date: Mar 10 21:41:22 2022 GMT
* subjectAltName: host "api.sandbox.push.apple.com" matched cert's "api.sandbox.push.apple.com"
* issuer: CN=Apple Public Server RSA CA 12 - G1; O=Apple Inc.; ST=California; C=US
* 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 0x7fe70780d600)
> POST /3/device/45822f2c09e0dbdfa6659b08f0b35ab8bda910d29f4abb107dfbf88f323e34f1 HTTP/2
> Host: api.sandbox.push.apple.com
> User-Agent: curl/7.64.1
> Accept: */*
> Content-Length: 24
> Content-Type: application/x-www-form-urlencoded
>
* Connection state changed (MAX_CONCURRENT_STREAMS == 1000)!
* We are completely uploaded and fine
< HTTP/2 400
< apns-id: E9EC6D23-7E07-BA0A-B574-F478271AE803
<
* Connection #2 to host api.sandbox.push.apple.com left intact
{"reason":"MissingTopic"}* Closing connection 2
How can I fix this?
The problem is with this part:
--header apns-topic: com.domainname.appname
Please adjust it to:
Note the use of single quotes '' at the beginning and end of the --header argument apns-topic: com.domainname.appname
--header 'apns-topic: com.domainname.appname'
curl -v --header 'apns-topic: com.domainname.appname' --header apns-push-type: alert --cert aps.cer --cert-type DER --key PushChatKey.pem --key-type PEM --data '{"aps":{"alert":"test"}}' --http2 https://api.sandbox.push.apple.com/3/device/45822f2c09e0dbdfa6659b08f0b35ab8bda910d29f4abb107dfbf88f323e34f1
some of my computers' behavior are different when I using a proxy code by golang, with https. While http is always ok.
for example:
for some normal computer ( Mac )
the right one:
all_proxy=ip:port curl -vv -k https://baidu.com
---> it works
In some computer (also, Mac):
all_proxy=ip:port curl -vv -k https://baidu.com
* Uses proxy env variable all_proxy == 'ip:port'
* Trying ip...
* TCP_NODELAY set
* Connected to ip (ip) port port (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to baidu.com:443
> CONNECT baidu.com:443 HTTP/1.1
> Host: baidu.com:443
> User-Agent: curl/7.64.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Date: Fri, 07 May 2021 06:28:57 GMT
< Transfer-Encoding: chunked
* Ignoring Transfer-Encoding in CONNECT 200 response
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* 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):
* LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to baidu.com:443
* Closing connection 0
curl: (35) LibreSSL SSL_connect: SSL_ERROR_SYSCALL in connection to baidu.com:443
--- > it does not work ?!
However, in this case, if I use sudo , it works!
sudo all_proxy=ip:port curl -vv -k https://baidu.com
* Uses proxy env variable all_proxy == 'ip:port'
* Trying ip...
* TCP_NODELAY set
* Connected to ip (ip) port port (#0)
* allocate connect buffer!
* Establish HTTP proxy tunnel to baidu.com:443
> CONNECT baidu.com:443 HTTP/1.1
> Host: baidu.com:443
> User-Agent: curl/7.64.1
> Proxy-Connection: Keep-Alive
>
< HTTP/1.1 200 OK
< Date: Fri, 07 May 2021 06:27:18 GMT
< Transfer-Encoding: chunked
* Ignoring Transfer-Encoding in CONNECT 200 response
<
* Proxy replied 200 to CONNECT request
* CONNECT phase completed!
* 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):
* CONNECT phase completed!
* CONNECT phase completed!
* 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-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
* subject: C=CN; ST=\U5317\U4EAC\U5E02; O=BeiJing Baidu Netcom Science Technology Co., Ltd; CN=www.baidu.cn
* start date: Jan 25 00:00:00 2021 GMT
* expire date: Feb 24 23:59:59 2022 GMT
* issuer: C=US; O=DigiCert Inc; CN=DigiCert Secure Site Pro CN CA G3
* SSL certificate verify ok.
> GET / HTTP/1.1
> Host: baidu.com
> User-Agent: curl/7.64.1
> Accept: */*
>
< HTTP/1.1 302 Moved Temporarily
< Server: bfe/1.0.8.18
< Date: Fri, 07 May 2021 06:27:18 GMT
< Content-Type: text/html
< Content-Length: 161
< Connection: keep-alive
< Location: http://www.baidu.com/
<
<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>bfe/1.0.8.18</center>
</body>
</html>
* Connection #0 to host ip left intact
* Closing connection 0
----- I totally don't know why.
It seems hang on the first "HELLO" after the proxy connect to the target website and "HELLO" didn't send out.
this problem only occur if the proxy server is code by golang, if I use a proxy server code by python, it will work.
also, if the proxy server is on the same computer, it will work in localhost only:
all_proxy=127.0.0.1:8080 curl -vv -k https://baidu.com ---> work!
all_proxy=192.168.0.1:8080 curl -vv -k https://baidu.com ---> not work!
pls help.
I am looking to cut the task number which is highlighted in the output. However, normal grep or sed commands or redirection to text file for getting the desired output is not working. As the curl is writing on the terminal screen, these operations arent working. Please suggest.
vcap#jumpbox-sagdf-staging:~ $ curl -v -s -k 'https://admin:88uudjdjd#10.19.1.1:25555/deployments/concourse/vms?format=full'
* Hostname was NOT found in DNS cache
Trying 10.19.1.1....
Connected to 10.19.1.1 (10.19.1.1) port 25555 (#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-AES128-GCM-SHA256
Server certificate:
subject: CN=director
start date: 2017-06-20 13:19:23 GMT
expire date: 2019-06-20 13:19:23 GMT
issuer: CN=rootCA
SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway.
Server auth using Basic with user 'admin'
GET /deployments/concourse/vms?format=full HTTP/1.1
Authorization: Basic YWRtaW46OHdId1lEVlIwakJCZ3c=
User-Agent: curl/7.35.0
Host: 10.19.1.1:25555
Accept: /
>
< HTTP/1.1 302 Moved Temporarily
Server nginx is not blacklisted
< Server: nginx
< Date: Fri, 30 Jun 2017 04:07:19 GMT
< Content-Type: text/html;charset=utf-8
< Content-Length: 0
< Connection: keep-alive
< WWW-Authenticate: Basic realm="BOSH Director"
< Location: https://10.19.1.1/tasks/1017317
< X-XSS-Protection: 1; mode=block
< X-Content-Type-Options: nosniff
< X-Frame-Options: SAMEORIGIN
<
Connection #0 to host 10.19.1.1 left intact
Since you want to extract the piece on the right of the right-most slash of the Location: response header, I would use this:
curl -so /dev/null -w "%{redirect_url}\n" $URL | sed 's:.*/::g'
so that with your original URL use case it would look like (I added the -k back in this version):
curl -kso /dev/null -w "%{redirect_url}\n" 'https://admin:88uudjdjd#10.19.1.1:25555/deployments/concourse/vms?format=full' | sed 's:.*/::g'
(Do note that you've exposed your user name and password to the world here...)
Using the code here http://fusion-tables-api-samples.googlecode.com/svn/trunk/ftapi/ [1] I can produce a successful response by running [2] cat PATHTOMYDATA.csv | ./ftupload.sh MYTABLEID . But I see no change in the Fusion Table specified by MYTABLEID
Some things I've tried:
-upload to new, blank table with correct number of columns ... same result
-upload to other table with incorrect number of columns ... receive error about columns
-various modifications of the curl command in ftupload.sh [3]
--remove -s -S (so can get full output) ... same result
--giving file as parameter rather than streaming standard input [4] ... same result
--sending without --data-binary flag.. produces HTTP/1.1 405 Method Not Allowed
--sending with -v flag, produces the following log of HTTP request [5]
[1] Which is functionally identical to http://fusion-tables-api-samples.googlecode.com/svn/trunk/ftapi, since that code doesn't change from rev56 to rev57
[2] On bash/Ubuntu
[3] originally:
curl -s -S --data-binary #- -H "Authorization: Bearer $access_token" \
-H "Content-Type: application/octet-stream" \
"https://www.googleapis.com/upload/fusiontables/v1/tables/$1/import"
[4]
curl -s -S --data-binary #PATHTOMYDATA.csv -H "Authorization: Bearer $access_token" \
-H "Content-Type: application/octet-stream" \
"https://www.googleapis.com/upload/fusiontables/v1/tables/$1/import"
[5]
* About to connect() to www.googleapis.com port 443 (#0)
* Trying 74.125.29.95... connected
* 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-RC4-SHA
* Server certificate:
* subject: C=US; ST=California; L=Mountain View; O=Google Inc; CN=*.googl eapis.com
* start date: 2013-06-19 12:43:04 GMT
* expire date: 2013-10-31 23:59:59 GMT
* subjectAltName: www.googleapis.com matched
* issuer: C=US; O=Google Inc; CN=Google Internet Authority
* SSL certificate verify ok.
> POST /upload/fusiontables/v1/tables/MYTABLEID/import HTTP/1.1
> User-Agent: curl/7.22.0 (x86_64-pc-linux-gnu) libcurl/7.22.0 OpenSSL/1.0.1 zli b/1.2.3.4 libidn/1.23 librtmp/2.3
> Host: www.googleapis.com
> Accept: */*
> Authorization: Bearer ya29.AHES6ZTZG_aqdYJYg-JgeAMOHOQIJOYFWAaGzzDWDlP2OKzpof8 MIkuPUA
> Content-Type: application/octet-stream
> Content-Length: 50
>
* upload completely sent off: 50out of 50 bytes
< HTTP/1.1 200 OK
< ETag: "TMh8SguO4XpkjXICbs8TpuVjR5I/BKKfZXT4y10ldV7sI6nrMgeYYNw"
< Content-Type: application/json
< Content-Length: 60
< Date: Fri, 28 Jun 2013 15:09:00 GMT
< Server: HTTP Upload Server Built on Jun 25 2013 11:32:14 (1372185134)
<
{
"kind": "fusiontables#import",
"numRowsReceived": "1"
}
* Connection #0 to host www.googleapis.com left intact
* Closing connection #0
* SSLv3, TLS alert, Client hello (1):
There was a bug that swallowed the first row for uploads from the API. It was introduced around April 2013 and is fixed as of 8/1/2013.