This utility is used by the client, which cannot do anything about errors
received from the API. In situations where no API connection was possible,
for example, if the client has no permissions to connect to the socket,
the request would have a "-1" status-code;
https://github.com/moby/moby/blob/3e39ec60dab859f70577ea8561fe5bda5236749e/client/request.go#L133-L134

In this case, a client with "debug" enabled, would print _and_ log a confusing
error message:

    DEBU[0000] FIXME: Got an status-code for which error does not match any expected type!!!  error="Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post \"http://%2Fvar%2Frun%2Fdocker.sock/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile.repro&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=repro&target=&ulimits=null&version=1\": dial unix /var/run/docker.sock: connect: permission denied" module=api status_code=-1
    Got permission denied while trying to connect to the Docker daemon socket at unix:///var/run/docker.sock: Post "http://%2Fvar%2Frun%2Fdocker.sock/v1.24/build?buildargs=%7B%7D&cachefrom=%5B%5D&cgroupparent=&cpuperiod=0&cpuquota=0&cpusetcpus=&cpusetmems=&cpushares=0&dockerfile=Dockerfile.repro&labels=%7B%7D&memory=0&memswap=0&networkmode=default&rm=1&shmsize=0&t=repro&target=&ulimits=null&version=1": dial unix /var/run/docker.sock: connect: permission denied

In the above; `DEBU` logs the error (including the "FIXME"), and the second
line is the error message printed.

This was a mistake on my side when I added the `FromStatusCode` utility. I
implemented that to be the counterpart to `FromError`, but in doing so also
copied over the logging (see 1af30c50ca0ad81e2839ff4f2c5e70413f021d52). That
log-message is only intended to be logged on the daemon side, for situations
where we return an error without a proper errdefs (which would result in an
500 "internal server error" to be returned by the API).

This patch removes the debug log, and a minor cleanup to explicitly return
"nil" if we didn't get an error in the first place.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

This reverts the changes made in 2a9c987e5a72549775ffa4dc31595ceff4f06a78, which
moved the GetHTTPErrorStatusCode() utility to the errdefs package.

While it seemed to make sense at the time to have the errdefs package provide
conversion both from HTTP status codes errdefs and the reverse, a side-effect
of the move was that the errdefs package now had a dependency on various external
modules, to handle conversio of errors coming from those sub-systems, such as;

- github.com/containerd/containerd
- github.com/docker/distribution
- google.golang.org/grpc

This patch moves the conversion from (errdef-) errors to HTTP status-codes to a
 api/server/httpstatus package, which is only used by the API server, and should
not be needed by client-code using the errdefs package.

The MakeErrorHandler() utility was moved to the API server itself, as that's the
only place it's used. While the same applies to the GetHTTPErrorStatusCode func,
I opted for keeping that in its own package for a slightly cleaner interface.

Why not move it into the api/server/httputils package?

The api/server/httputils package is also imported in the client package, which
uses the httputils.ParseForm() and httputils.HijackConnection() functions as
part of the TestTLSCloseWriter() test. While this is only used in tests, I
wanted to avoid introducing the indirect depdencencies outside of the api/server
code.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

Signed-off-by: tonic <tonicbupt@gmail.com>

Signed-off-by: Kostadin Plachkov <k.n.plachkov@gmail.com>

full diff: https://github.com/gotestyourself/gotest.tools/compare/v2.3.0...v3.0.1

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

Fix error handling of incorrect --platform values

Before we handled containerd errors, using an invalid platform produced a 500 status:

```bash
curl -v \
  -X POST \
  --unix-socket /var/run/docker.sock \
  "http://localhost:2375/v1.40/images/create?fromImage=hello-world&platform=foobar&tag=latest" \
  -H "Content-Type: application/json"
```

```
* Connected to localhost (docker.sock) port 80 (#0)
> POST /v1.40/images/create?fromImage=hello-world&platform=foobar&tag=latest HTTP/1.1
> Host: localhost:2375
> User-Agent: curl/7.54.0
> Accept: */*
> Content-Type: application/json
>
< HTTP/1.1 500 Internal Server Error
< Api-Version: 1.40
< Content-Length: 85
< Content-Type: application/json
< Date: Mon, 15 Jul 2019 15:25:44 GMT
< Docker-Experimental: true
< Ostype: linux
< Server: Docker/19.03.0-rc2 (linux)
<
{"message":"\"foobar\": unknown operating system or architecture: invalid argument"}
```

That problem is now fixed, and the API correctly returns a 4xx status:

```bash
curl -v \
  -X POST \
  --unix-socket /var/run/docker.sock \
  "http://localhost:2375/v1.40/images/create?fromImage=hello-world&platform=foobar&tag=latest" \
  -H "Content-Type: application/json"
```

```
* Connected to localhost (/var/run/docker.sock) port 80 (#0)
> POST /v1.40/images/create?fromImage=hello-world&platform=foobar&tag=latest HTTP/1.1
> Host: localhost:2375
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Type: application/json
>
< HTTP/1.1 400 Bad Request
< Api-Version: 1.41
< Content-Type: application/json
< Docker-Experimental: true
< Ostype: linux
< Server: Docker/dev (linux)
< Date: Mon, 15 Jul 2019 15:13:42 GMT
< Content-Length: 85
<
{"message":"\"foobar\": unknown operating system or architecture: invalid argument"}
* Curl_http_done: called premature == 0
```

This patch adds tests to validate the behaviour

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

In situations where the containerd error is consumed directly
and not received over gRPC, errors were not translated.

This patch converts containerd errors to the correct HTTP
status code.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

The `statusCodeFromGRPCError` and `statusCodeFromDistributionError`
helpers are used by `GetHTTPErrorStatusCode`, which already recurses
if the error implements the `Causer` interface.

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>

The `ErrAlreadyExists` error is used for 304 statuses, which
is not an error-condition, so should probably not be defined
as part of the errdefs package.

This patch removes the `ErrAlreadyExists` interface, and related
helpers, as it was currently not used.

Note that a 304 status can fulfil certain use-cases, but (refering
to https://www.codetinkerer.com/2015/12/04/choosing-an-http-status-code.html)
could probably be handled by a 200 OK, unless we want to perform
caching in the client.

If we do want to use 304 statuses, perhaps we need a separate class
of "errors" for this (?).

Signed-off-by: Sebastiaan van Stijn <github@gone.nl>