http.METHODS
Lists every HTTP method name this Node build's parser will accept.
http.METHODS- Added in Node.js v0.11.8
Return value
<string[]>An array of the uppercase HTTP method names supported by the parser, in ascending lexicographic order.
Errors
Never throws — it is a plain array property.
http.METHODS is the list the HTTP parser itself enforces. A request whose method is not in this array is rejected at parse time and never reaches your 'request' handler — it surfaces as a 'clientError' instead.
When to reach for it
Two honest uses. First, validating a method string before you pass it to http.request(), so a typo fails at your boundary with a clear message rather than deep in the client. Second, as a feature check: the list is compiled into the parser and grows between releases, so http.METHODS.includes('QUERY') tells you whether the running build knows the method rather than what the spec says.
What trips people up
- It is not the list you should route on. It includes 35-odd verbs — WebDAV (
PROPFIND,MKCOL), CalDAV (MKCALENDAR), and oddities likeM-SEARCHandPURGE. Your API supports a handful; check against your own list and answer405with anAllowheader. - It is case-sensitive and uppercase.
includes('get')isfalse. - The contents differ by version. Never assert on
lengthor on the exact array in a test that runs on more than one Node release. - It is a live array, not frozen — pushing to it mutates the module-level value for every consumer in the process.
Example
When to use it
- Reject an invalid method string before handing it to http.request()
- Feature-detect whether the running Node build understands a newer method such as QUERY
- Build the Allow header for a 405 response from the intersection of your routes and the supported set
- Assert in a proxy that an inbound method is one the parser will forward
Frequently asked questions
What HTTP methods does Node support?
Everything in http.METHODS — around 35 verbs, covering the standard set (GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH) plus WebDAV and CalDAV extensions such as PROPFIND, MKCOL, and MKCALENDAR. The exact list is compiled into the parser and changes between Node releases, so check with includes() rather than memorising it.
Can I use a custom HTTP method in Node?
Not for incoming requests — the parser rejects any method outside http.METHODS before your handler runs, and the connection gets a 'clientError' instead. For outgoing requests you can pass an arbitrary method string to http.request(), but whether the server accepts it is up to that server.
Is http.METHODS the list I should validate my API routes against?
No. It is what the parser accepts, not what your API supports, and it includes dozens of WebDAV verbs you almost certainly do not implement. Validate against your own per-route list and return 405 with an Allow header; use http.METHODS only to catch method strings Node itself would refuse.
More examples
Validating a method before making a request
Uppercasing first matters because the array holds only uppercase names, so a lowercase 'delete' would otherwise be rejected as unsupported. Catching the typo at the boundary turns a confusing downstream failure into a TypeError that names the offending value.
const http = require('node:http');
function call(url, method, body) {
const verb = String(method).toUpperCase();
if (!http.METHODS.includes(verb)) {
// Fail here, with a useful message, rather than inside the client.
throw new TypeError(`unsupported HTTP method: ${method}`);
}
const req = http.request(url, { method: verb }, (res) => {
console.log(verb, res.statusCode);
res.resume();
});
req.on('error', (err) => console.log(err.code));
if (body) req.write(body);
req.end();
return req;
}
call('http://127.0.0.1:8000/items/1', 'delete'); // uppercased to DELETE
try {
call('http://127.0.0.1:8000/items/1', 'DELET');
} catch (err) {
console.log(err.message); // unsupported HTTP method: DELET
}Building an Allow header for a 405
RFC 9110 requires a 405 to carry an Allow header, and generating it from the route table keeps the two from drifting apart. Sorting makes the header deterministic so it can be asserted in a test, and the intersection with http.METHODS catches a mistyped verb in the route table at request time rather than silently never matching.
const http = require('node:http');
const routes = {
'/items': { GET: listItems, POST: createItem },
'/items/1': { GET: getItem, PUT: replaceItem, DELETE: deleteItem },
};
function handlersFor(pathname) {
const table = routes[pathname];
if (!table) return null;
// Intersect with METHODS so a typo in the route table cannot
// advertise a verb the parser would never deliver.
return Object.keys(table).filter((m) => http.METHODS.includes(m)).sort();
}
const server = http.createServer((req, res) => {
const allowed = handlersFor(req.url);
if (!allowed) return res.writeHead(404).end();
if (!allowed.includes(req.method)) {
console.log(`405 ${req.method} ${req.url}; allow: ${allowed.join(', ')}`);
res.writeHead(405, { Allow: allowed.join(', ') }).end();
return;
}
routes[req.url][req.method](req, res);
});
server.listen(3000);
Discussion