Hi Daniel, thanks for your replay. To first make clear my question :

1. Tunneling you say, so you're doing a CONNECT through a http proxy, right?
    Yes, its CONNECT method. I'd like to make sure that the CONNECT method
is done, and I think it can be done by "DEBUGFUNCTION", just like what you
said.

2. Isn't a "server error" then the response code to that CONNECT request?
    I've did multiple experiments like server's DNS name is wrong, or like
the proxy is down and timeout. It seems that neither http response code nor
curl error code is a reliable metric for differentiation.

I've been using DEBUGFUNCTION for a while and it indeed helps me a lot to
find the root cause. The problem is that it's not scalable and unable to be
used in production code since we've got to enable "CURL_VERBOSE", and it's
expensive. Is there any way to get the information from DEBUGFUNCTION's
my_trace callback without enabling CURL_VERBOSE ? Thank you.

Best
Kuan-Sheng

On Mon, Sep 24, 2018 at 10:56 PM Daniel Stenberg <daniel_at_haxx.se> wrote:

> On Mon, 24 Sep 2018, Kuan-Sheng Chen wrote:
>
> But please don't take this off the list...
>
> > Hi Daniel, thanks for your replay. To first make clear my question :
> >
> > 1. Tunneling you say, so you're doing a CONNECT through a http proxy,
> right?
> > Yes, its CONNECT method. I'd like to make sure that the CONNECT method
> > is done, and I think it can be done by "DEBUGFUNCTION", just like what
> you
> > said.
> >
> > 2. Isn't a "server error" then the response code to that CONNECT request?
> > I've did multiple experiments like server's DNS name is wrong, or like
> > the proxy is down and timeout. It seems that neither http response code
> nor
> > curl error code is a reliable metric for differentiation.
> >
> >
> > I've been using DEBUGFUNCTION for a while and it indeed helps me a lot to
> > find the root cause. The problem is that it's not scalable and unable to
> be
> > used in production code since we've got to enable "CURL_VERBOSE", and
> it's
> > expensive. Is there any way to get the information from DEBUGFUNCTION's
> > my_trace callback without enabling CURL_VERBOSE ? Thank you.
> >
> >
> > Best
> > Kuan-Sheng
> >
> > On Mon, Sep 24, 2018 at 2:24 PM Daniel Stenberg <daniel_at_haxx.se> wrote:
> >
> >> On Mon, 24 Sep 2018, Kuan-Sheng Chen via curl-library wrote:
> >>
> >>> I'm doing this is by making sure that libcurl has finished it's http
> >>> tunneling with the proxy, so if there's an error after that, I would
> >> make it
> >>> a server error, and vice versa.
> >>
> >> Tunneling you say, so you're doing a CONNECT through a http proxy,
> right?
> >> Isn't a "server error" then the response code to that CONNECT request?
> >>
> >>> The problem now I'm facing is that the only way to get the http
> >> tunneling
> >>> messages is throw enabling CURLOPT_VERBOSE, and to check these Verbose
> >>> message in a coding way I dumped it to a file with CURLOPT_STDERR, and
> >>> checked it line by line so as to "observer" the operation of http
> >> tunneling.
> >>
> >> At the very least you can use the DEBUGFUNCTION and get all those
> messages
> >> fed
> >> directly into your callback. There's no need to redirect to a file or
> >> similar.
> >>
> >> --
> >>
> >> / daniel.haxx.se
> >>
> >
>
> --
>
> / daniel.haxx.se
>

-------------------------------------------------------------------
Unsubscribe: https://cool.haxx.se/list/listinfo/curl-library
Etiquette: https://curl.haxx.se/mail/etiquette.html
Received on 2018-09-25