Project

General

Profile

Actions

Bug #16388

closed

Wrong Content-Range and Content-Length for zero size object with Range request

Added by Victor Efimov almost 8 years ago. Updated over 7 years ago.

Status:
Resolved
Priority:
Normal
Target version:
-
% Done:

0%

Source:
other
Tags:
Backport:
Regression:
No
Severity:
2 - major
Reviewed:
Affected Versions:
ceph-qa-suite:
Pull request ID:
Crash signature (v1):
Crash signature (v2):

Description

When I submit request to zero-size object with Range header, I am getting
wrong Content-Length and Content-Range.

See "Content-Range: bytes 0-5242880/0" and "Content-Length: 5242881" below.

GET
http://XXXX/test-vsespb-1/mykey?AWSAccessKeyId=XXX&Expires=1467330825&Signature=XXX
Range: bytes=0-5242880

HTTP/1.1 206 Partial Content
Connection: close
Date: Sun, 19 Jun 2016 10:12:40 GMT
Accept-Ranges: bytes
ETag: "d41d8cd98f00b204e9800998ecf8427e"
Server: Apache/2.4.7 (Ubuntu)
Content-Length: 5242881
Content-Range: bytes 0-5242880/0
Content-Type: binary/octet-stream
Last-Modified: Sun, 19 Jun 2016 09:51:13 GMT
Client-Date: Sun, 19 Jun 2016 10:12:41 GMT
Client-Peer: XXX
Client-Response-Num: 1
X-Amz-Meta-Md5: d41d8cd98f00b204e9800998ecf8427e
X-Amz-Request-Id: XXX

Without request Range everything is ok:

GET
http://XXX/test-vsespb-1/mykey?AWSAccessKeyId=XXX&Expires=1467330825&Signature=XXX

HTTP/1.1 200 OK
Connection: close
Date: Sun, 19 Jun 2016 10:18:58 GMT
Accept-Ranges: bytes
ETag: "d41d8cd98f00b204e9800998ecf8427e"
Server: Apache/2.4.7 (Ubuntu)
Content-Length: 0
Content-Type: binary/octet-stream
Last-Modified: Sun, 19 Jun 2016 09:51:13 GMT
Client-Date: Sun, 19 Jun 2016 10:18:58 GMT
Client-Peer: XXX
Client-Response-Num: 1
X-Amz-Meta-Md5: d41d8cd98f00b204e9800998ecf8427e
X-Amz-Request-Id: XXX

Note that ETag in both requests is same and it's d41d8cd98f00b204e9800998ecf8427e (known md5 of empty string), so it's a zero-size object.

Version "ceph version 10.2.1 (3a66dd4f30852819c1bdaa8ec23c795d4ad77269)"

I tried different sizes for Range. Reproduced always.

Related maillist message: http://lists.ceph.com/pipermail/ceph-users-ceph.com/2016-June/010704.html

p.s.
That bug actually prevents implementing the following workflow for applications where all HTTP response body stored in memory and thus downloading
huge files consumes all memory:
Download object of any size (including huge) with minimum number of request.
1) Issue first request with Range, say "Range: bytes=0-5242880"
2) If it's last chunk, that we got all object.
3) If there is more data, continue with other chunks.

Actions #1

Updated by Pavan Rallabhandi almost 8 years ago

  • Assignee set to Pavan Rallabhandi
Actions #2

Updated by Pavan Rallabhandi almost 8 years ago

  • Status changed from New to In Progress
Actions #3

Updated by Pavan Rallabhandi over 7 years ago

  • Status changed from In Progress to Resolved
  • Source changed from other to Community (dev)
  • Release set to master

commit:4a90e648ed87433f026d03e6a499549c4bb8b710

Actions #4

Updated by Pavan Rallabhandi over 7 years ago

  • Private changed from No to Yes
  • Source changed from Community (dev) to other
Actions #5

Updated by Pavan Rallabhandi over 7 years ago

  • Private changed from Yes to No
Actions

Also available in: Atom PDF