Hi,
I think i have just the same problem. I didnt figured it out in detail like
Sigrid did, but i get the same line in url.c, when my program crashes. I also
use a Multi handle and reusing Easy handles after a reset(). Im using version
7.16.1. Im not exactly sure, but i think i got that problem even in 7.16.0.

Please tell me what information i can provide you. (i cannot give you an
examplecase, im sorry).

Would be nice if we can figure out an fix together.
Thats all for now, just wanted to raise my hand!

greetings
Manuel Jung

Am Mittwoch, 7. März 2007 12:14 schrieb Sigrid Thijs:
> Hello,
>
> I think I found the cause of this behavior.
> We use the multi interface, and basically the following happens:
>
> // For the first request, we create an easy handle:
> CURL * pcURL = curl_easy_init ();
>
> // the necessary options are set ...
>
> // this handle is added to the multi session:
> curl_multi_add_handle ( pMultiCURL, pcURL );
>
> // Perform transfer
> int busyHandleCount = 0;
> CURLMcode code = curl_multi_perform ( pMultiCURL, &busyHandleCount );
>
> if ( code == CURLM_CALL_MULTI_PERFORM )
> code = curl_multi_perform ( pMultiCURL, &busyHandleCount ); // Again
>
> // Process results
> int messageCount = 0;
> CURLMsg *pmessage = NULL;
>
> while ( ( pmessage = curl_multi_info_read ( pMultiCURL, &messageCount ) ) )
> {
> if ( pmessage->msg == CURLMSG_DONE )
> {
> curl_multi_remove_handle ( pMultiCURL, pcURL );
> curl_easy_cleanup (pcURL );
> }
> }
>
> When the second request on the same connection is issued, a new easy
> handle is created and performed.
> I have been debugging this and the problem is located in libcurl url.c
> line 3603:
> <code snip>
>
> struct connectdata *old_conn = conn;
>
> if(old_conn->proxy.rawalloc)
> free(old_conn->proxy.rawalloc);
>
> /* free the SSL config struct from this connection struct as this was
> allocated in vain and is targeted for destruction */
> Curl_free_ssl_config(&conn->ssl_config);
>
> conn = conn_temp; /* use this connection from now on */
>
> conn->data = old_conn->data; /* **HERE** */
>
> </code snip>
>
> When reusing the connection, conn_temp contains the data of the
> connection (a.o. the digest and nonce). The new connection will point to
> this connection, BUT the data of this connection is overwritten! As a
> result the digest and nonce information are gone.
> As a result of this, when the 2nd request is posted, conn->bits.authneg
> is set to TRUE in http.c line 1680. Because of this no body will be
> added to the request. I'm not sure why and where the Authorization
> header still is added to the request, this means the digest information
> is still available somewhere.
>
> The reason that this worked before is because in version 7.12.1, url.c
> did not contains this line (3603):
> conn->data = old_conn->data
>
> I would like to have some feedback on this. Is it not allowed to use
> multiple easy handles when using the same connection? Are we doing
> something wrong? Should the same easy handle be used when reusing a
> connection? Is it a bug in libcurl?
>
> kind regards,
>
> Sigrid
>
> Sigrid Thijs wrote:
> > Hi,
> >
> > we recently upgraded our client to libcurl version 7.16.0 (win32) and
> > have now a problem while re-using a connection.
> >
> > We use HTTP Digest authentication, the following options are set:
> > CURLOPT_WRITEFUNCTION, CURLOPT_FILE, CURLOPT_PRIVATE, CURLOPT_HTTPHEADER
> > CURLOPT_URL, CURLOPT_HTTPAUTH, CURLOPT_USERPWD, CURLOPT_POSTFIELDS,
> > CURLOPT_POSTFIELDSIZE, CURLOPT_CAPATH
> >
> > The following happens:
> > 1. The client posts an initial HTTP request (without body)
> >
> > POST /mmas/wbe_302S/wbe.soap.osp HTTP/1.1
> > Host: 193.166.131.188:8080
> > Accept: */*
> > Content-Type: text/xml; charset=utf-8
> > SOAPaction: ""
> > Content-Length: 0
> >
> > 2. The client receives a 401 response from the server
> >
> > HTTP/1.1 401 Authorization Required
> > Date: Mon, 05 Mar 2007 09:36:43 GMT
> > Server: Apache/1.3.31 (Unix) PHP/5.0.5 OSP FEPHTTP (mod_in)/1.0.008
> > mod_ssl/2.8.17 OpenSSL/0.9.7d
> > Set-cookie: INSessionID=;path=/;expires=Sun, 04-Mar-07 09:36:43 GMT
> > WWW-Authenticate: Digest realm="WBERealm",
> > nonce="c23a7595e96edc3df13270fe73f3f456", algorithm=MD5, domain="/",
> > qop="auth"
> > Transfer-Encoding: chunked
> > Content-Type: text/html; charset=iso-8859-1
> >
> > ...
> >
> > 3. The client re-posts the HTTP request containing authorization and body
> >
> > POST /mmas/wbe_302S/wbe.soap.osp HTTP/1.1
> > Authorization: Digest username="username_at_mmas.com", realm="WBERealm",
> > nonce="c23a7595e96edc3df13270fe73f3f456",
> > uri="/mmas/wbe_302S/wbe.soap.osp", cnonce="MDA0NzE3", nc=00000001,
> > qop="auth", response="121f382f188f4d88550318893011f841", algorithm="MD5"
> > Host: 193.166.131.188:8080
> > Accept: */*
> > Content-Type: text/xml; charset=utf-8
> > SOAPaction: ""
> > Content-Length: 497
> >
> > ...
> >
> > 4. A 200 OK response is received
> >
> > HTTP/1.1 200 OK
> > Date: Mon, 05 Mar 2007 09:36:44 GMT
> > Server: Apache/1.3.31 (Unix) PHP/5.0.5 OSP FEPHTTP (mod_in)/1.0.008
> > mod_ssl/2.8.17 OpenSSL/0.9.7d
> > Set-cookie: Sequence=1;path=/
> > Set-cookie: INSessionID=MTY3ODAxMDJAMjMz;path=/
> > Content-Type:
> > Content-Length: 1063
> >
> > ...
> >
> > 5. The client posts a new HTTP request (reuses the connection), with
> > authorization but without body
> >
> > POST /mmas/wbe_302S/wbe.soap.osp HTTP/1.1
> > Authorization: Digest username="username_at_mmas.com", realm="WBERealm",
> > nonce="c23a7595e96edc3df13270fe73f3f456",
> > uri="/mmas/wbe_302S/wbe.soap.osp", cnonce="MDA0NzE3", nc=00000001,
> > qop="auth", response="121f382f188f4d88550318893011f841", algorithm="MD5"
> > Host: 193.166.131.188:8080
> > Accept: */*
> > Content-Type: text/xml; charset=utf-8
> > SOAPaction: ""
> > Content-Length: 0
> >
> > 6. As a result of this the server sends a 400 Bad Request response
> >
> > HTTP/1.1 400 Bad Request
> > Set-cookie: INSessionID=MTY3ODAxMDJAMjM0;path=/
> > Content-Type:
> > Content-Length: 684
> >
> > ...
> >
> > Do you have any idea why the body is not included in the request sent in
> > step 5? Because the request already contains the authorization it does
> > not make any sense to not include the body.
> >
> > kind regards,
> >
> > Sigrid
Received on 2007-03-07