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: Libcurl 7.86.0 issue with reverse proxy server
- Contemporary messages sorted: [ by date ] [ by thread ] [ by subject ] [ by author ] [ by messages with attachments ]
From: Daniel Stenberg via curl-library <curl-library_at_lists.haxx.se>
Date: Thu, 11 Jan 2024 11:21:06 +0100 (CET)
On Thu, 11 Jan 2024, Purvi Prajapati via curl-library wrote:
> We have a problem with libcurl library with big request body when IHS (IBM
> HTTP Server) is used as reverse proxy.
So libcurl is doing a plain HTTPS POST to this server? (The fact that it is a
reverse proxy is hardly something libcurl knows or cares about.) What does
"big" mean here? Is there a known size that works vs does not work?
Do you set the upload buffer size?
How does this server's behavior differ compared to a server that is not a
reverse proxy, from a client's perspective?
> Problem background: When we have a big request body, we receive this error
> message "Failure when receiving data from the peer". This is happening only
> when IHS is set as reverse proxy. This is working fine without proxy set up.
This sounds as if the POST worked and the problem is related to the response
from the server. Is it? What does the server respond, HTTP wise? Response
code, headers, size?
> We are using libcurl with GSKit.
Unfortunate, because we don't support gskit anymore in recent curl versions. I
would urge you to switch to something modern.
> Our analysis: Further digging into the curl library code, we identified that
> the issue might lie in "easy.c" file, in function "easy_transfer".
> The suspected code line is as below:
> if(!mcode)
> mcode = curl_multi_perform(multi, &still_running);
>
> If I put some delay after this code line (using sleep call), I observed that
> the issue is not happening for the failed scenario. However, this is
> creating unnecessary delay in processing the request (and still fail in very
> specific scenario of big request).
That analysis is unfortunately too course for us to act on. It does not
explain at all why the error happens but only that slowing things down might
work around the problem. We need much more detailed tracing and logging of
what exacly happened up until the problem hit.
We have done thirteen releases and 1300+ bugfixes since 7.86.0 so chances are
we already fixed this. I doubt you will find many people here who are
interested in archeology enough to go hunting for (possibly already solved)
problems in an old release for fun and for free. I am not.
> * Downgrade the library to 7.76.1 (Not accepted due to vulnerabilities)
Note that 7.86.0 has 19 vulnerabilities reported:
https://curl.se/docs/vuln-7.86.0.html
Date: Thu, 11 Jan 2024 11:21:06 +0100 (CET)
On Thu, 11 Jan 2024, Purvi Prajapati via curl-library wrote:
> We have a problem with libcurl library with big request body when IHS (IBM
> HTTP Server) is used as reverse proxy.
So libcurl is doing a plain HTTPS POST to this server? (The fact that it is a
reverse proxy is hardly something libcurl knows or cares about.) What does
"big" mean here? Is there a known size that works vs does not work?
Do you set the upload buffer size?
How does this server's behavior differ compared to a server that is not a
reverse proxy, from a client's perspective?
> Problem background: When we have a big request body, we receive this error
> message "Failure when receiving data from the peer". This is happening only
> when IHS is set as reverse proxy. This is working fine without proxy set up.
This sounds as if the POST worked and the problem is related to the response
from the server. Is it? What does the server respond, HTTP wise? Response
code, headers, size?
> We are using libcurl with GSKit.
Unfortunate, because we don't support gskit anymore in recent curl versions. I
would urge you to switch to something modern.
> Our analysis: Further digging into the curl library code, we identified that
> the issue might lie in "easy.c" file, in function "easy_transfer".
> The suspected code line is as below:
> if(!mcode)
> mcode = curl_multi_perform(multi, &still_running);
>
> If I put some delay after this code line (using sleep call), I observed that
> the issue is not happening for the failed scenario. However, this is
> creating unnecessary delay in processing the request (and still fail in very
> specific scenario of big request).
That analysis is unfortunately too course for us to act on. It does not
explain at all why the error happens but only that slowing things down might
work around the problem. We need much more detailed tracing and logging of
what exacly happened up until the problem hit.
We have done thirteen releases and 1300+ bugfixes since 7.86.0 so chances are
we already fixed this. I doubt you will find many people here who are
interested in archeology enough to go hunting for (possibly already solved)
problems in an old release for fun and for free. I am not.
> * Downgrade the library to 7.76.1 (Not accepted due to vulnerabilities)
Note that 7.86.0 has 19 vulnerabilities reported:
https://curl.se/docs/vuln-7.86.0.html
-- / daniel.haxx.se | Commercial curl support up to 24x7 is available! | Private help, bug fixes, support, ports, new features | https://curl.se/support.html -- Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library Etiquette: https://curl.se/mail/etiquette.htmlReceived on 2024-01-11