Found while bringing lwsd up to the Oct 2026 LWS drafts (#621; lwsd CONFORMANCE.md C15).
Problem
lws10-index moved the Type Search Service to the HTTP QUERY method (RFC 10008, June 2026): the filter travels in the request body as application/lws-query+json. Node 24's parser accepts QUERY (http.METHODS includes it), but Fastify 4.29 has a fixed method list (lib/httpMethods.js) and 404s any other method before routing, so a plugin cannot register a route for it — there is no hook earlier than the router.
What lwsd does today
Prepends a listener on the raw http.Server that relabels a QUERY request as POST and remembers it in a WeakSet; the handler reports the real method. It works (Touchstone index 36/36) but it is the plugin reaching under the host.
Fix options
Fastify 5 has fastify.addHttpMethod('QUERY', { hasBody: true }); lwsd already uses it when present. Upgrading is the clean fix and benefits everything else too.
If the upgrade is not imminent: core calls addHttpMethod-equivalent at boot (Fastify 4 has no public API, so this would be the same relabel shim, once, in the host) and plugins' scope.route({ method: 'QUERY' }) just works.
WONTFIX: adding an HTTP method to the host (Fastify upgrade or a core-level relabel) is a can of worms for one plugin's search endpoint. lwsd keeps its own contained shim (prepended request listener, documented as CONFORMANCE.md C15) and that is where it stays.
Activity
melvincarvalho commented on Oct 14, 2026
WONTFIX: adding an HTTP method to the host (Fastify upgrade or a core-level relabel) is a can of worms for one plugin's search endpoint. lwsd keeps its own contained shim (prepended request listener, documented as CONFORMANCE.md C15) and that is where it stays.