Buy commercial curl support from WolfSSL. We help you work
out your issues, debug your libcurl applications, use the API, port to new
platforms, add new features and more. With a team lead by the curl founder
himself.
Re: curl_easy_recv and SIGPIPE
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Tomalak Geret'kal via curl-library <curl-library_at_cool.haxx.se>
Date: Mon, 26 Oct 2020 23:36:02 +0000
On 26/10/2020 23:30, Daniel Stenberg wrote:
> On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>> Based on the `#if defined`s in sigpipe.h, from what I can
>> tell, curl doesn't protect anything from SIGPIPE unless
>> OpenSSL or MBEDTLS are in use. I don't know whether your
>> intention was to protect against SIGPIPE more broadly or
>> not.
>
> We make sure that no writes to the socket allows SIGPIPE
> by using MSG_NOSIGNAL or SO_NOSIGPIPE, depending on target
> system.
Ok - so not intending to cover the case where an error is
raised on the socket (by, e.g. the OS closing it for you)
and recv then triggers SIGPIPE. That's fine if intended
behaviour.
>
>> Admittedly my build is using a "non-standard" config-ios.h,
>
> ... and I don't know which of those systems, if any, works
> on iOS. Maybe you need a third approach there.
SECTRANSP is the correct approach and works fine (i.e. using
the OS's secure transport layer). It's just that due to the
defines in sigpipe.h, none of the sigpipe_ignore calls in
the library do anything at all. But, again, that's fine for
me - turns out it's not invoked in curl_easy_recv anyway.
>
>> but the result is USE_SECTRANSP which I believe is
>> supported and also available for use by Mac builds.
>> Unless I'm missing something, this condition would also
>> cause a SIGPIPE
>
> I don't think so, since it uses callbacks to our code for
> the actual sending to the socket and we set the socket to
> not cause sigpipes. At least that's the intention.
>
That only helps you if the socket still exists.
On wake from suspend on iPad, the socket does not exist any
more, an event is raised on its FD, then you get a failed
recv (with a SIGPIPE unless it's been externally
SIG_IGNored), with errno ENOTCONN.
There exists no protection in libcurl for error cases like
this, and I think it's clear at this point that you never
intended for there to be: the only question is, do you want
there to be!
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27
Date: Mon, 26 Oct 2020 23:36:02 +0000
On 26/10/2020 23:30, Daniel Stenberg wrote:
> On Mon, 26 Oct 2020, Tomalak Geret'kal via curl-library
> wrote:
>
>> Based on the `#if defined`s in sigpipe.h, from what I can
>> tell, curl doesn't protect anything from SIGPIPE unless
>> OpenSSL or MBEDTLS are in use. I don't know whether your
>> intention was to protect against SIGPIPE more broadly or
>> not.
>
> We make sure that no writes to the socket allows SIGPIPE
> by using MSG_NOSIGNAL or SO_NOSIGPIPE, depending on target
> system.
Ok - so not intending to cover the case where an error is
raised on the socket (by, e.g. the OS closing it for you)
and recv then triggers SIGPIPE. That's fine if intended
behaviour.
>
>> Admittedly my build is using a "non-standard" config-ios.h,
>
> ... and I don't know which of those systems, if any, works
> on iOS. Maybe you need a third approach there.
SECTRANSP is the correct approach and works fine (i.e. using
the OS's secure transport layer). It's just that due to the
defines in sigpipe.h, none of the sigpipe_ignore calls in
the library do anything at all. But, again, that's fine for
me - turns out it's not invoked in curl_easy_recv anyway.
>
>> but the result is USE_SECTRANSP which I believe is
>> supported and also available for use by Mac builds.
>> Unless I'm missing something, this condition would also
>> cause a SIGPIPE
>
> I don't think so, since it uses callbacks to our code for
> the actual sending to the socket and we set the socket to
> not cause sigpipes. At least that's the intention.
>
That only helps you if the socket still exists.
On wake from suspend on iPad, the socket does not exist any
more, an event is raised on its FD, then you get a failed
recv (with a SIGPIPE unless it's been externally
SIG_IGNored), with errno ENOTCONN.
There exists no protection in libcurl for error cases like
this, and I think it's clear at this point that you never
intended for there to be: the only question is, do you want
there to be!
Cheers
-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2020-10-27