Missing header "Content-Type: application/json" in response of POST /build

[jh-cd]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

Normal behaviour:

The REST POST /build returns with status code 200 as long as the parameters are given properly and the daemon can handle the request. Even in case the Dockerfile can't be processed, the status code is 200. Clients have to parse the response content for errors. It contains an error object with the error message in case an error occurred. This is no problem as long as the client knows the content is JSON.

The problem:

Some clients need the header "Content-Type application/json" to start parsing. This is the case at least in the fabric8/docker-maven-plugin we're using.

For the fabric8/docker-maven-plugin I filed the issue Plugin doesn't abort building an image in case Podman is used and the Dockerfile can't be processed #1512 and wrote a workaround (fork), commit see that issue.

Is the absence of the header intended or is it missing? If missing, a fix would be nice.

Steps to reproduce the issue:

Create a Dockerfile:

cat <<EOF > Dockerfile
FROM openjdk:8-jdk-alpine 
COPY NOT_EXISTING_FILE .
EOF

Put the Dockerfile into a tar:

tar -cf data.tar Dockerfile

Start the daemon:

systemctl --user enable --now podman.socket

Check if the daemon is running, get the unix socket from line "Listen:":

systemctl --user status podman.socket
● podman.socket - Podman API Socket
     Loaded: loaded (/usr/lib/systemd/user/podman.socket; enabled; vendor preset: enabled)
     Active: active (listening) since Fri 2022-02-04 22:59:38 CET; 2min 26s ago
   Triggers: ● podman.service
       Docs: man:podman-system-service(1)
     Listen: /run/user/1000/podman/podman.sock (Stream)
     CGroup: /user.slice/user-1000.slice/user@1000.service/podman.socket

Run the POST /build request. The --unix-socket is the one from the "Listen:" line above.

curl -v -sS -X POST -H 'Content-Type: application/tar' --unix-socket /run/user/1000/podman//podman.sock --data-binary @./data.tar http://localhost/v1.40/build

Describe the results you received:

*   Trying /run/user/1000/podman//podman.sock:0...
* Connected to localhost (/run/user/1000/podman/podman.sock) port 80 (#0)
> POST /v1.40/build HTTP/1.1
> Host: localhost
> User-Agent: curl/7.68.0
> Accept: */*
> Content-Type: application/tar
> Content-Length: 10240
> Expect: 100-continue
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Api-Version: 1.40
< Libpod-Api-Version: 3.4.2
< Server: Libpod/3.4.2 (linux)
< X-Reference-Id: 0xc0000118d0
< Date: Fri, 04 Feb 2022 22:08:25 GMT
< Transfer-Encoding: chunked
< 
{"stream":"STEP 1/2: FROM openjdk:8-jdk-alpine\n"}
{"stream":"STEP 2/2: COPY NOT_EXISTING_FILE .\n"}
{"error":"error building at STEP \"COPY NOT_EXISTING_FILE .\": checking on sources under \"/var/tmp/libpod_builder139296770/build\": copier: stat: \"/NOT_EXISTING_FILE\": no such file or directory\n"}
* Connection #0 to host localhost left intact

• The response content contains the error-message as expected.
• No "Content-Type: application/json", but expected it.

Describe the results you expected:

Expect "Content-Type: application/json" in the response.

Output of podman version:

Version:      3.4.2
API Version:  3.4.2
Go Version:   go1.16.6
Built:        Thu Jan  1 01:00:00 1970
OS/Arch:      linux/amd64

Output of podman info --debug:

host:
  arch: amd64
  buildahVersion: 1.23.1
  cgroupControllers: []
  cgroupManager: cgroupfs
  cgroupVersion: v1
  conmon:
    package: 'conmon: /usr/libexec/podman/conmon'
    path: /usr/libexec/podman/conmon
    version: 'conmon version 2.0.30, commit: '
  cpus: 2
  distribution:
    codename: focal
    distribution: ubuntu
    version: "20.04"
  eventLogger: journald
  hostname: jh-VirtualBox
  idMappings:
    gidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
    uidmap:
    - container_id: 0
      host_id: 1000
      size: 1
    - container_id: 1
      host_id: 100000
      size: 65536
  kernel: 5.13.0-27-generic
  linkmode: dynamic
  logDriver: journald
  memFree: 982728704
  memTotal: 5334114304
  ociRuntime:
    name: crun
    package: 'crun: /usr/bin/crun'
    path: /usr/bin/crun
    version: |-
      crun version UNKNOWN
      commit: ea1fe3938eefa14eb707f1d22adff4db670645d6
      spec: 1.0.0
      +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJL
  os: linux
  remoteSocket:
    exists: true
    path: /run/user/1000/podman/podman.sock
  security:
    apparmorEnabled: false
    capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
    rootless: true
    seccompEnabled: true
    seccompProfilePath: /usr/share/containers/seccomp.json
    selinuxEnabled: false
  serviceIsRemote: false
  slirp4netns:
    executable: /usr/bin/slirp4netns
    package: 'slirp4netns: /usr/bin/slirp4netns'
    version: |-
      slirp4netns version 1.1.8
      commit: unknown
      libslirp: 4.3.1-git
      SLIRP_CONFIG_VERSION_MAX: 3
      libseccomp: 2.4.3
  swapFree: 450048000
  swapTotal: 978952192
  uptime: 137h 24m 48.62s (Approximately 5.71 days)
plugins:
  log:
  - k8s-file
  - none
  - journald
  network:
  - bridge
  - macvlan
  volume:
  - local
registries:
  search:
  - docker.io
  - quay.io
store:
  configFile: /home/jh/.config/containers/storage.conf
  containerStore:
    number: 0
    paused: 0
    running: 0
    stopped: 0
  graphDriverName: overlay
  graphOptions: {}
  graphRoot: /home/jh/.local/share/containers/storage
  graphStatus:
    Backing Filesystem: extfs
    Native Overlay Diff: "true"
    Supports d_type: "true"
    Using metacopy: "false"
  imageStore:
    number: 1
  runRoot: /run/user/1000/containers
  volumePath: /home/jh/.local/share/containers/storage/volumes
version:
  APIVersion: 3.4.2
  Built: 0
  BuiltTime: Thu Jan  1 01:00:00 1970
  GitCommit: ""
  GoVersion: go1.16.6
  OsArch: linux/amd64
  Version: 3.4.2

Package info (e.g. output of rpm -q podman or apt list podman):

Listing... Done
podman/unknown,now 100:3.4.2-1 amd64 [installed]
podman/unknown 100:3.4.2-1 arm64
podman/unknown 100:3.4.2-1 armhf
podman/unknown 100:3.4.2-1 s390x

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide? (https://github.com/containers/podman/blob/main/troubleshooting.md)

No.
But there are no commits between 3.4.2 and 3.4.4 pointing to something about the header.

Additional environment details (AWS, VirtualBox, physical, etc.):

VirtualBox, REHL

[flouthoc]

@jh-cd Thanks above PR should close it.

[jh-cd]

@flouthoc Thanks!