`assertMethod` must set `Allow` header, as per spec

[binyamin]

Describe the feature

The current (v2.0.0-beta.4) implementation of the assertMethod util just generates a generic error with a 405 status. Per RFC 9110, a 405 status code must be accompanied by a list of supported HTTP methods in the Allow header field. The current implementation does not do this, nor does it provide a way to add the header directly.

Example

HTTP/1.1 405 Method Not Allowed
Content-Length: 0
Date: Fri, 28 Jun 2024 14:30:31 GMT
Allow: GET, POST, HEAD

If the goal is to send a valid 405 response for unsupported methods, I feel that we can do better than assertMethod. An optimal implementation would have intimate knowledge of registered routes and methods. More importantly, it knows exactly which methods are not supported for any given request. H3 core fits this definition; userland does not.

In theory, I could use map app._routes for every request. I haven't tried. But, underscored properties are usually internal, unofficial and/or subject to change. Again, core, not userland.

Note: I'd be happy to discuss the best way to implement this feature. I could even open a PR, if you don't mind me tracking mud all over the codebase. 😜

Additional information

• Would you be willing to help implement this feature?

[sandros94]

Good point @binyamin, tho atm I wouldn't go down the route of scanning currently registered routes.

Instead, since assertMethod does require a second argument with the expected methods, we could simply use that as a source of truth for that response. It would simply mean adding the Allow response header with that expected method/s in the implementation:

h3/src/utils/request.ts

Lines 256 to 264 in 62356d7

	export function assertMethod(
	event: HTTPEvent,
	expected: HTTPMethod | HTTPMethod[],
	allowHead?: boolean,
	): void {
	if (!isMethod(event, expected, allowHead)) {
	throw new HTTPError({ status: 405 });
	}
	}