tahoe-lafs wrote: > #698: corrupted file displayed to user after failure to download followed by > retry [...] > When we get a "late failure" (i.e. one of the servers disconnects in the > middle), the webapi doesn't have a lot of choices. At the moment, it emits > a brief error message (attached to whatever partial content has already been > written out), then drops the HTTP connection, and hopes that the client is > observant enough to notice that the number of received bytes does not > match the previously-sent Content-Length header, and then announce an error > on > the client side.
Is it possible for the length so far plus the length of the brief error message, to coincidentally equal the expected file length (whether or not that is what happened in this case)? > There are two directions to fix this: > > * change the webapi to use "Chunked Encoding", basically delivering data > one segment at a time, possibly giving the server a chance to emit an > error > header in between segments: this would let us respond better to these > errors This sounds like the best approach to me. -- David-Sarah Hopwood ⚥ _______________________________________________ tahoe-dev mailing list [email protected] http://allmydata.org/cgi-bin/mailman/listinfo/tahoe-dev
