Handling HTTP connection errors

[Daniel Drake <dsd laptop org>]

Hi,

When a http GFile is opened and is being read through gio calling down
into gvfs, if there is some connectivity problem, the reads will never
time out. It will just sit there forever. I would like to solve this
bug.

In gvfs's http backend, I added the trivial code changes needed to
request a 60 second timeout in libsoup. That helps, but the results
from the client-side are not quite right. At the point of timeout, the
async read completes at the Gio level, but the result is a 0 byte
read, like an EOF. There is no error code in sight.

I believe this problem would occur on other existing soup failures
too, not just on the timeout condition I have added.

I have tried to investigate this but I'm a bit lost in the design. How
is the breakage of the HTTP connection supposed to be communicated
from gvfsbackendhttp to the upper layers?

Here's what happens at the moment:
- On timeout, read_ready in gvfsbackendhttp gets called. nread=-1 and
a GError is set (message: Connection terminated unexpectedly). So we
call g_vfs_job_failed_literal().
- g_vfs_job_failed_literal() sends a reply over dbus - I haven't
investigated its exact contents. Then we end up in send_reply_cb() in
gvfschannel.c.
- send_reply_cb() does not seem to check the state of our HTTP
connection in any way. Instead it calls start_queued_request().
- start_queued_request() notes that there are more queued reads, so it
calls down to try_read() in the HTTP backend
- read_ready() in the HTTP backend is called. nread=0, no error.
- Client reports a successful read of 0 bytes (EOF) without having
encountered any errors.

How is this supposed to work? Assuming the client received the error
message, should it have then ignored the followup successful 0 byte
read messages?
Or is send_reply_cb() missing some logic to check the underlying state
of the backend's connection? It doesn't make sense to fire off a load
of queued reads when we've just realised that the connection is
broken.
Or is the HTTP backend supposed to reject the queued followup read
requests because the previous one noted that the connection was
terminated?

Thanks
Daniel