Curl receiving a 302 or something, weird

curl

I have the following curl command

curl -X POST -w "\nRESULT CODE:%{http_code}\n" --insecure --header "Content-Type:application/json" --user robot-midc:1ZSXM7 -d @table.json http://databus.nrel.gov/api/registerV1

and I receive the following response

<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx/1.2.4</center>
</body>
</html>

hmmm, how do I check the actual http code, was it a 302 as curl docs claim they follow redirects so I am not sure what is going on?

thanks,
Dean

hmmm, maybe this is a bug in that curl doesn't follow http to https redirect like browsers do???? My issue was simply that the load balancer always redirects to https and I had http on the line there….so odd, it would be nice for curl to give a better error in that it doesn't redirect to https (ie. doesn't follow all redirects like the documentation states).

Best Answer

Pass -L to cURL and it will follow the 302.

Related Solutions

Difference between `curl -I` and `curl -X HEAD`

It seems the difference has to do with the Content-Length header and how it is treated by both commands.

But before going into that, curl -X HEAD does not give any output because, by default, curl does not print headers if switch -i is not provided (not needed on -I though).

In any case, curl -I is the proper way to fetch the headers. It just ask for the header and close the connection.

On the other hand curl -X HEAD -i will wait for the transmission of the number of bytes stated by Content-Length. In the case no Content-Length is not specified, I guess it will wait for some data or for that particular header.

Some examples that shows this behaviour:

$ curl -X HEAD -i http://www.elpais.es
HTTP/1.1 301 Moved Permanently
Server: AkamaiGHost
Content-Length: 0
Location: http://www.elpais.com/
Date: Wed, 12 May 2010 06:35:57 GMT
Connection: keep-alive

Because Content-Length is 0, in this case both commands behave the same. And the connection is closed afterwards.

$ curl -X HEAD -i http://slashdot.org
HTTP/1.1 200 OK
Server: Apache/1.3.41 (Unix) mod_perl/1.31-rc4
SLASH_LOG_DATA: shtml
X-Powered-By: Slash 2.005001296
X-Bender: Since I love you all so much, I'd like to give everyone hugs.
X-XRDS-Location: http://slashdot.org/slashdot.xrds
Cache-Control: no-cache
Pragma: no-cache
Content-Type: text/html; charset=iso-8859-1
Content-Length: 115224
Date: Wed, 12 May 2010 06:37:20 GMT
X-Varnish: 1649060825 1649060810
Age: 1
Connection: keep-alive

curl: (18) transfer closed with 115224 bytes remaining to read

In this case, there seems to be a timeout (probably by Varnish), so curl protests that the connection was closed before having received the Content-Length number of bytes.

By the way, look at the funny X-Bender (shown in the example) and X-Fry (try it for yourself) headers :).

Php – Curl POST – 411 Length Required

You are correct -- lighttpd doesn't support POST requests with an empty message body without a 'Content-Length' header set to zero, and CURL sends such a request. There's argument back and forth about who's right, but in my opinion, lighttpd is broken. A POST with no Content-Length and no Transfer-Encoding is perfectly legal and has no message body.

Adding -d "" causes CURL to send a Content-Length: 0 header, which resolves the problem.

You could modify lighttp. Find the code that issues the 411 error and instead set the content length to zero.

Best Answer

Related Solutions

Difference between `curl -I` and `curl -X HEAD`

Php – Curl POST – 411 Length Required

Related Topic