Access-Control-Allow-Methods

사용법

단순하지 않은 메서드로 교차 출처 요청을 보내기 전에 브라우저는 사전 요청 OPTIONS를 발행합니다. 사전 요청의 Access-Control-Request-Method 헤더는 클라이언트가 사용하려는 메서드를 알립니다. 서버는 Access-Control-Allow-Methods로 응답하여 대상 리소스에서 어떤 메서드가 허용되는지 확인해 줍니다.

단순 메서드(GET, HEAD, POST)는 CORS 프로토콜이 항상 허용하므로 엄밀히는 여기에 나열할 필요가 없습니다. 그래도 명시적으로 나열하는 것이 일반적인 관행이며, 서버 정책을 한눈에 보이게 합니다.

여러 메서드는 쉼표로 구분된 목록으로 나타납니다.

메서드 이름 목록

서버가 교차 출처 접근에 대해 받아들이는 HTTP 메서드 이름을 쉼표로 구분한 집합입니다.

Access-Control-Allow-Methods: GET, POST, PUT, DELETE

* (와일드카드)

별표는 자격 증명이 없는 요청에 대한 와일드카드로 작동하여 모든 메서드를 허용합니다.

Access-Control-Allow-Methods: *

참고

자격 증명이 포함된 요청에서 와일드카드 *는 와일드카드가 아니라 문자 그대로의 문자열로 취급됩니다. 자격 증명이 있을 때는 허용되는 각 메서드를 명시적으로 나열해야 합니다.

예시

사전 요청이 PUT 메서드가 허용되는지 묻습니다. 서버가 여러 메서드를 확인해 줍니다.

요청

OPTIONS /api/resource/42 HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: PUT

응답

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Max-Age: 7200

더 제한적인 서버는 GET과 POST만 허용합니다.

Access-Control-Allow-Methods: GET, POST

문제 해결

HTTP 메서드와 관련된 사전 요청 실패는 서버가 의도한 작업을 처리하기도 전에 실제 교차 출처 요청을 차단합니다.

콘솔에 “Method PUT is not allowed by Access-Control-Allow-Methods in preflight response.”가 표시됩니다. 서버가 요청된 메서드를 Access-Control-Allow-Methods 값에 포함시키지 않은 것입니다. 빠진 메서드를 사전 요청 응답에 추가하십시오. nginx에서는 add_header Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”; Apache에서는 Header set Access-Control-Allow-Methods “GET, POST, PUT, DELETE, PATCH”

사전 요청 응답에 헤더가 아예 없습니다. OPTIONS 핸들러는 존재하지만 Access-Control-Allow-Methods를 반환하지 않습니다. 사전 요청 라우트가 Access-Control-Allow-Origin, Access-Control-Allow-Headers와 함께 이 헤더를 설정하는지 확인하십시오. 메서드 헤더가 없으면 브라우저는 단순하지 않은 모든 메서드를 거부합니다.

자격 증명이 포함된 요청에서 와일드카드 *가 동작하지 않습니다. Access-Control-Allow-Credentials가 true일 때 와일드카드는 문자 그대로의 문자열 *로 취급되어 어떤 메서드와도 일치하지 않습니다. 자격 증명을 쓰는 구성에서는 허용되는 각 메서드를 명시적으로 나열하십시오.

사전 요청 중에 서버가 405 Method Not Allowed를 반환합니다. 대상 URL에 대해 OPTIONS를 처리하는 라우트가 없어, 요청이 메서드를 거부하는 catch-all에 걸린 것입니다. 해당 라우트에 OPTIONS 핸들러를 추가하십시오. Express에서는 app.options(‘/api/resource’, cors()) 를 사용합니다. Django에서는 django-cors-headers 미들웨어를 설치하면 OPTIONS가 자동으로 처리됩니다. nginx에서는 if ($request_method = OPTIONS) 블록을 추가하거나 limit_except 로 해당 location에서 OPTIONS를 허용하십시오.

프레임워크가 OPTIONS를 자동 처리하지만 CORS 헤더는 포함하지 않습니다. 일부 프레임워크는 OPTIONS에 200이나 204와 함께 지원 메서드를 나열한 평범한 Allow 헤더로 응답하면서 CORS 헤더는 전혀 붙이지 않습니다. Access-Control-Allow-Methods가 없으므로 브라우저는 이를 실패한 사전 요청으로 취급합니다. 프레임워크의 내장 핸들러보다 먼저 CORS 미들웨어가 OPTIONS 요청을 가로채도록 구성하십시오. Spring Boot에서는 CorsFilter 빈을 등록하십시오. ASP.NET에서는 app.UseRouting() 전에 올바른 정책으로 services.AddCors() 를 호출하십시오.