Ceph » rgw

I've done some work on this today, while doing so i found some more issues.

The attached patch fixes that with GET and HEAD requests we always return the Content-Length, Last-Modified and Accept-Ranges (bytes) headers.

With a HEAD request a client should be able to know how large the download is going to be (Content-Length) and if it has changed since it cached the file (Last-Modified).

The Accept-Ranges header should not only be sent back when a "Range" header is specified by the client, when we do so, a client never knows we do support partial content. Thus we always sent back that header.

Tried this with Amazon, and they do support Content-Range, but they do not sent back the "Accept-Ranges" header with a normal request:

Normal request

wido@wido-desktop:~$ curl -sv http://XXX.s3.amazonaws.com/The.Simpsons.2007.Mypods.and.Boomsticks.avi > /dev/null
* About to connect() to XXX.s3.amazonaws.com port 80 (#0)
*   Trying 87.238.86.131... connected
* Connected to XXX.s3.amazonaws.com (87.238.86.131) port 80 (#0)
> GET /The.Simpsons.2007.Mypods.and.Boomsticks.avi HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: XXX.s3.amazonaws.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< x-amz-id-2: BFPqP+cEW4EkjTkg+oWwwYPvFavKVbVTrCyGzpm0sUiB91HAQCAqttCx14H+mrWb
< x-amz-request-id: FF4A445F5D8C01A9
< Date: Fri, 23 Jul 2010 13:59:34 GMT
< Last-Modified: Thu, 22 Jul 2010 19:49:09 GMT
< ETag: "764d09f8630adac862e9844005d07fb0" 
< Content-Type: video/x-msvideo
< Content-Length: 183533568
< Server: AmazonS3
< 
{ [data not shown]
wido@wido-desktop:~$

Here the "Accept-Ranges" header is not sent by Amazon S3, while it is supported:

Partial request

wido@wido-desktop:~$ curl -sv -r 0-500 http://XXX.s3.amazonaws.com/The.Simpsons.2007.Mypods.and.Boomsticks.avi > /dev/null
* About to connect() to XXX.s3.amazonaws.com port 80 (#0)
*   Trying 87.238.86.131... connected
* Connected to XXX.s3.amazonaws.com (87.238.86.131) port 80 (#0)
> GET /The.Simpsons.2007.Mypods.and.Boomsticks.avi HTTP/1.1
> Range: bytes=0-500
> User-Agent: curl/7.19.7 (x86_64-pc-linux-gnu) libcurl/7.19.7 OpenSSL/0.9.8k zlib/1.2.3.3 libidn/1.15
> Host: XXX.s3.amazonaws.com
> Accept: */*
> 
< HTTP/1.1 206 Partial Content
< x-amz-id-2: 9wrAZika2uUwRyo5Tdl5chX6cW5Tu8Jy/H+WAyxDPzRN1p1oD8vMKunlgU2V+Bun
< x-amz-request-id: 6DCABE354252FE00
< Date: Fri, 23 Jul 2010 13:59:11 GMT
< Last-Modified: Thu, 22 Jul 2010 19:49:09 GMT
< ETag: "764d09f8630adac862e9844005d07fb0" 
< Content-Range: bytes 0-500/183533568
< Content-Type: video/x-msvideo
< Content-Length: 501
< Server: AmazonS3
< 
{ [data not shown]
* Connection #0 to host XXXX.s3.amazonaws.com left intact
* Closing connection #0
wido@wido-desktop:~$

Imho it would be fine if we always sent the Accept-Ranges header.

About the Content-Length being set to 0, i haven't been able to find out how this could happen. Might it be that the gateway does not return any data, while it says it would do so, and then Apache sets the Content-Length to 0, since nothing is being sent?

Uh, my bad, the Last-Modified header value was not a GMT timestamp. The attached patch fixes this by using "gmtime()" instead of "localtime()".

There was still a problem that with partial content no data was returned. This was due to a error in rgw_rest.cc.

A check was done if ret was not set, but it is when we return partial content.

The attached patch fixes that we return data when the client requests partial content.

Skipping through a movie with VLC works fine now.

After this patch i think this issue can be set to resolved.

Bulk reassign of radosgw category to RGW project.