Support HTTP HEAD requests

[ghost]

Replicate

Perform an HTTP HEAD request as follows:

1. Install httpie
2. Run: http HEAD https://kroki.io/graphviz/svg/eNpLyUwvSizIUHBRqOZSUEhU0LVTSLLmqgUAVQQGWQ== --verbose

Expected

Content type set to image/svg+xml.

Actual

Content type set to text/plain.

Accept: */*
Accept-Encoding: gzip, deflate
Connection: keep-alive
Host: kroki.io
User-Agent: HTTPie/2.4.0
HTTP/1.1 404 OK
CF-Cache-Status: DYNAMIC
CF-RAY: 63ad15d1ae0cc520-ORD
Connection: keep-alive
Content-Encoding: gzip
Content-Type: text/plain
Date: Sun, 04 Apr 2021 19:53:52 GMT
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
NEL: {"report_to":"cf-nel","max_age":604800}
Report-To: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report?s=Yj37MVYec5YKZXI5B7He1vNNsQbhHSDQzOMadNdzlb4aqzcyCviEq%2B5hdxs50GtUYNYTLstBnAQm4rZQohQvB7r5ncmBQLkKLQ%3D%3D"}],"group":"cf-nel","max_age":604800}
Server: cloudflare
Set-Cookie: __cfduid=d996b29d5b1f566da2c82cd014df2d6281617566031; expires=Tue, 04-May-21 19:53:51 GMT; path=/; domain=.kroki.io; HttpOnly; SameSite=Lax; Secure
alt-svc: h3-27=":443"; ma=86400, h3-28=":443"; ma=86400, h3-29=":443"; ma=86400
cf-request-id: 09400bf7040000c5209b012000000001

Rationale

HTTP HEAD requests can reduce bandwidth.

Return Values

We will probably need to determine what Kroki should do when it receives a HEAD request. For instance, should we try to decode the payload and raise an error if the content is not properly encoded? Should we return a 200 on https://kroki.io/graphviz/svg? etc...

From the HTTP RFC, it seems 400 or 404 are suitable for bad HEAD requests where an HTTP GET for the same data would fail:

400 Bad Request The request could not be understood by the server due to malformed syntax. The client SHOULD NOT repeat the request without modifications.

404 Not Found The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.

We could also return 204:

204 No Content The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. The response MAY include new or updated metainformation in the form of entity-headers, which if present SHOULD be associated with the requested variant.

[amirabramovich]

Hi @Mogztter , I would like to help with this issue. we might need most of 'GET' service implementation for all the validations needed (which requires us to construct the diagram), but only not to return it in the response. I checked using JUnit and postman and saw that POST HEAD won't return the content OOB so I think it is ok to use the whole 'GET' service as it is.