cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: Infinite loop behaviour with libcurl + FTP + proxy + NTLM authentication

From: Pramod Sharma <pramodsharma08_at_gmail.com>
Date: Thu, 16 Apr 2009 09:02:31 +0530

> *> Connection: Keep-Alive< Proxy-Connection: Keep-Alive< Pragma:
> no-cache< *
> *> Cache-Control: no-cache< Content-Type: text/html< Content-Length: 0 < *
> *> 0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- *
> *> 0 *..
>
> *> * Closing connection #0 *
>
> > This last line is the indicator of this bug. Since NTLM is authenticating
> a
> > connection, it will restart when it gets closed. The big question here is
> why
> > libcurl thinks the connection should get closed. I can't see any clues in
> that
> > log output!
>
> > Can you write up a test case that reproduces this problem?
>
>
> Thanks Daniel .
> The problem is with closing of connection( no persistent connection). I
> could write a test case for that , though I need to understand curl test
> cases format (learning curve for me ). I can instead, write a c test code
> using libcurl (easy)
>
> I analyzed the problem and here are my findings. Let me know where should I
> place the fix.
>
> 1. By default, conn->bits.close = TRUE ; // protocol specific connectors
> will set this value
> 2. For HTTP, curl_http_connect( called by curl_http_handler->connect_it)
> sets its to FALSE , as it supports persist connection.(http.c)
> 3. For FTP there is a function ftp_connect (supposed to be called by
> curl_ftp_handler->connect_it), which also sets it to false . (ftp.c)
>
> 4. But the function ftp_setup_connection(struct connectdata * conn)
> changes the FTP handler itself in case of (http proxy + no tunneling)
> combination
>
> See my comments below in the code snippets, let me know what you think...
>
> ftp.c
>
> static CURLcode ftp_setup_connection(struct connectdata * conn)
> {
> .............................................
>
> if(conn->handler == &Curl_handler_ftp)
> {
>
> /* Pramod Sharma
> This is changing the handler itself , which has the connect_it function
> call back as NULL
> and there will be no connect_it in this case and conn->bits.close will
> remain as true
> */
>
> conn->handler = &Curl_handler_ftp_proxy;
>
> /*Pramod Sharma - either we can write the connect_it for
> curl_handler_ftp_proxy too
> and do the thing protocol specific like setting bits.close as false
> or we can set the bit here itself here as false as we know here we
> reached only in this proxy scenario
> */
> conn->bits.close = FALSE;
> }
> }
>
>
> url.c
>
> CURLcode Curl_protocol_connect(struct connectdata *conn,
> bool *protocol_done)
> {
> ........................................
> if(!conn->bits.protoconnstart) {
> /*Pramod Sharma
> Here handler is changed for this scenario , so it will not have
> connect_it
> and conn->bits.close will be remain as default)
> */
> if(conn->handler->connect_it) {
> /* is there a protocol-specific connect() procedure? */
> ......................................................
> else
> *protocol_done = TRUE;
>
> .................................
> }
>

 Did anyone get a chance to look into this ? . I don't know by mistake "Re"
got missed out in the last email , so I am doubtful about my last email.

Regards,
Pramod
Received on 2009-04-16