Bug #55680
openRGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xml
20%
Description
Hi,
I've just tried to receive responses in different formats like json using "format" query parameter and it works.
I've seen my postman client doesn't shows the response in prettified json format and it shows that like a text response.
Then, I've seen the request responses 'Content-Type' header is on 'application/xml' while I received json response.
I tried to reproduced it on different endpoints, latest ceph demo, and our staging rgw on different version and nothing changes.
I've already monitored the postman request with burpsuite to check that if it's a postman (and not rados gateway) bug.
there is the burpsuite output for request:
GET /?format=json HTTP/1.1
Host: 127.0.0.1:8080
X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
X-Amz-Date: 20220514T080922Z
Authorization: AWS4-HMAC-SHA256 Credential=<my-credential>, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=<the-signature>
User-Agent: PostmanRuntime/7.29.0
Accept: /
Postman-Token: e95dcec3-17ee-4c8e-b21c-23227b4dccd2
Accept-Encoding: gzip, deflate
Connection: close
and there is a simple curl example:
curl -v --location --request GET '127.0.0.1:8080/?format=json' \
--header 'X-Amz-Content-Sha256: e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855' \
--header 'X-Amz-Date: 20220517T030732Z' \
--header 'Authorization: AWS4-HMAC-SHA256 Credential=<my-credential>, SignedHeaders=host;x-amz-content-sha256;x-amz-date, Signature=<singature>
and there is the burpsuite output for response:
HTTP/1.1 200 OK
x-amz-request-id: tx0000093ef8bfe57e4165a-00627f63b2-371b-default
Content-Type: application/xml
Date: Sat, 14 May 2022 08:09:22 GMT
Connection: close
Content-Length: 121
I discovered the code and think the issue is for when `end_headers` called in the `send_response` method of api classes to calculating the 'Content-Length',
with a hardcoded 'content_type' parameter to 'application/xml', or without force_content_type.
By the way I've never contributed to rgw, and I think it's better to double check it. Feel free to contact me if there is anything, that I can help about it.
Updated by Casey Bodley almost 2 years ago
I've just tried to receive responses in different formats like json using "format" query parameter and it works.
where is this 'format' query parameter documented? does the 'Accept' header work here?
Updated by Casey Bodley almost 2 years ago
- Status changed from New to Need More Info
Updated by Salar Nosrati-Ershad almost 2 years ago
where is this 'format' query parameter documented?
I found it documented on [Admin Operations](https://docs.ceph.com/en/latest/radosgw/adminops/#get-user-info) but you can use it in other rados gateway endpoints and it works. (for example I tested it when using Bucket Operations, and Topics)
Also I've found that, some endpoints don't return any Content-Type header (for example get user information endpoint), but I think it's not matter to don't return any Content-Type, the wrong Content-Type is the issue.
does the 'Accept' header work here?
I tried with Accept: \*/\* and Accept: application/json in many endpoints and nothing changes. looks like no.
Updated by Casey Bodley almost 2 years ago
- Status changed from Need More Info to New
thanks. i think the goal here is to support the Accept header properly, and leave the 'format' parameter as admin-api
Updated by Salar Nosrati-Ershad almost 2 years ago
Casey Bodley wrote:
thanks. i think the goal here is to support the Accept header properly, and leave the 'format' parameter as admin-api
I will try to fix in a PR, thanks Casey.
Updated by Salar Nosrati-Ershad almost 2 years ago
Casey Bodley wrote:
thanks. i think the goal here is to support the Accept header properly, and leave the 'format' parameter as admin-api
Should I apply this change to wild rgw_rest?
Updated by Matt Benjamin over 1 year ago
- Assignee set to Matt Benjamin
My attempts to access RGW anonymously haven't succeeded yet, but so far, I'm seeing plausibly correct behavior with Accept header, against upstream main (15f612fdbc12e11053c1a02695d41c3b10c05902).
[mbenjamin@lemon build]$ curl -v -H "Accept: application/xml" http://lemon:8000/works3 * Trying 10.17.152.22:8000... * Connected to lemon (10.17.152.22) port 8000 (#0) > GET /works3 HTTP/1.1 > Host: lemon:8000 > User-Agent: curl/7.69.1 > Accept: application/xml > * Mark bundle as not supporting multiuse < HTTP/1.1 403 Forbidden < Content-Length: 216 < x-amz-request-id: tx0000028f92bf6d9868613-0062f7c282-102c-default < Accept-Ranges: bytes < Content-Type: application/xml < Date: Sat, 13 Aug 2022 15:25:54 GMT < Connection: Keep-Alive < * Connection #0 to host lemon left intact <?xml version="1.0" encoding="UTF-8"?><Error><Code>AccessDenied</Code><BucketName>works3</BucketName><RequestId>tx0000028f92bf6d9868613-0062f7c282-102c-default</RequestId><HostId>102c-default-default</HostId></Error>[mbenjamin@lemon build]$
[mbenjamin@lemon build]$ curl -v -H "Accept: application/json" http://lemon:8000/works3 * Trying 10.17.152.22:8000... * Connected to lemon (10.17.152.22) port 8000 (#0) > GET /works3 HTTP/1.1 > Host: lemon:8000 > User-Agent: curl/7.69.1 > Accept: application/json > * Mark bundle as not supporting multiuse < HTTP/1.1 403 Forbidden < Content-Length: 139 < x-amz-request-id: tx00000e706dfcb4c8550c9-0062f7c2ba-102c-default < Accept-Ranges: bytes < Content-Type: application/json < Date: Sat, 13 Aug 2022 15:26:50 GMT < Connection: Keep-Alive < * Connection #0 to host lemon left intact {"Code":"AccessDenied","BucketName":"works3","RequestId":"tx00000e706dfcb4c8550c9-0062f7c2ba-102c-default","HostId":"102c-default-default"}[mbenjamin@lemon build]$
Updated by Matt Benjamin over 1 year ago
[mbenjamin@lemon build]$ curl -v -H "Accept: application/json" http://lemon:8000/works3/ * Trying 10.17.152.22:8000... * Connected to lemon (10.17.152.22) port 8000 (#0) > GET /works3/ HTTP/1.1 > Host: lemon:8000 > User-Agent: curl/7.69.1 > Accept: application/json > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Transfer-Encoding: chunked < x-amz-request-id: tx00000084da91c23fc8042-0062f7d7e6-103b-default < Content-Type: application/xml < Date: Sat, 13 Aug 2022 16:57:10 GMT < Connection: Keep-Alive < * Connection #0 to host lemon left intact {"Name":"works3","Prefix":"","MaxKeys":1000,"IsTruncated":"false","Contents":["pass1","2022-08-13T16:57:04.649Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Contents":["pass2","2022-08-13T16:57:03.126Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Contents":["pass3","2022-08-13T16:57:01.284Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Marker":""}
- The invalid repeated "Contents" element is the subject of https://tracker.ceph.com/issues/53455.
Updated by Matt Benjamin over 1 year ago
To further clarify. I am taking the domain of this issue specifically to be the alignment of the response content-type with that of the (RGWOp internal) Formatter--which appears to be correctly set to match the format specified in the Accept header of the request (or, at least when that is application/xml or application/json):
[mbenjamin@lemon build]$ curl -v -H "Accept: application/json" http://lemon:8000/works3/ * Trying 10.17.152.22:8000... * Connected to lemon (10.17.152.22) port 8000 (#0) > GET /works3/ HTTP/1.1 > Host: lemon:8000 > User-Agent: curl/7.69.1 > Accept: application/json > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Transfer-Encoding: chunked < x-amz-request-id: tx00000ac70c4070ceafd17-0062f7f5ef-1045-default < Content-Type: application/json < Date: Sat, 13 Aug 2022 19:05:19 GMT < Connection: Keep-Alive < * Connection #0 to host lemon left intact {"Name":"works3","Prefix":"","MaxKeys":1000,"IsTruncated":"false","Contents":["pass1","2022-08-13T16:57:04.649Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Contents":["pass2","2022-08-13T16:57:03.126Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Contents":["pass3","2022-08-13T16:57:01.284Z","\"271ec5227ced4bd1f5de40e6d665b3e1\"",4458,"STANDARD",{"ID":"testid","DisplayName":"M. Tester"},"Normal"],"Marker":""}
Correcting the json output of ListBucket is not in scope for this issue, see above.
Updated by Matt Benjamin over 1 year ago
- Status changed from In Progress to Fix Under Review
- Pull request ID set to 47577
Updated by Casey Bodley over 1 year ago
- Status changed from Fix Under Review to Pending Backport
- Backport changed from quincy to pacific quincy
Updated by Backport Bot over 1 year ago
- Copied to Backport #57202: pacific: RGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xml added
Updated by Backport Bot over 1 year ago
- Copied to Backport #57203: quincy: RGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xml added
Updated by Backport Bot over 1 year ago
- Tags changed from rest, content-type to rest, content-type backport_processed