For compatibility, ignore Content-Type

Endpoint /build logs an info entry when a client uses the wrong Content-Type for build payload. Given Content-Type is ignored and assumed to be "application/x-tar". Endpoint /libpod/build will fail unless "application/x-tar" or "application/tar" is given for Content-Type. "application/tar" will be logged as an info entry. Fixes #11012 Signed-off-by: Jhon Honce <[email protected]>
containers · Aug 11, 2021 · 5a32946 · 5a32946
1 parent 7e5a9fd
commit 5a32946
Show file tree

Hide file tree

Showing 2 changed files with 40 additions and 5 deletions.
diff --git a/pkg/api/handlers/compat/images_build.go b/pkg/api/handlers/compat/images_build.go
@@ -34,13 +34,16 @@ func BuildImage(w http.ResponseWriter, r *http.Request) {
 		contentType := hdr[0]
 		switch contentType {
 		case "application/tar":
-			logrus.Warnf("tar file content type is  %s, should use \"application/x-tar\" content type", contentType)
+			logrus.Infof("tar file content type is  %s, should use \"application/x-tar\" content type", contentType)
 		case "application/x-tar":
 			break
 		default:
-			utils.BadRequest(w, "Content-Type", hdr[0],
-				fmt.Errorf("Content-Type: %s is not supported. Should be \"application/x-tar\"", hdr[0]))
-			return
+			if utils.IsLibpodRequest(r) {
+				utils.BadRequest(w, "Content-Type", hdr[0],
+					fmt.Errorf("Content-Type: %s is not supported. Should be \"application/x-tar\"", hdr[0]))
+				return
+			}
+			logrus.Infof("tar file content type is  %s, should use \"application/x-tar\" content type", contentType)
 		}
 	}
 

diff --git a/test/apiv2/10-images.at b/test/apiv2/10-images.at
@@ -173,7 +173,7 @@ curl -XPOST --data-binary @<(cat $CONTAINERFILE_TAR) \
 BUILD_TEST_ERROR=""
 
 if ! grep -q '200 OK' "${TMPD}/headers.txt"; then
-    echo -e "${red}NOK: Image build from tar failed response was not 200 OK"
+    echo -e "${red}NOK: Image build from tar failed response was not 200 OK (application/x-tar)"
     BUILD_TEST_ERROR="1"
 fi
 
@@ -182,6 +182,38 @@ if ! grep -q 'quay.io/libpod/alpine_labels' "${TMPD}/response.txt"; then
     BUILD_TEST_ERROR="1"
 fi
 
+curl -XPOST --data-binary @<(cat $CONTAINERFILE_TAR) \
+    -H "content-type: application/tar" \
+    --dump-header "${TMPD}/headers.txt" \
+    -o /dev/null \
+    "http://$HOST:$PORT/v1.40/libpod/build?dockerfile=containerfile" &> /dev/null
+if ! grep -q '200 OK' "${TMPD}/headers.txt"; then
+    echo -e "${red}NOK: Image build from tar failed response was not 200 OK (application/tar)"
+    BUILD_TEST_ERROR="1"
+fi
+
+# Yes, this is very un-RESTful re: Content-Type header ignored when compatibility endpoint used
+# See https://github.com/containers/podman/issues/11012
+curl -XPOST --data-binary @<(cat $CONTAINERFILE_TAR) \
+    -H "content-type: application/json" \
+    --dump-header "${TMPD}/headers.txt" \
+    -o /dev/null \
+    "http://$HOST:$PORT/v1.40/build?dockerfile=containerfile" &> /dev/null
+if ! grep -q '200 OK' "${TMPD}/headers.txt"; then
+    echo -e "${red}NOK: Image build from tar failed response was not 200 OK (application/tar)"
+    BUILD_TEST_ERROR="1"
+fi
+
+curl -XPOST --data-binary @<(cat $CONTAINERFILE_TAR) \
+    -H "content-type: application/json" \
+    --dump-header "${TMPD}/headers.txt" \
+    -o /dev/null \
+    "http://$HOST:$PORT/v1.40/libpod/build?dockerfile=containerfile" &> /dev/null
+if ! grep -q '400 Bad Request' "${TMPD}/headers.txt"; then
+    echo -e "${red}NOK: Image build should have failed with 400 (wrong Content-Type)"
+    BUILD_TEST_ERROR="1"
+fi
+
 cleanBuildTest
 if [[ "${BUILD_TEST_ERROR}" ]]; then
     exit 1