addHttpMethod override existing http standard methods

Prerequisites

I have written a descriptive issue title
I have searched existing issues to ensure the issue has not already been raised

Issue

While reading ticket #6283 and checking the source code, I realized that addHttpMethod override existing methods, including standard http methods.

Surprisingly, the name of the function does not reflect its implementation, nor does the documentation.

I wonder if we should do something about this.

Here are a few options:

At a minimum, document this behavior.
Disable the override behavior in the next major and add an alternative method (e.g., setHttpMethod or overrideHttpMethod) or option (e.g. override: true).
Perhaps a combination of both.

Sorry, maybe I opened this issue too quickly.
Will take a deeper look, keep open if any feedback.

@Eomm

Funny right? 😁 I actually think that we discussed this behaviour when @Eomm implemented it.

I just remembered that function, and when I checked that code i saw no override protection... So i am actually kind of proud that we could help this guy out with this functionality. Also we have anyway a limititation by nodejs/llhttp.

Yeah, I'm pro on supporting legacy behaviour because we can list whatever RFCs, but the real world needs to handle request body on GET handlers and blocking this feature is like closing out part of the community that choose fastify.

Regarding rethinking a new interface to improve the clarity or documentation I'm always in favour of it!

@Uzlopak

@Uzlopak, I'm really glad you could help this guy, a.k.a me lol.

I kindly ask you guys not to change this behavior, so we don't have to revisit this topic again, and maybe there are some smarter people out there that already figured that out without the need of asking for help, who could have problems with it, too.

If any change can be made, maybe improving docs (which I can contribute if you want), or maybe implementing an allowGetBody to wrap this call to make it more semantic.

I recommend that we address the misleading nature of the current addHttpMethod.

We can improve this smoothly without disrupting users:

Introduce a new method (e.g. overrideHttpMethod) now.
Add a deprecation warning in addHttpMethod when it is used to override an existing method.
In next, change addHttpMethod by throwing an error instead of warning.

But, TBH, method overriding was never documented, and relying on it means depending on internal behavior, which shouldn’t be considered stable. So I’d even consider treating it as a bug, throwing a clear error with a message directing users to the new method or option would be justified.

I’m happy to open a PR for this if @fastify/core agrees.

To recap:

overrideHttpMethod to override default methods (I would just check if we use override or overwrite somewhere)
addHttpMethod to add non-strict standard methods (+ if default method is used as arg: v5=warning, v6=error)

makes sense to me 👍🏼

Questions

what if I add a method with addHttpMethod and then the same one with overrideHttpMethod? (asking because a plugin odd configuration may happen)
what if I add a method with overrideHttpMethod and then the same one with addHttpMethod?

I personally dislike the idea of having "overrideHttpMethod" or "overwriteHttpMethod". What am I overriding or overwriting? the HttpMethod on an incoming request? We actually want to configure http methods. A subsequent call to the addHttpMethod will reconfigure the method again.

The only question ,.. g2g

The only question for me is, do we encapsulate this behavior?

The only question for me is, do we encapsulate this behavior?

Yes, it is using decorator.

I thint that we basically want to implement one day all the relevant HTTP Methods which are supported by nodejs into fastify core. Well except CONNECT. And if so, addHttpMethod woulld be pointless, because we couldnt add more http methods.

I suggest configureHttpMethod

I think we should only implement these by default and let others add more or configure the existing ones

I am not against the current behavior of addHttpMethod, I just think the name is misleading.

Maybe we can just rename addHttpMethod -> configureHttpMethod in next major.
For now, we trigger a deprecation warning on addHttpMethod.
Upgrading to the next major version will be a little more brutal for those who ignore the warnings.

overrideHttpMethod to override default methods (I would just check if we use override or overwrite somewhere)

addHttpMethod to add non-strict standard methods (+ if default method is used as arg: v5=warning, v6=error)

I don't think it is worth being so disruptive. The issue that has spawned this thread is an edge case. If overwriting an existing method through addHttpMethod is confusing, I'd argue it's only because it "accidentally" worked and is not documented as a valid use case. If anything outside of documentation improvement is required, I'd suggest adding an options parameter to the existing method and accept { overrideExisting: true }.

I'd suggest adding an options parameter to the existing method and accept { overrideExisting: true }

I still think the name is inappropriate, but I consider it an improvement that could be a solution, so ok for me.
However, I think we should trigger an error if users try to override with overrideExisting: false (default) rather than silently skipping the override, which may be even more surprising.
So there is still a risk of light breaking change, it's just less disruptive than dropping the method for a new one.

Perhaps we could list the offered solutions in this thread and vote.

I agree that the current name is misleading; it'd be easier to figure out that it'd solve my problem if it were named configureHttpMethod, so, creating this new method and adding a warning to addHttpMethod when used to modify a previously existing method seems like a good solution to me.

What should we do about this?
I keep thinking the current name is inappropriate, adding is semantically very different from setting or overriding.

I propose deprecating addHttpMethod in favor of setHttpMethod in the next major.
This would let users set any method they need.

fix: warn when addHttpMethod overrides an existing HTTP method

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

Navigation Menu

Repository navigation

`addHttpMethod` override existing http standard methods #6284

Prerequisites

Issue

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

addHttpMethod override existing http standard methods #6284

Description

Prerequisites

Issue

Activity

jean-michelet commented on Aug 10, 2025

Uzlopak commented on Aug 10, 2025

Eomm commented on Aug 10, 2025

Farenheith commented on Aug 10, 2025

jean-michelet commented on Aug 10, 2025

Eomm commented on Aug 11, 2025

Uzlopak commented on Aug 11, 2025

Uzlopak commented on Aug 11, 2025

climba03003 commented on Aug 11, 2025

Uzlopak commented on Aug 11, 2025

gurgunday commented on Aug 11, 2025

jean-michelet commented on Aug 11, 2025

jsumners commented on Aug 11, 2025

jean-michelet commented on Aug 11, 2025

Farenheith commented on Aug 11, 2025

jean-michelet commented on Sep 23, 2025

mahmoodhamdi commented on Mar 15, 2026

github-actions commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

`addHttpMethod` override existing http standard methods #6284