Today I was working with a big data company’s API, trying to pull some information using their documentation and a simple
curl command via the command line.
The problem was I could use the browser and see the results of what amounts to a GET request via the URL. The results came back fine. However, when using
curl or any variation or flag I could think of, the results were either an error or blank.
The first issue I ran into was an error like this:
curl: (3) [globbing] bad range in column 192
That was easily solved by using:
$ curl --globoff "https://whatever.com/my/path/to/the/api/endpoint"
However, once that was fixed, the results were blank. No response really. So, let’s go verbose…
$ curl -v --globoff "https://whatever.com/my/path/to/the/api/endpoint"
And the results were …
* Hostname was NOT found in DNS cache
* Trying ##.###.###.##...
* Connected to whatever.com (##.###.###.##) port 443 (#0)
* TLS 1.2 connection using TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
* Server certificate: .whatever.com
* Server certificate: Gandi Standard SSL CA
* Server certificate: UTN-USERFirst-Hardware
* Server auth using Basic with user 'xxxxxxxxxxx'
GET /my/path/to/the/api/endpoint HTTP/1.1
Authorization: Basic xxxxxxxxxxxxxx
HTTP/1.1 400 BAD_REQUEST
Closing connection 0
So, now what?
The Source of The Issue
It seems, weirdly enough, that it was my wifi router. It could be that, or any kind of proxy, really. The issue is that some routers don’t work with
curl and the IPV6 standard well.
No, really. I know, I didn’t believe it either.
So, how do you test if that’s the issue, and how do you get around it?
wget command which does something similar as a
$ wget -qO- -4 "https://whatever.com/my/path/to/the/api/endpoint"
If you do that, and get a response, you know your router and IPV6 got a divorce and bitterly hate each other. They won’t even speak, and your router should be in the dog house.
I hope this helps someone stop denting their forehead (or wall, whichever is harder) in the future.