libcurl development talk. How to program using libcurl, and how to develop libcurl further

Daniel Stenberg | 1 Oct 2009 09:09

Re: Problems related to probing for proxy authentication methods

On Wed, 30 Sep 2009, Constantine Sapuntzakis wrote:

>> I think the erroneous bit is that CCProxy doesn't reset the connection 
>> after sending the 407, it only resets it after it gets more data. I am 
>> feeling like that is very nonstandard behavior:
>
> Agreed - CCProxy should send a shutdown if it doesn't support another 
> request.

Indeed. I think it is a proxy bug not to.

> However, the same situation can happen with any proxy or server that does 
> support persistent connections. curl sends the next header just as the proxy 
> times out the persistent connection. So it would be friendlier if curl deal 
> with this situation rather than propagating it to the client.

I agree here too. And libcurl already _does_ handle this case when it does a 
"normal" HTTP request that isn't a CONNECT, exactly for this reason.

> Maybe the right way to deal with it is: if the request is not the first 
> request on the connection and the server resets the connection, then retry 
> the request on a fresh connection.

Sounds about right. The worst part is that the CONNECT function has turned 
into a rather messy thing that would benefit from a little cleanup...

--

-- 

  / daniel.haxx.se
-------------------------------------------------------------------

(Continue reading)

headers

Joshua Kwan | 1 Oct 2009 20:28

Re: Problems related to probing for proxy authentication methods

On 10/1/09 00:09, "Daniel Stenberg" <daniel <at> haxx.se> wrote:
>> Maybe the right way to deal with it is: if the request is not the first
>> request on the connection and the server resets the connection, then retry
>> the request on a fresh connection.
> 
> Sounds about right. The worst part is that the CONNECT function has turned
> into a rather messy thing that would benefit from a little cleanup...

In this case, would the initial connection reset error be seen by the cURL
client, or would it be masked unless the second request fails too?

I was also taking a look at Curl_proxyCONNECT and winced a little.. as it is
blocking!

We use cURL in a GUI app so it's important that it blocks as little as
possible.

-Josh

-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette:  http://curl.haxx.se/mail/etiquette.html

headers

Daniel Stenberg | 1 Oct 2009 22:57

Re: Problems related to probing for proxy authentication methods

On Thu, 1 Oct 2009, Joshua Kwan wrote:

> In this case, would the initial connection reset error be seen by the cURL 
> client, or would it be masked unless the second request fails too?

For the "normal" requests, if the first send() on a re-used connection fails 
it will silently create a new connection and retry the request on that. See 
lib/url.c:Curl_do().

> I was also taking a look at Curl_proxyCONNECT and winced a little.. as it is 
> blocking!
>
> We use cURL in a GUI app so it's important that it blocks as little as 
> possible.

Right, and hence the comment above this function says:

   This badly needs to be rewritten. CONNECT should be sent and dealt with
   like any ordinary HTTP request, and not specially crafted like this. This
   function only remains here like this for now since the rewrite is a bit too
   much work to do at the moment.

   This function is BLOCKING which is nasty for all multi interface using apps.

Converting this blocking approach to a proper non-blocking one is indeed 
something we've been wanting to do for a long time but I've so far not found 
the proper motivation to go ahead.

--

--

(Continue reading)