REST API: Support the Range header for GET content of files
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ubuntu One Servers |
Confirmed
|
Medium
|
Sidnei da Silva |
Bug Description
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-
Date: Mon, 21 Jan 2013 23:30:06 GMT
X-Bzr-Revision-
Etag: "sha1:7f96fcfa0
Content-Range: bytes 0-143/3909
Via: 1.0 calamansi.
Content-Type: application/
Vary: Accept-
X-Cache: MISS from calamansi.
Set-Cookie: sessionid=...; Domain=
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 (206, which is Partial content), but the body of the response is empty, and there is no Content-Length header in the returned response.
summary: |
- Support the Range header + REST API: Support the Range header for GET content of files |
Changed in ubuntuone-servers: | |
assignee: | nobody → Sidnei da Silva (sidnei) |
importance: | Undecided → Medium |
information type: | Proprietary → Public |
description: | updated |
tags: | added: u1-api u1-by-user u1-on-production |
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