On Fri, Feb 15, 2008 at 10:44 PM, Daniel Stenberg <daniel_at_haxx.se> wrote:
> On Fri, 15 Feb 2008, jérôme Muffat-Méridol wrote:
>
>
> > I have done the changes you suggested and it didn't do anything new.
> > Tracing the code, I have come to the conclusion that the change didn't
> > have any significant effect:
>
>
> > returns CURLE_OK instead of CURLE_GOT_NOTHING . But tracing further, that
> > return value isn't used down the line at all.
>
> And that was why I asked. If that's not the spot that returns
> CURLE_GOT_NOTHING for your error case, then what is? When I search the libcurl
> source code I can only see one instance of this being returned or used in any
> sense that could end up anywhere.
>
> Where is this return code dropped then? It sounds like you've detected a bug
> if it's not used.
>
> I just don't understand how you can (wrongly) get CURLE_GOT_NOTHING with my
> suggested patch applied. Can you?
>
> --
>
>
> Commercial curl and libcurl Technical Support: http://haxx.se/curl.html

This is what the code does when failf("Empty reply from server") is
triggered (ie without the changes you suggested)

CURLE_GOT_NOTHING is returned by Curl_http_done to Curl_done
Curl_done doesn't do anything special with this return value, and passes it on.
it follows that:
CURLE_GOT_NOTHING is returned by Curl_done to curl_multi_remove_handle

curl_multi_remove_handle doesn't check the return value.

I'm *not* getting CURLE_GOT_NOTHING wrongly.

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.

I am getting a failf("Empty reply from server") when closing A.
This isn't too surprising.

What I would have expected is that libCurl would make a note somewhere
that it should ignore content coming back from the server as the
server has no clue we're not interested any more. Or, to do things
differently, maybe libCurl should close that connection instead of
keeping it available for reuse. To be fair, I have no idea what should
be done inside libCurl as I haven't delved too much into it yet and as
I don't know much about the underlying protocols and sockets.

I still haven't managed to reproduce the case in a standalone sample.
I haven't even managed to trigger a failf("Empty reply from
server")... This is the key: extracting the problem into a small
enough piece of code. I'll be back on to that on monday.

Thanks for the suggestions so far, the feeling of not being alone is
very helpful.
J.
Received on 2008-02-16