Hi,
On Tue, Nov 6, 2012 at 6:13 PM, Lieven Govaerts <lgo_at_mobsol.be> wrote:
> Hi,
>
> On Tue, Nov 6, 2012 at 4:50 PM, Lieven Govaerts <lgo_at_mobsol.be> wrote:
>> Ben,
>>
>> On Tue, Nov 6, 2012 at 4:09 PM, Ben Reser <ben_at_reser.org> wrote:
>>> I worked with Philip today and was able to reproduce the exact problem
>>> he's been seeing. I ended up having to get his full httpd.conf to
>>> figure it out..
>>>
>>> Ultimately the problem proved to be that he had this directive:
>>> Timeout 3
>>>
>>> Which would mean if we don't tend a connection for 3 seconds Apache
>>> will close it. Serf should be able to deal with the connection being
>>> closed.
>>>
>
> okay, so with the Timeout directive added I can reproduce this issue.
>
> What I see is that the server closes the connection in the middle of
> sending a response to the client. It doesn't even finalize the
> response first.
> So ra_serf is reading the data from the response bucket, but gets an
> APR_EOF when it needs more data than specified in the Content-Length
> header of the response.
>
> What is the expected behavior here, let serf close down the connection
> and try the request again on a new connection?
IMHO, the reasonable thing to do here, is to report the error
correctly to the user, so that we don't corrupt the working copy.
This way the user can retry the transaction.
For response bodies that are encoded (chunked or gzip/deflated), serf
will already return an error status to svn/ra_serf. The one case where
serf silently returns APR_EOF is when no encoding is used so the
Content-Length header is set.
Attached patch to serf trunk will calculate the actually read bytes
from the response body, and ensures an error is returned to svn when
this is less than what's expected. The patch is not final, I probably
want to use another error code.
Philip or Ben, can you test that with this patch svn will always stop
with a communication error?
Lieven
Received on 2012-11-06 22:46:45 CET