Why is cURL returning “additional stuff not fine”?

Question

I am writing a Python application that queries social media APIs via cURL. Most of the different servers I query (Google+, Reddit, Twitter, Facebook, others) have cURL compl

Answer 1

I disagree with this - I get the same message when attempting to call a website via a BIGIP LTM external VIP address.

For example:

I call the website http://11five.10.10.10/index.html (IP address is random in this case). The BIG F5 should be load balancing the traffic to two internal web servers (17two.20.0.10 and 17two.20.0.11) via a pool associated with the virtual server.

In this case, the request coming from the external source (Internal Client) to the VIP address on TCP 80 should round robin between the two web servers. What I find is that all the servers receive an initial SYN packet and never a SYN-ACK back.

If I sit on a terminal within the local subnet where the real servers reside, I can "wget" the index.html webpage - sourced from 17two.20.0.11 to http://17two.20.0.10}/index.html.

Coming from external, I get the *additional stuff not fine transfer.c:1037 0 0 message.

You are right in saying that it's a built in debug mechanism for CURL in older revisions of the libcurl library but I disagree with the below statement;

A bug in curl, or the way you're using it.
Something wrong with your network setup (e.g., your ISP cuts you off for making too many outgoing connections or using too many bytes in 30 minutes).
Something you're doing is making the servers think you're a spammer/DoS attacker/whatever and they're blocking you.

What ever is causing this is due to a networking issue within the environment, I.E... the web servers cannot return the traffic back to the original source and hence displays this error or two, there is something wrong with the request header and the response back from the web server.

In this case I will opt to say that the original issue is more likely as when I performed a curl using different URis on the original request from a test host in the local subnet, I could retrieve the index.html web page fine. This implies that the server is listening and accepting connections using the FQDN and short name of the server.

I believe that this error is there to suggest that curl received a response that it is unsure on and therefore produces the above error. Without developing curl or reading the source code, I cannot comment further.

Any additional response that questions this logic would be welcome - all up for learning new things.

Andy