Description
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