Hi, there still seems to be a off-by-1 error in core/downloads.c, where the returned range header of a download request is compared to the requested range.
Ranges in struct download always exclude the end byte, whereas ranges returned in HTTP headers always include the end byte. This issue is not handled correctly in the range comparison in current CVS. This results in "Range mismatch" messages in the case where the remote servent indeed manages to also provide the end byte that was requested in a range request, which should mean that such downloads never succeed because the last byte of a file cannot be downloaded by using a range request. If I noticed correctly, Christian addressed the issue in revision 1.50 of core/downloads.c, but he seemed to have changed the second instead of the first inequality. A patch that solves this issue (at least for me) is attached. My pending downloads then succeeded in a flash with correct SHA1 and without any more "Range mismatch" messages. Greetings, Thomas.
Index: downloads.c
===================================================================
RCS file: /cvsroot/gtk-gnutella/gtk-gnutella-current/src/core/downloads.c,v
retrieving revision 1.53
diff -u -r1.53 downloads.c
--- downloads.c 30 May 2005 22:25:11 -0000 1.53
+++ downloads.c 8 Jun 2005 15:35:22 -0000
@@ -6021,7 +6021,7 @@
download_stop(d, GTA_DL_ERROR, "Range end too
large");
return;
}
- if (end <= d->skip || start > d->range_end) {
+ if (end < d->skip || start >= d->range_end) {
gchar got[64];
gm_snprintf(got, sizeof got, "got %s - %s",
pgpHshnAtReDf.pgp
Description: PGP signature
