cURL / Mailing Lists / curl-library / Single Mail

curl-library

Re: How bad is "Empty reply from server" ?

From: jérôme Muffat-Méridol <jmuffat_at_webphotomag.com>
Date: Sat, 16 Feb 2008 17:34:17 +0100

On Feb 16, 2008 2:55 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Sat, 16 Feb 2008, jérôme Muffat-Méridol wrote:
>
> > CURLE_GOT_NOTHING is returned by Curl_done to curl_multi_remove_handle
> > curl_multi_remove_handle doesn't check the return value.
>
> It is indeed. I should add some comment in there to make it more obvious that
> it actually does this on purpose.
>
> > I'm *not* getting CURLE_GOT_NOTHING wrongly.
>
> No you're not and I'm sorry I was confused there for a moment. But the error
> text "Empty reply from server" that you get is also only stored at a single
> place so that's why I thought they were closely related.
>
> > What I think I am getting is this: a handle has sent a request A to a
> > server, the server hasn't sent back any byte yet, and I close the handle.
> > Then, a new handle is created and sends a request B to the same server.
> > Instead of receiving the content of B, this new handle receives the content
> > for A.
>
> If this is the case, libcurl re-uses a connection that it shouldn't. The
> connection to A needs to be closed at this point since there may or may not be
> lingering response data coming back. The connection for B needs to be made
> fresh.
>
> Reading the code further, I actually think this is the case you see. As a
> test, you can try the following patch that forces the connection to get closed
> if the handle is removed "prematurely". Possibly we should make the check
> somewhat more fine-grained, but atm I can't think of a way how a premature
> removal won't risk causing this problem.
>
> --- lib/url.c 15 Feb 2008 21:38:54 -0000 1.700
> +++ lib/url.c 16 Feb 2008 13:54:25 -0000
> @@ -4446,7 +4446,7 @@
> if conn->bits.close is TRUE, it means that the connection should be
> closed in spite of all our efforts to be nice, due to protocol
> restrictions in our or the server's end */
> - if(data->set.reuse_forbid || conn->bits.close) {
> + if(data->set.reuse_forbid || conn->bits.close || premature) {
> CURLcode res2 = Curl_disconnect(conn); /* close the connection */
>
> /* If we had an error already, make sure we return that one. But
>
>
> --
>
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

ok, so I'm understanding this properly then.
Thanks a lot.

I am sure that I have a case where the connection gets reused, I'll
track this precisely on monday. I wasn't sure what was supposed to
happen in that sort of case, but now realise that the only option is
to drop the connection, (it feels sort of obvious, actually).

Thanks again.
J.
Received on 2008-02-16