Hello Daniel

I'm impressed by your response time! Thanks.

>I agree with this, but the reason it uses the redirect method
>is that it was an already established method of doing almost
>exactly what we needed when I wrote the retry-the-request logic.
>This problem you've identified is so far the only downside
>with this approach.
>This situation is also very hard to write a test case/server for...

Yes, I completely agree with you. We deal with a server implementation (we
can't change) that handles the keep-alive timeout incorrectly. After the
keep-alive timeout it does not close the connection actively but it closes
it as soon as the client tries to use the socket again. In this scenario,
the problematic case can easily be reproduced and that's how we encountered
and analyzed the described problem. The keep-alive implementation of the
server is just wrong and prone to denial of service attacks. In spite of
that, I guess that it's good for curl to be as robust as possible.

>How about the attached patch? It tries to prevent the
>'redirect' status of the
>retried request to make it look more like the first one and
>thus hopefully
>work better in your problematic case.

We applied your second patch to curl 7.12.3 and so far all tests are working
well and the problem does not occur anymore! We'll have more tests running
today but I'm convinced that your suggested patch solves it.

Best regards,

Cyrill
Received on 2005-01-11