Typescript: Http request methods should be string literal type

[kaleidawave]

Search Terms

Http Methods, lib.dom.d.ts, fetch

Suggestion

In lib.dom.d.ts wherever method is defined it should be of the type "GET" | "HEAD" | "POST" | "PUT" | "DELETE" | "CONNECT" | "OPTIONS" | "TRACE" | "PATCH". I recently had a project where it had a issue where method value was incorrect and it wasn't picked up by TypeScript. If we know the set of HTTP methods I don't see why we can't have typed method declaration.

Notably lines 1553, 6869, 12783 define weakly typed method declarations.

If Request.credentials is strongly typed then I don't see why Request.method isn't?

I have a pull request waiting, just need your feedback and confirmation.

Use Cases

• Fetch API
• <form method="..."> ?
• Request

Examples

Checklist

My suggestion meets these guidelines:

• [ ] This wouldn't be a breaking change in existing TypeScript/JavaScript code
• [x] This wouldn't change the runtime behavior of existing JavaScript code
• [x] This could be implemented without emitting different JS based on the types of the expressions
• [ ] This isn't a runtime feature (e.g. library functionality, non-ECMAScript syntax with JavaScript output, etc.)
• [x] This feature would agree with the rest of TypeScript's Design Goals.

Possible problems

• Lowercase method implementations may have to be refactored :/

[nmain]

I don't think this is correct. If I'm reading the spec correctly, method can be any string that is not a case-insensitive match for CONNECT, TRACE, TRACK. Chrome also implements this: I can fetch("/", { method: "FOO" }) and on the other end see a method FOO request come in.

Per RFC 7231, your remote server probably should have responded with 501 or 405 for this situation.

[ilogico]

I suppose it would be acceptable for HTMLFormElement.prototype.method, but surely not for fetch.

[nmain]

I suppose it would be acceptable for HTMLFormElement.prototype.method, but surely not for fetch.

Agreed; looking at the appropriate spec for that it should be "get" | "post" | "dialog".

[kaleidawave]

Interesting I was unaware of using methods other than those specified here. I understand the following could not be implemented because although there is a probably a insignificant number using alternate methods, we cannot discard them. If it is valid and is not throwing errors then there is no requirement to restrict types.

As for HTMLFormElement.prototype.method it does seem to have an fixed output, even on incorrect actions where it defaults to "get". I have tested this in Chrome via this codepen. The specification definition seems obfuscated but going of your word, line 6869 would need to be amended to your suggestion.

Although this change on its own seems inconsequential, if lib.dom.d.ts does not fully reflect the DOM api then it needs to be amended. Shame fetch cannot be altered but I guess that's just the design flaw of TypeScript wanting to maintain parallelisation with the js code.

[RyanCavanaugh]

Doesn't seem like this is a great change - we tend to err on the side of allowing more string values in the DOM than enforcing more, since browser implementations are a lot more fluid than the core JS library