How to allow HEAD requests?

[cinderblockgames]

The Jump dashboard uses HEAD requests to check if a site is up, but making a HEAD call to Authelia behind Traefik is resulting in a 405 Method Not Allowed. Is there a way to enable HEAD requests?

[james-d-elliott]

We handle HEAD requests appropriately for most legitimate use cases, for endpoints that do not have any specific HEAD responses we appropriately respond with a 405 per web standards. What endpoint are you trying to make HEAD requests to or what are you trying to do?

[cinderblockgames]

@james-d-elliott The request is for https://login.example.com/?rd=https%3A%2F%2Frecipes.example.com%2F&rm=HEAD but I get a 405 just going straight to Authelia as well:

curl -I https://login.example.com

HTTP/1.1 405 Method Not Allowed
content-length: 22
content-type: text/plain; charset=utf-8
date: Mon, 27 Feb 2023 21:37:46 GMT
strict-transport-security: max-age=60;

[james-d-elliott]

Also.. how would Jump provide the credentials? Do you mean it would need to automate seeing the redirect, submitting the Authelia form, and following the redirect with the provided cookie? Or is there a simpler way? Could I just do https://testuser:password@recipes.example.com and have Authelia pick that up?

Forwarding the Cookie, or *Authorization headers, or sending its own Proxy-Authorization header with 1FA credentials using the basic scheme.

[cinderblockgames]

How does it stink for your use case? It will always show as up if Authelia and the proxy are up, so there's no point in having the status check at all for individual apps, it's just an inefficient request.

It would only redirect if the container is up, but otherwise, fair points all. Thanks.

[james-d-elliott]

It would only redirect if the container is up, but otherwise, fair points all. Thanks.

Hence why it should be configurable. One other aspect to this is the status check should allow the end user to determine which status codes are a successful response. For example a 30x should in your use case indicate the container is most likely up (Traefik does not necessarily do this status check unless you use the label and labels are not the only way to configure Traefik, in addition the status of a container may not change immediately and traefik may not pick up the container status change immediately) so they should not be followed.

In addition a 405 Method Not Allowed response would also indicate the container is running, and is responding correctly. This is because it indicates the path exists and can serve other method verbs, but the particular method verb used is not appropriate. This should only occur if the container is up and serving requests, and the endpoint may service other request method verbs. 405 is pretty unique in this way, though this argument could theoretically be argued for several other 4xx status codes depending on the application. Making it fairly important that this is something users can configure.

[james-d-elliott]

I'm going to adjust most of the static assets and the /api/status /api/heath endpoint to respond to HEAD requests as it's easier than I thought and the only issues I can see it introducing are when someone has misconfigured something (which will have people complain that it's a breaking change even though it just isn't) however I think all of those points still stand regarding appropriate status checks should have configurable request method, request headers, request body, valid response statuses, and choice of following redirects.

[cinderblockgames]

I agree, and thank you.