Project

General

Profile

Actions

Bug #55680

open

RGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xml

Added by Salar Nosrati-Ershad almost 2 years ago. Updated over 1 year ago.

Status:
Pending Backport
Priority:
Normal
Assignee:
Target version:
-
% Done:

20%

Source:
Tags:
rest, content-type backport_processed
Backport:
pacific quincy
Regression:
No
Severity:
4 - irritation
Reviewed:
08/09/2022
Affected Versions:
ceph-qa-suite:
rest, rgw
Pull request ID:
Crash signature (v1):
Crash signature (v2):

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.


Related issues 2 (1 open1 closed)

Copied to rgw - Backport #57202: pacific: RGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xmlRejectedMatt BenjaminActions
Copied to rgw - Backport #57203: quincy: RGW rest API returns responses with header 'Content-Type: application/xml' even when body content type isn't xmlNewMatt BenjaminActions
Actions #1

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?

Actions #2

Updated by Casey Bodley almost 2 years ago

  • Status changed from New to Need More Info
Actions #3

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.

Actions #4

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

Actions #5

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.

Actions #6

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?

Actions #7

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]$
Actions #8

Updated by Matt Benjamin over 1 year ago

  • Status changed from New to In Progress
Actions #9

Updated by Matt Benjamin over 1 year ago

Ok, having fixed the bucket policy, json (*) output is produced with a correct header:
[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":""}
Actions #10

Updated by Matt Benjamin over 1 year ago

oops, sorry, no it isn't :)

Actions #11

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.
Actions #12

Updated by Matt Benjamin over 1 year ago

  • Status changed from In Progress to Fix Under Review
  • Pull request ID set to 47577
Actions #13

Updated by Ken Dreyer over 1 year ago

  • Backport set to quincy
Actions #14

Updated by Casey Bodley over 1 year ago

  • Status changed from Fix Under Review to Pending Backport
  • Backport changed from quincy to pacific quincy
Actions #15

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
Actions #16

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
Actions #17

Updated by Backport Bot over 1 year ago

  • Tags changed from rest, content-type to rest, content-type backport_processed
Actions

Also available in: Atom PDF