Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

containers list api route response header is text/plain instead of application/json #14647

Closed
iongion opened this issue Jun 17, 2022 · 1 comment · Fixed by #14662
Closed

containers list api route response header is text/plain instead of application/json #14647

iongion opened this issue Jun 17, 2022 · 1 comment · Fixed by #14662
Assignees
@Luap99
Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@iongion
Copy link

iongion commented Jun 17, 2022 •
edited
Loading

/kind bug

Description

Response content-type header is not application/json for containers list endpoint, although negotiation requests it.
Some client libraries do attempt deserializing automatically to their data structures. Although it can be mitigated as an exception for this route, it should respect the negotiation. (v3 and v4 have the same behavior)

Steps to reproduce the issue:

  1. base url v3.0.0 - curl -v -X GET --unix-socket "/run/user/1000/podman/podman.sock" "http://d/v3.0.0/libpod/containers/json" -H "Accept: application/json" -H "Content-Type: application/json"

  2. base url v4.0.0 - curl -v -X GET --unix-socket "/run/user/1000/podman/podman.sock" "http://d/v4.0.0/libpod/containers/json" -H "Accept: application/json" -H "Content-Type: application/json"

Describe the results you received:

> GET /v4.0.0/libpod/containers/json HTTP/1.1
...
< Content-Type: text/plain; charset=us-ascii
< Libpod-Api-Version: 4.1.0
...

Describe the results you expected:

> GET /v4.0.0/libpod/containers/json HTTP/1.1
...
< Content-Type: application/json; charset=us-ascii
< Libpod-Api-Version: 4.1.0
...

If any use, issued the same for docker api and it does have application/json as response content-type header

docker --version
Docker version 20.10.16, build aa7e414fdc

curl -v -X GET --unix-socket "/var/run/docker.sock" "http://localhost/containers/json" -H "Accept: application/json" -H "Content-Type: application/json"
Note: Unnecessary use of -X or --request, GET is already inferred.
*   Trying /var/run/docker.sock:0...
* Connected to localhost (/run/docker.sock) port 80 (#0)
> GET /containers/json HTTP/1.1
> Host: localhost
> User-Agent: curl/7.83.1
> Accept: application/json
> Content-Type: application/json
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Api-Version: 1.41
< Content-Type: application/json
< Docker-Experimental: false
< Ostype: linux
< Server: Docker/20.10.16 (linux)
< Date: Fri, 17 Jun 2022 15:57:22 GMT
< Transfer-Encoding: chunked

IMPORTANT EDIT - It only happens when the list of containers is empty, as soon as at least one is present it respects!
@openshift-ci openshift-ci bot added the kind/bug Categorizes issue or PR as related to a bug. label Jun 17, 2022
@Luap99 Luap99 self-assigned this Jun 20, 2022
@Luap99 Luap99 added the In Progress This issue is actively being worked by the assignee, please do not work on this at this time. label Jun 20, 2022
Luap99 added a commit to Luap99/libpod that referenced this issue Jun 20, 2022
@Luap99
API: container/list always set application/json content type
ebb7cd0 
When we return no contianers we just return '[]' but we still have to keep
the content type header application/json so external tools can correctly
parse the output.

Fixes containers#14647

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99 added a commit to Luap99/libpod that referenced this issue Jun 20, 2022
@Luap99
API: container/list always set application/json content type
5f0501a 
When we return no containers we just return `[]` but we still have to keep
the content type header `application/json` so external tools can correctly
parse the output.

Fixes containers#14647

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
Luap99 added a commit to Luap99/libpod that referenced this issue Jun 20, 2022
@Luap99
API: containers/json always set application/json content type
bb5bd09 
When we return no containers we just return `[]` but we still have to keep
the content type header `application/json` so external tools can correctly
parse the output.

Fixes containers#14647

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@Luap99 Luap99 mentioned this issue Jun 20, 2022
Merged
@Luap99
Copy link
Member

Luap99 commented Jun 20, 2022

#14662 should fix it

gbraad pushed a commit to gbraad-redhat/podman that referenced this issue Jul 13, 2022
@Luap99
API: containers/json always set application/json content type
9d2967e 
When we return no containers we just return `[]` but we still have to keep
the content type header `application/json` so external tools can correctly
parse the output.

Fixes containers#14647

Signed-off-by: Paul Holzinger <pholzing@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 20, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 20, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@Luap99 Luap99

Labels
In Progress This issue is actively being worked by the assignee, please do not work on this at this time. kind/bug Categorizes issue or PR as related to a bug. locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

API: containers/json always set application/json content type Luap99/libpod
2 participants
@iongion @Luap99