A preflight answer lists only PUT in Access-Control-Allow-Methods; which cross-origin methods may the caller still attempt?

When a cross-origin call has to be asked about before it is made, the server's answer is a small set of grant fields. `Access-Control-Allow-Methods` is the method half of that answer, and the question interviewers actually ask about it is what it does *not* need to contain. ## What the field states `Access-Control-Allow-Methods = #method` is a comma-separated list of methods the browser may use for the actual request that follows. It is written by the **server**, on the preflight response, and it is one of the list-valued grant fields - unlike `Access-Control-Allow-Origin`, which holds exactly one value. ## The check passes two ways The method check does not simply ask whether the requested method appears in the list. It succeeds if **either** of these holds: 1. the method appears in the granted list, or 2. the method is a **CORS-safelisted method**, which is `GET`, `HEAD` or `POST`. Those three need no grant to be attempted. So a gauge feed that answers `Access-Control-Allow-Methods: PUT` has granted `PUT` *in addition to* the three, not instead of them: | granted list | may the caller use PUT | may the caller use GET | |---|---|---| | `PUT` | yes, it is listed | yes, it is safelisted | | `GET` | no, not listed and not safelisted | yes | | field absent | no | yes | | `*` (no credentials) | yes | yes | The last row is the wildcard reading, which applies to a request made without credentials; a request in credentialed mode reads every wildcard differently, and that is a separate subject. The practical read is that the list exists to grant the methods *beyond* the safelisted three, and an answer that carefully enumerates `GET, HEAD, POST` has spent bytes granting what was never withheld. ## The field that looks like the grant and is not `Allow` is a response header of core HTTP - it appears in RFC 9110 - and it has no role in the CORS protocol at all. The names are close enough that a server answering a preflight with ```http HTTP/1.1 204 No Content Allow: GET, PUT, OPTIONS ``` looks, at a glance, like it has answered. It has not. No `Access-Control-` grant field is present, so no origin was granted, no method was granted, and the browser withholds the response from script. This is worth recognising on sight, because the response *is* well-formed HTTP and a reader who is scanning for a comma-separated method list will find one. ## What a granted method is not Three separate things are easy to collapse into the word *allowed*, and only the first is what this field decides: - **the browser permitting the request to be made and its response to be read** - that is what the grant does; - **the server accepting and processing the request** - routing and handler logic, entirely independent of any grant; - **an authorization decision about the resource** - whether *this caller* may write *this station's* readings, which is the application's business. So granting `PUT` does not commit the server to accepting a `PUT`: the grant is browser-facing, and the server may still refuse the method or the caller on its own terms. In the other direction, a method that the server would happily process is still withheld from script if it is neither listed nor safelisted, because the browser never issues the actual request at all. ## Where the header half goes The method is one half of a preflight's answer; the other half is `Access-Control-Allow-Headers = #field-name`, naming the request header field names the caller may send. The two are independent: a grant that names the method and omits a header the caller needs fails just as completely as one that names neither, and the failure looks identical from the calling side. When you are reading a preflight answer, read both fields before concluding anything about the method. One last direction check, because this material stays grammatical when stated backwards: `Access-Control-Allow-Methods` is sent **by the server**, in a response. Anything named `Access-Control-Request-...` travels the other way. Naming a request field as a response grant, or the reverse, is the single most common wrong answer in this whole subject.