Could you include more details for debugging? As far as I can tell range requests are working properly, as witnessed by the session below, using curl against a public file.
Note it does include a Content-Length header, and indeed I've confirmed that it returns 144 bytes as expected.
Looking over our code, there's two places a Content-Range header is set, one when a proper 206 response is generated, and for which the code path forcibly sets a Content-Length header, and another one when a Range request is not satisfiable, which generates a 416 response code, with Content-Range: */<content-length> but no body included. None of them match the response you included in the bug description.
I'm suspecting that Squid might be at fault here, but would need more information to confirm.
curl -s -v -o/dev/null -H "Range: bytes=0-143" http://ubuntuone.com/p/c9Y/
* About to connect() to ubuntuone.com port 80 (#0)
* Trying 91.189.89.205...
* connected
* Connected to ubuntuone.com (91.189.89.205) port 80 (#0)
> GET /p/c9Y/ HTTP/1.1
> User-Agent: curl/7.28.0
> Host: ubuntuone.com
> Accept: */*
> Range: bytes=0-143
>
< HTTP/1.1 206 Partial Content
< Date: Tue, 22 Jan 2013 21:12:31 GMT
< Server: TwistedWeb/10.0.0
< Content-Length: 144
< Content-Disposition: inline; filename=Selection_281.png
< Vary: Accept-Encoding
< Last-Modified: Tue, 08 Feb 2011 11:33:40 GMT
< Content-Range: bytes 0-143/103672
< ETag: "sha1:0d8a6d5947321c0a207e349f6a91b0d2dc445470"
< X-Bzr-Revision-Number: 6709
< Content-Type: image/png
< X-Cache: MISS from amatungulu.canonical.com
< X-Cache-Lookup: MISS from amatungulu.canonical.com:3128
< Via: 1.0 amatungulu.canonical.com:3128 (squid/2.7.STABLE7)
< Via: 1.1 www.ubuntuone.com
<
{ [data not shown]
* Connection #0 to host ubuntuone.com left intact
* Closing connection #0
Hi Raymond,
Could you include more details for debugging? As far as I can tell range requests are working properly, as witnessed by the session below, using curl against a public file.
Note it does include a Content-Length header, and indeed I've confirmed that it returns 144 bytes as expected.
Looking over our code, there's two places a Content-Range header is set, one when a proper 206 response is generated, and for which the code path forcibly sets a Content-Length header, and another one when a Range request is not satisfiable, which generates a 416 response code, with Content-Range: */<content-length> but no body included. None of them match the response you included in the bug description.
I'm suspecting that Squid might be at fault here, but would need more information to confirm.
curl -s -v -o/dev/null -H "Range: bytes=0-143" http:// ubuntuone. com/p/c9Y/ Disposition: inline; filename= Selection_ 281.png 7321c0a207e349f 6a91b0d2dc44547 0" Number: 6709 canonical. com canonical. com:3128 canonical. com:3128 (squid/2.7.STABLE7)
* About to connect() to ubuntuone.com port 80 (#0)
* Trying 91.189.89.205...
* connected
* Connected to ubuntuone.com (91.189.89.205) port 80 (#0)
> GET /p/c9Y/ HTTP/1.1
> User-Agent: curl/7.28.0
> Host: ubuntuone.com
> Accept: */*
> Range: bytes=0-143
>
< HTTP/1.1 206 Partial Content
< Date: Tue, 22 Jan 2013 21:12:31 GMT
< Server: TwistedWeb/10.0.0
< Content-Length: 144
< Content-
< Vary: Accept-Encoding
< Last-Modified: Tue, 08 Feb 2011 11:33:40 GMT
< Content-Range: bytes 0-143/103672
< ETag: "sha1:0d8a6d594
< X-Bzr-Revision-
< Content-Type: image/png
< X-Cache: MISS from amatungulu.
< X-Cache-Lookup: MISS from amatungulu.
< Via: 1.0 amatungulu.
< Via: 1.1 www.ubuntuone.com
<
{ [data not shown]
* Connection #0 to host ubuntuone.com left intact
* Closing connection #0