HTTP status code 500 when image over allowance for thumbnails

[wkloucek]

Describe the bug

The HTTP status code 500 looks wrong to me when

Steps to reproduce

1. configure:

      THUMBNAILS_MAX_INPUT_IMAGE_FILE_SIZE:  10MB
      THUMBNAILS_MAX_INPUT_WIDTH:            4000
      THUMBNAILS_MAX_INPUT_HEIGHT:           4000

2. upload a image that exceeds one / multiple of those limits

Expected behavior

have an HTTP status code that tells the clients, that their payload can't be processed, eg. HTTP 413 Payload Too Large

Actual behavior

we have an status code HTTP 500 Internal Server Error which says that the administrator of the server needs to take investigations and fix the service. This is just not true in this case

thumbnails-5c9c7b5bd9-ngfvf thumbnails {"level":"warn","service":"thumbnails","method":"Thumbnails.GetThumbnail","duration":188.664113,"error":"thumbnails: image is too large","time":"2024-11-18T08:09:44Z","line":"github.com/owncloud/ocis/v2/services/thumbnails/pkg/service/grpc/v0/decorators/logging.go:46","message":"Failed to execute"}
proxy-59db4b7997-5r6jc proxy {"level":"info","service":"proxy","proto":"HTTP/1.1","request-id":"5fab3e32-c581-4240-ab29-bce23061afa4","traceid":"5c71984d7e768bdd5edc5fe207fc953c","remote-addr":"31.18.255.45","method":"GET","status":500,"path":"/remote.php/dav/spaces/08892747-a1d1-42e7-9cd2-1307ce653638$449de03c-08ad-4446-a080-dc8647860e25/Foto_mit_Text.jpg","duration":214.84084,"bytes":321,"time":"2024-11-18T08:09:44Z","line":"github.com/owncloud/ocis/v2/services/proxy/pkg/middleware/accesslog.go:34","message":"access-log"}

Setup

oCIS 7.0.0-rc.2 in Kubernetes via the oCIS Helm Chart

Additional context

This prevents monitoring for HTTP 5xx status codes that are not to be expected to happen in regular cases.

[butonic]

Hm 413 Content Too Large does not really apply:

The 413 (Content Too Large) status code indicates that the server is refusing to process a request because the request content is larger than the server is willing or able to process. The server MAY terminate the request, if the protocol version in use allows it; otherwise, the server MAY close the connection.

If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.

I see three other status codes that we could use:

415 Unsupported Media Type

The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the content is in a format not supported by this method on the target resource.

The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.

If the problem was caused by an unsupported content coding, the Accept-Encoding response header field (Section 12.5.3) ought to be used to indicate which (if any) content codings would have been accepted in the request.

On the other hand, if the cause was an unsupported media type, the Accept response header field (Section 12.5.1) can be used to indicate which media types would have been accepted in the request.

AFAICT the problem is with the target resource and the server does not need to send Accept-Encoding or Accept headers as there is no MUST in the description and the server is allowed to inspect the data directly.

422 Unprocessable Content

The 422 (Unprocessable Content) status code indicates that the server understands the content type of the request content (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request content is correct, but it was unable to process the contained instructions. For example, this status code can be sent if an XML request content contains well-formed (i.e., syntactically correct), but semantically erroneous XML instructions.

Still, the real problem is not with the Request. The client did everything correct.

403 Forbidden

The 403 (Forbidden) status code indicates that the server understood the request but refuses to fulfill it. A server that wishes to make public why the request has been forbidden can describe that reason in the response content (if any).

If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.

An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).

I think this is the simplest solution and highlighted the relevant part of the description. It is simply forbidden to fetch thumbnails for images that are too large. We can even describe the reason in the response.

So, I'd vote for 403 Forbidden as we cannot send the actual reason in a 415 response.