Re: libCurl 7.61.1: no response message received indicating dead connection

[Francisco Sedano Crippa (fsedanoc) via curl-library]

Hello folks,

I'm also impacted by this issue - Does anybody have any objection if we submit 
a PR to fix the timer issue Bernd is mentioning?

Thanks,

. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering | 
CSG Enterprise Access and Services Group (EASG)
 

On 09.10.18, 16:06, "curl-library on behalf of Bernd Mueller (bermuell) via 
curl-library"  wrote:

Hello,

I’m reaching out to you as we saw a functional change in libCurl which 
might not have been intended or to get advice how to cope with it on 
application side.

When moving from libCurl version 7.61.0 to 7.61.1 a response message is not 
received anymore
in case of ‘dead connection’ (‘stream_error’ in multi.c). Where as we
received in 7.61.0 a response message with error code 7="Couldn't connect 
to server”.

It looks like that the reason is the introduction of the state function 
‘Curl_init_completed’ for state CURLM_STATE_COMPLETED which stops all the 
timers by calling ‘Curl_expire_clear’.

In the above mentioned error case 
* “Completed” state is the next state
* as a result, all timers are stopped (which was not the case in v7.61.0)
* response message which is created afterwards 
(https://github.com/curl/curl/blob/432eb5f5c254ee8383b2522ce597c9219877923e/lib/multi.c#L2133,
 
with error code indicating the ’timed out’) is never received by the 
application because of the stopped timers...I assume.

I tried not stopping/clearing the timers in that ‘error’ situation and then 
we receive on application side the response message with the expected error 
code in ‘msg->extmsg.data.result’.

Is there a change required on application side to get informed about the 
failing attempt to send the message in that situation?

We’re using
- libCurl (7.61.1).
- multi interface to connect to a server using HTTPS.

thanks a lot for your help,
Bernd


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: today: feature freeze

[Francisco Sedano Crippa (fsedanoc)]

Hello folks,

One quick question on this, since I'm not familiar with the release process. 
Once the freeze was done on 21st, when is the official release expected to go 
live?

Thanks!


. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering | 
CSG Enterprise Access and Services Group (EASG)
 
On 21.02.18, 09:29, "curl-library on behalf of Daniel Stenberg" 
 wrote:

Hi team!

Today is curl feature freeze day for 7.59.0. If your change isn't merged by 
the end of today it will have to wait until next feature window opens again 
after the pending release.

Starting now, we will only merge bug fixes until we ship the next release - 
curl 7.59.0 is planned to ship on March 21. We welcome all help to get to 
know 
about bugs, reproduce bugs and perhaps most of all: get fixes for existing 
bugs!

For the curious, the current in-progress RELEASE-NOTES for what will ship 
in 
the next release is always available here:

   https://curl.haxx.se/dev/release-notes.html

Thanks!

-- 

  / daniel.haxx.se
---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Callback for socket options in curl + c-ares

[Francisco Sedano Crippa (fsedanoc)]

Hi folks,
I went ahead and created a patch to provide a new libcurl CB, that will be 
called just before a new resolver is called, and the resolver data (channel in 
case of cares) is passed. This solves the problem perfectly for my use case.
 
Initially I thought about just adding a new easy_getinfo option to retrieve it, 
but since libcurl can create easy_handles on it's own, I feel this callback 
approach is a safer option.

Are you guys OK with that approach? If that's ok I can send the pull request 
for review.

Thanks,

. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering | 
CSG Enterprise Access and Services Group (EASG)
 
On 14.02.18, 00:54, "curl-library on behalf of Francisco Sedano Crippa 
(fsedanoc)" <curl-library-boun...@cool.haxx.se on behalf of fseda...@cisco.com> 
wrote:

Hello Daniel,

I feel it would be useful in some other cases - for example dealing with 
multi-vrf sockets, currently you can bind the libcurl socket to any vrf you 
want, but no way to do that with the underlying c-ares.

Wouldn't be enough to provide access to the c-ares channel (which is in 
curl_easy->state.resolver if I'm not wrong)? Once I create my easy socket and 
the c-ares channel is created, I could just use 
ares_set_socket_configure_callback on the channel and I'd be done. Anything 
else I'm missing?

Thanks,


. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering 
| CSG Enterprise Access and Services Group (EASG)
 
On 13.02.18, 23:49, "curl-library on behalf of Daniel Stenberg" 
<curl-library-boun...@cool.haxx.se on behalf of dan...@haxx.se> wrote:

    On Tue, 13 Feb 2018, Francisco Sedano Crippa (fsedanoc) wrote:

> Ideally I’d like to setup a callback with 
> ares_set_socket_configure_callback(), but in order to do so, I need 
access 
> to internal libcurl c-ares channel, which is embedded in the 
Curl_easy 
> structure.
>
> Is there any way to access such c-ares channel so I can properly 
intercept 
> c-ares socket usage, like we can do with CURLOPT_OPENSOCKETFUNCTION 
in 
> libcurl?

No, that's something we've not felt the need for before... I can't 
think of 
any other way to offer such a feature than to add a special and 
dedicated "set 
socket options" callback for c-ares or perhaps rather for "the resolver 
back-end". (There's work ongoing in making the resolver back-end 
totally 
pluggable which then possibly also appreciate such an ability.)

-- 

  / daniel.haxx.se


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Re: Callback for socket options in curl + c-ares

[Francisco Sedano Crippa (fsedanoc)]

Hello Daniel,

I feel it would be useful in some other cases - for example dealing with 
multi-vrf sockets, currently you can bind the libcurl socket to any vrf you 
want, but no way to do that with the underlying c-ares.

Wouldn't be enough to provide access to the c-ares channel (which is in 
curl_easy->state.resolver if I'm not wrong)? Once I create my easy socket and 
the c-ares channel is created, I could just use 
ares_set_socket_configure_callback on the channel and I'd be done. Anything 
else I'm missing?

Thanks,


. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering | 
CSG Enterprise Access and Services Group (EASG)
 
On 13.02.18, 23:49, "curl-library on behalf of Daniel Stenberg" 
<curl-library-boun...@cool.haxx.se on behalf of dan...@haxx.se> wrote:

On Tue, 13 Feb 2018, Francisco Sedano Crippa (fsedanoc) wrote:

> Ideally I’d like to setup a callback with 
> ares_set_socket_configure_callback(), but in order to do so, I need 
access 
> to internal libcurl c-ares channel, which is embedded in the Curl_easy 
> structure.
>
> Is there any way to access such c-ares channel so I can properly 
intercept 
> c-ares socket usage, like we can do with CURLOPT_OPENSOCKETFUNCTION in 
> libcurl?

No, that's something we've not felt the need for before... I can't think of 
any other way to offer such a feature than to add a special and dedicated 
"set 
socket options" callback for c-ares or perhaps rather for "the resolver 
back-end". (There's work ongoing in making the resolver back-end totally 
pluggable which then possibly also appreciate such an ability.)

-- 

  / daniel.haxx.se


---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html

Callback for socket options in curl + c-ares

[Francisco Sedano Crippa (fsedanoc)]

Hello folks,

In our environment, we need to setup some socket options before sockets can be 
used, and we need to use curl + c-ares.

Ideally I’d like to setup a callback with ares_set_socket_configure_callback(), 
but in order to do so, I need access to internal libcurl c-ares channel, which 
is embedded in the Curl_easy structure.

Is there any way to access such c-ares channel so I can properly intercept 
c-ares socket usage, like we can do with CURLOPT_OPENSOCKETFUNCTION in libcurl?

Thanks!


. .:|:.:|:. Francisco Sedano  | CCIE 14859, Tech Lead Software Engineering | 
CSG Enterprise Access and Services Group (EASG)

---
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette:   https://curl.haxx.se/mail/etiquette.html