The axum integration registers a route with GET and POST as filters.
|
MethodFilter::GET.or(MethodFilter::POST), |
However Axum has a default behavior that GET handlers are also used for HEAD requests, just stripping the body from the response. This causes us to reach the unreachable branch of the method match.
You can override this behavior with an explicit HEAD handler, but you cannot remove the HEAD support for a GET route.
Not implementing would be out of spec
If we do set an explicit HEAD handler returning a 405 or 501 response, that would be considered breaking specs.
As per MDN here: "Servers are required to support GET and HEAD".
Additionally Axum builds the Allow header for us and will include HEAD. So we would be simultaneously advertising it as supported, while not supporting it.
By the looks of it, we'll have to support HEAD requests. Perhaps why Axum has this default "stripped GET" to begin with.
Solutions
Axum's idea is not bad and a quick solution would be to just add HEAD to the match and treat it the same as a GET request. Axum will then drop the body for us.
That said, it seems rather wasteful to actually do queries here. Almost all useful information, including internal information like whether an RSPC route even exists, is in the body rather than headers or HTTP status. So perhaps it's semantically correct to just have an OK responder?
The axum integration registers a route with GET and POST as filters.
rspc/integrations/axum/src/v2.rs
Line 35 in 30402a4
However Axum has a default behavior that GET handlers are also used for HEAD requests, just stripping the body from the response. This causes us to reach the unreachable branch of the method match.
rspc/integrations/axum/src/v2.rs
Line 77 in 30402a4
You can override this behavior with an explicit HEAD handler, but you cannot remove the HEAD support for a GET route.
Not implementing would be out of spec
If we do set an explicit HEAD handler returning a 405 or 501 response, that would be considered breaking specs.
As per MDN here: "Servers are required to support GET and HEAD".
Additionally Axum builds the
Allowheader for us and will include HEAD. So we would be simultaneously advertising it as supported, while not supporting it.By the looks of it, we'll have to support HEAD requests. Perhaps why Axum has this default "stripped GET" to begin with.
Solutions
Axum's idea is not bad and a quick solution would be to just add HEAD to the match and treat it the same as a GET request. Axum will then drop the body for us.
That said, it seems rather wasteful to actually do queries here. Almost all useful information, including internal information like whether an RSPC route even exists, is in the body rather than headers or HTTP status. So perhaps it's semantically correct to just have an OK responder?