Comment 0 for bug 1103136

Excerpt from RFC2616, section 14.35.2, "Range Retrieval Requests":

"HTTP/1.1 origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers, and supports efficient partial retrieval of large entities."

I tried to request a Range from Ubuntu One server for a file stored on my Ubuntu One account, and got the following response header:

/=====
Content-Disposition: inline; filename=blah.txt
Date: Mon, 21 Jan 2013 23:30:06 GMT
X-Bzr-Revision-Number: 6696
Etag: "sha1:7f96fcfa002cf5791c976c46aaf733dc523d9041;gzip"
Content-Range: bytes 0-143/3909
Via: 1.0 calamansi.canonical.com:3128 (squid/2.7.STABLE7) 1.1 files.one.ubuntu.com
Content-Type: application/octet-stream
Vary: Accept-Encoding,Cookie
X-Cache: MISS from calamansi.canonical.com
Set-Cookie: sessionid=...; Domain=.one.ubuntu.com; httponly; Path=/; secure
Server: TwistedWeb/10.0.0
Last-Modified: Mon, 21 Jan 2013 23:17:05 GMT
\=====

It is as if the server is fulfilling my request, telling me that range 0-143 is returned, along with a success status code (Partial content), but the body of the response is empty, and there is no Content-Length header in the returned response.