Nugine / s3s

S3 Service Adapter

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Wrong HTTP Statuscode in GetObject with Range header

St4NNi opened this issue · comments

Hi and thanks again for the great crate.

We experienced a problem with the current response implementation in the GetObject request:

If the user sends a request with a specific range and the range request gets fullfilled, s3s sends the wrong http status code in the response. The specification RFC9110 and the official S3 docs mention that in this case the status code SHOULD be 206 (Partial Content) and not 200 (OK):

Code that sets the statuscode:

pub fn serialize_http(x: GetObjectOutput) -> S3Result<http::Response> {
let mut res = http::Response::with_status(http::StatusCode::OK);

Example:

Sample Request:

---[ REQUEST POST-SIGN ]-----------------------------
GET /project/file.tar.gz HTTP/1.1
Host: localhost:9000
User-Agent: aws-sdk-go/1.44.256 (go1.20.8; linux; amd64)
Range: bytes=52428800-60353599
...

Expected (aws S3 / minio etc.):

DEBUG: Response s3/GetObject Details:
---[ RESPONSE ]--------------------------------------
HTTP/1.1 206 Partial Content
Content-Length: 7924800
Accept-Ranges: bytes
Content-Range: bytes 52428800-60353599/60353600

Got (s3s):

DEBUG: Response s3/GetObject Details:
---[ RESPONSE ]--------------------------------------
HTTP/1.1 200 OK
Content-Length: 7924800
Accept-Ranges: bytes
Content-Range: bytes 52428800-60353599/60353600

Unfortunately some clients (for example s5cmd) require a 206 code and will issue a retry if any other statuscode (including 200) is received. Edit: Further testing revealed that this is an additional bug in our Range parsing, so a 200 might work (in s5cmd) even if the response is not fully compliant to the spec.

We are currently working around this by wrapping the service in a custom hyper middleware that detects the Content-Range response header and overwrites the statuscode, while this works for now ideally this should be fixed in the generated code itself.

Currently, our E2E test is not enough to catch all bugs like this. It needs enhancement in the future.