Missing HEAD method when register route with GET

[rchaud]

What version of Elysia is running?

1.1.29

What platform is your computer?

Docker

What steps can reproduce the bug?

docker run -it --rm -v "$(pwd):/app" -w /app oven/bun:latest sh
Unable to find image 'oven/bun:latest' locally
latest: Pulling from oven/bun
ba83bbfca944: Already exists
f6f83b953810: Already exists
0804653e8134: Already exists
5b027434e92d: Already exists
cb42e1f96f89: Already exists
Digest: sha256:eb409bed239c3adff079a6b71283f151e802d66b99f643ba7a71e1be7d3da513
Status: Downloaded newer image for oven/bun:latest
# bun create elysia app

$ bun install
bun install v1.1.29 (6d43b366)

+ bun-types@1.1.29
+ elysia@1.1.17

9 packages installed [2.08s]

[2.10s] bun install


[2.83s] bun create elysia

Come hang out in bun's Discord: https://bun.sh/discord

-----

Dependencies were installed automatically.

Created elysia project successfully

# To get started, run:

  cd app
  bun run src/index.ts

# cd app
# bun run src/index.ts
🦊 Elysia is running at localhost:3000

What is the expected behavior?

We are expecting a 200 return code from the URL.

What do you see instead?

% curl localhost:3000/
Hello Elysia%

% curl localhost:3000/ -I
HTTP/1.1 404 Not Found
content-type: text/plain;charset=utf-8
Date: Wed, 02 Oct 2024 16:36:53 GMT
Content-Length: 9

Additional information

It seems any routes I create will result in a 404.

Have you try removing the node_modules and bun.lockb and try again yet?

yes

[rchaud]

Seems I was using the wrong curl argument

[rchaud]

Actually, it seems that curl -I or curl --head is not seeing by Elysia. Im trying to use Uptime Robot and the check is using HEAD.

[Kobusvdwalt]

I am having the same problem.
And the downstream effect of this is that provisioning an android device fails because the HEAD call returns 404.

[crishoj]

I think this works as intended.

For HEAD requests, you need to explicitly add a .head() handler, or use .all():

import Elysia from 'elysia'

const app = new Elysia()
    .get('/get', () => 'Hello from /get')
    .head('/head', () => 'Hello from /head')
    .all('/all', () => 'Hello from /all')

for (const url of ['https://example.com/get', 'https://example.com/head', 'https://example.com/all']) {
    for (const method of ['GET', 'HEAD']) {
        const res = await app.handle(new Request(url, {method}))
        console.log(method.padEnd(4), url, '→', res.status, await res.text())
    }
}

Output:

[kylecordes]

Implementing get only to find that head returns a 404 is an extremely surprising behavior versus experience with at least a dozen broadly analogous frameworks over two plus decades. Is there some way this could be enhanced to "just work" the way most developers will expect?

[byteio]

It might make sense to provide a configuration option to enable automatic HEAD binding. Typically, you wouldn't want to bind HEAD methods explicitly since the purpose of HEAD is to query an existing endpoint exclusively for headers. Otherwise, you'll end up with a lot of boilerplate code to bind every GET endpoint twice just to strip the body.

The default behavior could have unexpected impact on public websites because some intermediary systems like CDNs and crawlers use HEAD to decide whether or not to retrieve or cache an origin request.

[kylecordes]

@byteio From a few minutes research, it appears that a common solution for web servers and web application frameworks is that HEAD Requests get handled automatically by the GET handler; this provides correct behavior by default, which I think is wiser than incorrect behavior by default with an option to enable correct behavior.

Of course, correctness is not efficiency. So for applications that also need efficiency, a mechanism to handle HEAD In a way that avoids some of the work to create the whole response body should be provided also. Though this is often quite a bit of work to do since you really want the HEAD to return an accurate content length field.

[byteio]

@kylecordes I agree with you regarding your point on correct behavior, the reason I suggested an optional parameter is to hopefully get this fixed without concerns for breaking changes. I have no idea when the next major version release is planned but in an ideal world I think this behavior would be the default.

[kylecordes]

@byteio Great point about the breaking change. One of the hard questions about Semver is, does fixing a bug constitute a breaking change? In this case, I suspect most applications using Elysia are currently silently broken, serving 404s on all HEAD requests. So in some sense, they would get unbroken by an update. But if somebody is relying on intentionally 404ing the head request, then they would get broken by changing it. Offhand, I can't think of a use case for 404ing HEAD requests, but it is possible there is somebody in the user base doing so.

[byteio]

@kylecordes I think you're probably right. The population of people who benefit from fixing the broken behavior likely exceeds those who have come to rely on it. I suspect those who are doing so didn't do it intentionally, but may have implicit expectations about how other systems are interacting with their own based on things "just working" in the current state.

For example, I could imagine a scenario where the 404 prevents a CDN from caching the page, resulting in fresh results on every request, however, if the CDN VCL happens to be misconfigured to cache dynamic content, then fixing the 404 issue would result in major problems for the site. Of course, in that situation the 404 was actually masking a bug in the VCL, but the support engineer probably won't care about that distinction when pagerduty wakes them up because customers are seeing session information from random users. It's also the type of bug that could be quite difficult to track down since the bug is a subtle one. Perhaps that scenario is a little contrived, but I've seen crazier things over the years.