Reverse Pull #2492

[trametheka]

Describe the bug

Edit - Whopps, 2492 is the issue, Pull is:
#2614

Pull #2492 should, in my opinion at least, be reversed. In general, HEAD requests are expected to represent a GET request without a body:
https://datatracker.ietf.org/doc/html/rfc2616/#section-9.4

I can see why the push was made, however it breaks HTTP specifications and what I would consider expected behaviour for 99.9% of Vapor users. In the users case who made the pull, they should be handling the .HEAD request themself if they need the HEAD to be different to a GET's headers. There is nothing in the specifications that a HEAD request cannot have request parameters in the URL.

This change is also creating inconsistent behaviour between routes when a HEAD request is made. For example a static route of "/hello" returns .OK regardless of the GET route, where as a dynamic route of "/hello/:name" is (correctly) forwarded to GET request.

This change also means that routes are bound to an order. Defining a route.on(.HEAD) before a route.on(.GET) will cause the .HEAD route to be overwritten.

To Reproduce

Take for example a route of https://localhost/download?file=thefile.txt

A HEAD request to this route would expect a content-length to be returned so the requester, for example a browser, would know how much is to be downloaded. As by default this GET request has a .OK HEAD responder generated for it, that content-length wouldn't be included.

Expected behavior

• A HEAD request returns the same headers as GET request in the absence of a HEAD route
• HEAD routes work regardless of order they are defined with other routes.

[trametheka]

I assume this would fix #2680 as well?

[baarde]

I agree. The response to a HEAD request should be identical to that to a GET request. A developer may implement custom routes for HEAD but the default behaviour should be to forward to GET.