> On Fri, 30 Sep 2011, Gary Maxwell wrote:
>
> >> Thanks a lot for this. I agree with you that it certainly looks like what
> >> you describe. I hope to be able look into this very soon.
> >
> > Is it always the right thing to close the connection if an operation is
> > cancelled? As the sample indicates, the connection can still be used for
> > requests after the cancellation, which is what I would actually expect. If
> > my application supports simultaneous, independent requests to the same
> > server, I would not want the cancellation of one request to bugger any
> > others.
> >
> > IMO, it sounds like a "CLOSE_CONNECTION_IF_OPERATION_IS_ABORTED" option is
> > being solicited.
>
> It needs to be closed if the state of the connection is unknown, unclear or
> uncertain. We can only leave a connection for re-use if we know that we can
> re-use it in a controlled manner.
>
> In some situations in the code we take the safe way out and close down if
> there's a risk that it could cause problems.
>
> When a transfer is abrubtly being aborted like Vladimir showed us, libcurl
> cannot possibly re-use that connection again and it must be closed.

What it translates in real life is that a new reguest usually gets the response, potentially partial, of the previously cancelled one. Definitely not a good thing. I'm curious why this never surfaced before. Is it because most people use libcurl for file transfers and rarely cancel early? Our usage is a browser-like app with lots of data loading and cancellations as the user moves around the interface.
-------------------------------------------------------------------
List admin: http://cool.haxx.se/list/listinfo/curl-library
Etiquette: http://curl.haxx.se/mail/etiquette.html
Received on 2011-09-30