416 response, even though ranges overlap
 

BearShare beta testers report seeing LimeWire/4.0.6 respond with 416 Requested Range Unavailable, even though the LW server has part of the requested range:

It would be best if the server would serve as much of the requested range as it can.

http://www.bearshare.net/showthread.php?t=31319

Download to [Host2 IP] ("LimeWire/4.0.6") was Transferring, but now sent statusCode==416
--REQUEST--
GET /uri-res/N2R?urn:sha1:[123] HTTP/1.1\r\n
Host: [Host2 IP]\r\n
User-Agent: BearShare Pro 4.6.0.55\r\n
Range: bytes=76021760-76283903\r\n
Content-Disposition: inline; filename=[ABC].mp3\r\n
X-Gnutella-Content-URN: urn:sha1:[123]\r\n
X-Connection-Type: Other\r\n
X-Features: browse/1.0, queue/0.1\r\n
X-Node: [my IP]\r\n
X-Queue: 0.1\r\n
\r\n

--RESPONSE--
HTTP/1.1 416 Requested Range Unavailable\r\n
Server: LimeWire/4.0.6\r\n
Content-Type: text/plain\r\n
Content-Length: 0\r\n
X-Gnutella-Content-URN: urn:sha1:[123]\r\n
X-Available-Ranges: bytes 0-76099176\r\n
\r\n

Woulnd't it be better, if bearshare requested the range, which is avaible?

It gets the avaible range, so it should just request what is avaible.

Else I'm sure it can produce many bugs just because what the Bearshare client gets isn't what it requested.

The Limewire client would be a bit more flexible, if it served what it can, but the bearshare would also be more flexible, if it just requested what is avaible.

In this case Bearshare requested about 250kB, but Limewire had only the first 70kB (or so).

Des Beashare have a fixed download-segment-size?

Phex now uses flexible sizes (from 16bK to 20MB), I don't know, what LimeWire uses.

Oh, is that what LimeWire clients do? Clip their requests to the ranges available?

Regardless, clients that don't clip their requests should not be given a 416 in this situation. I think it is more likely that the LW developers intend to follow RFC2616, the HTTP 1.1 spec:

10.4.17 416 Requested Range Not Satisfiable

A server SHOULD return a response with this status code if a request included a Range request-header field (section 14.35), and none of the range-specifier values in this field overlap the current extent of the selected resource, and the request did not include an If-Range request-header field. (For byte-ranges, this means that the first- byte-pos of all of the byte-range-spec values were greater than the current length of the selected resource.)

Looks as if I was lazy...

We intend on adding this support to the HTTP Server portion, at some point. Till then, the safest is to just request what the server advertises as available.

OK
 

Thanks!