[libcurl] Request to nginx return 407

[tlebreton]

Hello community !

TL;DR

Call our Nginx server with libcurl make 407 everytime, but never with command curl under Raspbian 8

I did this

We have a soft under Qt that does some request to our Nginx server on localhost :

curl_global_init( CURL_GLOBAL_ALL );
mCurlPtr = CurlPtr(curl_easy_init());
curl_easy_setopt(mCurlPtr.get(), CURLOPT_WRITEFUNCTION, GsNetwork::writeCallback);
curl_easy_setopt(mCurlPtr.get(), CURLOPT_WRITEDATA, &mReadBuffer);
curl_easy_setopt(mCurlPtr.get(), CURLOPT_SSL_VERIFYHOST, 0L);
curl_easy_setopt(mCurlPtr.get(), CURLOPT_URL, "http://localhost/.....");
curl_easy_setopt(mCurlPtr.get(), CURLOPT_VERBOSE, 1L);

//Does some stuff with callback
curl_easy_reset(mCurlPtr.get());

We get a 407 http error everytime :

* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /api/modules HTTP/1.1
Host: 127.0.0.1
Accept: */*

< HTTP/1.1 407 Proxy Authentication Required
* Server nginx/1.6.2 is not blacklisted
< Server: nginx/1.6.2
< Date: Thu, 23 Mar 2017 15:55:11 GMT
< Content-Type: application/json;charset=utf-8
< Content-Length: 39
< Connection: keep-alive
< 
* Connection #0 to host 127.0.0.1 left intact
curl_easy_perform() failed: No error
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /api/systems/usb HTTP/1.1
Host: 127.0.0.1
Accept: */*

< HTTP/1.1 200 OK
* Server nginx/1.6.2 is not blacklisted
< Server: nginx/1.6.2
< Date: Thu, 23 Mar 2017 15:55:12 GMT
< Content-Type: application/json;charset=utf-8
< Content-Length: 14
< Connection: keep-alive
< 
* Connection #0 to host 127.0.0.1 left intact
curl_easy_perform() failed: No error
Thread launch : RUNNING  true
* Hostname was NOT found in DNS cache
*   Trying 127.0.0.1...
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /api/settings/listening HTTP/1.1
Host: 127.0.0.1
Accept: */*

< HTTP/1.1 407 Proxy Authentication Required
* Server nginx/1.6.2 is not blacklisted
< Server: nginx/1.6.2
< Date: Thu, 23 Mar 2017 15:55:14 GMT
< Content-Type: application/json;charset=utf-8
< Content-Length: 39
< Connection: keep-alive
< 
* Connection #0 to host 127.0.0.1 left intact
curl_easy_perform() failed: No error

Before we run under Apache, we get all the time 200 response, but Apache eat some much power ....

Our NGinx configuration :

 server {
    listen 80 default_server;
    listen [::]:80 default_server ipv6only=on;
    server_name _;

    root /var/www/html;

        server_name _;
  index index.php index.html index.htm index.nginx-debian.html;
        location / {
                try_files $uri /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param SCRIPT_NAME $fastcgi_script_name;
                fastcgi_index index.php;
                fastcgi_pass unix:/var/run/php5-fpm.sock;
        }
}


server {
    listen 443 ssl default_server;
    listen [::]:443 default_server;

    ssl_certificate     /etc/nginx/ssl/nginx.crt;
  	ssl_certificate_key /etc/nginx/ssl/nginx.key;
  	ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
  	ssl_ciphers         HIGH:!aNULL:!MD5;

    root /var/www/html;

    server_name _;
    index index.php index.html index.htm index.nginx-debian.html;
    location / {
	    try_files $uri /index.php$is_args$args;
    }

    location ~ \.php$ {
	    try_files $uri =404;
	    fastcgi_split_path_info ^(.+\.php)(/.+)$;
	    include fastcgi_params;
	    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
	    fastcgi_param SCRIPT_NAME $fastcgi_script_name;
	    fastcgi_index index.php;
	    fastcgi_pass unix:/var/run/php5-fpm.sock;
    }
}

I expected the following

We expected a 200OK ...

Interesting fact, did : curl -k https://localhost/ourRequest or curl http://localhost/ourRequest return all the time a 200OK.

Did we have miss some configuration ?

curl/libcurl version

On Raspbian base :

curl 7.38.0 (arm-unknown-linux-gnueabihf) libcurl/7.38.0 OpenSSL/1.0.1t zlib/1.2.8 libidn/1.29 libssh2/1.4.3 librtmp/2.3
Protocols: dict file ftp ftps gopher http https imap imaps ldap ldaps pop3 pop3s rtmp rtsp scp sftp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile GSS-API SPNEGO NTLM NTLM_WB SSL libz TLS-SRP

operating system

Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
more /etc/debian_version : 8.0
QMake version 3.0
Using Qt version 5.3.2 in /usr/lib/arm-linux-gnueabihf

Thanks you 😃

[bagder]

Sounds like an nginx issue to me that you probably are better off asking in an nginx forum or in their documentation.

407 would indicate that nginx runs as a proxy since that is the response code asking for proxy authorization.

[jay]

Interesting fact, did : curl -k https://localhost/ourRequest or curl http://localhost/ourRequest return all the time a 200OK.

Just to be clear are you saying that you can retrieve the same resources from your nginx server successfully using curl but not libcurl? In your libcurl output it shows a 200 reply when you request /api/systems/usb but not the others. For example, are you saying that /api/modules which the server gives a 407 reply in libcurl is a 200 reply in curl?

If that's the case compare the versions, curl -V to libcurl's curl_version(), maybe they are different. Another thing is maybe you have some settings in your curlrc or netrc.

[Servuc]

@bagder : Perhaps :)

@jay :

Yes with our code, call localhost/api/modules give :

• 200 OK with curl (http) and curl -k (https);
• 407 with libcurl (see config below)

We will compare it on tomorrow ;)

Thanks guys

[bagder]

I really can't see a curl issue here. If the server responds differently, it is either a server issue or you're making the requests differ somehow, via a curlrc or similar. If you find something that contradicts this, feel free to comment again and explain and we can reopen this issue if so.