headers
Chandrakant Bagul -ERS, HCL Tech | 1 Feb 05:31
Favicon

Invalid proxy settings

Hi All,

I have proxy server(Squid) with IP address of 192.168.1.12.
In my curl code I use following code to set proxy settings:
        curl_easy_setopt(pCurl, CURLOPT_PROXY, proxyAddress);
        curl_easy_setopt(pCurl, CURLOPT_PROXYPORT, port);
& check response code after execution using
          curl_easy_getinfo(pCurl, CURLINFO_RESPONSE_CODE, &respCode);  //If respCode
is 200 means Internet connectivity available

I have 3 cases to test this setup
1. Incorrect proxy server address:
        If I provide proxy server address as "192.168.1.45" or "http://wrong.proxyserver.com", then
        Response code is 0, means internet connection is not available.
2. Correct Proxy server address
        If I provide proxy server address as "192.168.1.12", then
        Response code is 200, means internet connection is available.
3. Invalid proxy server address
        If I provide proxy server address as "/192.168.1.45" or "/./././", then
        Response code is 200, means internet connection is available. But
        here proxy is invalid, but still respCode return as 200.
        This is buggy situation.

Please let me know how to resolve this issue(by doing some extra checks or
something).

Thanks & regards,
Chandrakant

::DISCLAIMER::
(Continue reading)

Permalink | Reply | 7 comments |
headers
Mischa Salle | 1 Feb 11:55
Picon
Picon
Favicon

SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS commit

Hi,

I'd like to continue the discussion about commit
https://github.com/bagder/curl/commit/db1a856b4f7cf6ae334fb0656b26a18eea317000

The option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is necessary to prevent a
number of (older) broken SSL implementation to lock up. Basically what
seems to happen is that they get confused about the empty fragments and
interpret them as an EOF.

With the above curl commit enabled, a curl-based client times out with
such a service.
I have seen this in a openjdk 1.6 based service on a Centos 5.7 with
java-1.6.0-openjdk{,-devel}-1.6.0.0-1.23.1.9.10.el5_7
On the other hand that service also uses other SSL stuff such as
not-yet-commons-ssl-0.3.9, jetty-sslengine-6.1.18 and bcprov-jdk15-1.45
which might add their own bugs.

I agree it's good to have the option removed as it is strictly speaking
a vulnerability, but the question is how to deal with all the older
servers...?

    Mischa
--

-- 
Nikhef                      Room  H155
Science Park 105            Tel.  +31-20-592 5102
1098 XG Amsterdam           Fax   +31-20-592 5155
The Netherlands             Email msalle <at> nikhef.nl
  __ .. ... _._. .... ._  ... ._ ._.. ._.. .._..
(Continue reading)

Permalink | Reply | 20 comments |
headers
Johannes Bauer | 1 Feb 15:38
Picon
Picon

Re: http_proxy and https_proxy

On 31.01.2012 23:42, Daniel Stenberg wrote:

>> Would you accept a patch to make curl fall back to http_proxy if
>> neither https_proxy nor all_proxy are set? Or do you think this should
>> be handled by git? Or not at all?
[...]
> But I'm open to listen to what others have to say!

Please don't include this.

The rationale is as follows: interpretation of command-line parameters
is confusing enough in Unixoid environments already. There are
applications that use various spellings of the common proxy environment
variables (with underscore and without, all uppercase or all lowercase).
Precedence of these variable if in conflict (i.e. what if ALL_PROXY and
http_proxy is set at the same time? What if socks_proxy is also set?)
also differs over applications, which makes matters worse.

To sum it all up and to reiterate my point: Envrionment variables to
change proxy settings are confusing enough already without yet another
special set of exceptions and/or rules. Please keep the KISS principle
in mind.

All the best,
Joe
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 1 Feb 22:28
Picon
Favicon
Gravatar

(lib)curl meetup at FOSDEM on this Sunday!

Hi friends,

Recall my call for a curl meetup at Fosdem? 
http://daniel.haxx.se/blog/2011/09/15/curl-meetup-at-fosdem-2012/

The interest seems to be far from huge, but since there may still be one or 
two hackers who want to just meet and have a chat and perhaps get a face 
attached to the name/email I thought that we meet up:

  Where: At the FOSDEM main entrance [*]
  Time:  13:00 (1pm)
  Date:  Feb 5th 2012
  How:   I'll make sure to have/show a very fancy hand written paper with
         something written on it that will include the word "curl" - or
         similar.

Bring your questions, ideas and whatever! =) If this particular time isn't 
good for you, I'll be around at Fosdem during both days.

[*] = http://fosdem.org/2012/maps/campus

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 0 comments |
headers
Daniel Stenberg | 2 Feb 22:58
Picon
Favicon
Gravatar

Re: SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS commit

On Wed, 1 Feb 2012, Mischa Salle wrote:

> The option SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS is necessary to prevent a 
> number of (older) broken SSL implementation to lock up. Basically what seems 
> to happen is that they get confused about the empty fragments and interpret 
> them as an EOF.

Right, and from what I hear that's one of the reasons why NSS(?) chose a 
different route to mitigate the problem:

http://thread.gmane.org/gmane.comp.encryption.openssl.devel/19772

> I agree it's good to have the option removed as it is strictly speaking a 
> vulnerability, but the question is how to deal with all the older 
> servers...?

As a short term fix you can use CURLOPT_SSL_CTX_FUNCTION and set whatever 
option you like to openssl. And of course to complain to anyone who still run 
servers that can't deal with this.

As a longer term fix I could see us accepting a patch that allows a user to 
explicitly ask for diabling of this work-around.

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
(Continue reading)

Permalink | Reply | 19 comments |
headers
Daniel Stenberg | 5 Feb 11:49
Picon
Favicon
Gravatar

Re: Invalid proxy settings

On Wed, 1 Feb 2012, Chandrakant Bagul -ERS, HCL Tech wrote:

> 3. Invalid proxy server address
>        If I provide proxy server address as "/192.168.1.45" or "/./././", then
>        Response code is 200, means internet connection is available. But
>        here proxy is invalid, but still respCode return as 200.
>        This is buggy situation.

I believe this is because if libcurl fails to parse/accept the proxy string it 
won't get set and then it runs without proxy. I think that is the correct 
behavior, but you should of course get an error code back when you used 
setopt() to set that proxy. Did you?

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 6 comments |
headers
Daniel Stenberg | 5 Feb 12:40
Picon
Favicon
Gravatar

Re: SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS commit

On Thu, 2 Feb 2012, Daniel Stenberg wrote:

> As a longer term fix I could see us accepting a patch that allows a user to 
> explicitly ask for diabling of this work-around.

I've received and read several more cases where people experience this 
problem. I suggest we introduce a new setopt option (and corresponding command 
line option) that simply switches off this work-around for those SSL libraries 
that use it. CURLOPT_SSL_ALLOW_INSECURE or something like that. Possibly even 
more specific like CURLOPT_SSL_NO_EMPTY_FRAGMENTS...

Opinions?

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 18 comments |
headers
Alessandro Ghedini | 5 Feb 14:10
Picon
Gravatar

Re: SSL_OP_DONT_INSERT_EMPTY_FRAGMENTS commit

On Sun, Feb 05, 2012 at 12:40:14PM +0100, Daniel Stenberg wrote:
> On Thu, 2 Feb 2012, Daniel Stenberg wrote:
> 
> >As a longer term fix I could see us accepting a patch that allows
> >a user to explicitly ask for diabling of this work-around.
> 
> I've received and read several more cases where people experience
> this problem. I suggest we introduce a new setopt option (and
> corresponding command line option) that simply switches off this
> work-around for those SSL libraries that use it.
> CURLOPT_SSL_ALLOW_INSECURE or something like that. Possibly even
> more specific like CURLOPT_SSL_NO_EMPTY_FRAGMENTS...
> 
> Opinions?

That is the same solution I have thought in response to Debian bug 
#658276 [0]. I was not sure about the option naming, but
CURLOPT_SSL_NO_EMPTY_FRAGMENTS (and maybe --ssl-no-empty-fragments) seems 
the best to me.

Cheers

[0] http://bugs.debian.org/658276

--

-- 
perl -E'$_=q;$/= @{[@_]};and s;\S+;<inidehG ordnasselA>;eg;say~~reverse'
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
(Continue reading)

Permalink | Reply | 17 comments |
headers
Lijo Antony | 5 Feb 16:30
Picon
Favicon

Correct way to retrieve error code in case of multi interface

Hello,

I am using curl multi interface (socket_action) for http/https transfers 
and would like to know the correct way to retrieve error codes 
associated with a transfer.

Currently I am using curl_easy_getinfo with CURLINFO_RESPONSE_CODE and 
CURLINFO_OS_ERRNO to do this. But this doesn't give the specific error 
code like curl_easy_perform would return. For example, when network is 
down, I get CURLINFO_RESPONSE_CODE and CURLINFO_OS_ERRNO as 0, even 
though I can see debug log as "Could not resolve host: <url> (Could not 
contact DNS servers)".

In error scenarios like these (dns error, connect error, ssl errors 
etc), I would like to get the specific error code. How can I achieve this?

Thanks in advance,
-lijo
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 1 comment |
headers
Lijo Antony | 6 Feb 14:03
Picon
Favicon

Re: Correct way to retrieve error code in case of multi interface

On 02/05/2012 07:30 PM, Lijo Antony wrote:

> Currently I am using curl_easy_getinfo with CURLINFO_RESPONSE_CODE and
> CURLINFO_OS_ERRNO to do this. But this doesn't give the specific error
> code like curl_easy_perform would return. For example, when network is
> down, I get CURLINFO_RESPONSE_CODE and CURLINFO_OS_ERRNO as 0, even
> though I can see debug log as "Could not resolve host: <url> (Could not
> contact DNS servers)".
>
> In error scenarios like these (dns error, connect error, ssl errors
> etc), I would like to get the specific error code. How can I achieve this?
>

I have found the CURLcode variable "result", which is present inside the 
CURLMsg structure returned by the function curl_multi_info_read. I guess 
I was looking for this and is giving me the specific error codes as 
expected.

Thanks,
-lijo
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html
Permalink | Reply | 0 comments |

Gmane