Access-Control-Allow-Headers
사용법
브라우저가 사전 요청 OPTIONS를 발행할 때, Access-Control-Request-Headers 헤더는 클라이언트가 보내려는 안전 목록에 없는 헤더들을 나열합니다. 서버는 Access-Control-Allow-Headers로 응답하여 그중 어떤 헤더가 허용되는지 확인해 줍니다.
CORS 안전 목록 헤더는 항상 허용되므로 이 목록에 나타날 필요가 없습니다. 안전 목록에는 Accept, Accept-Language, Content-Language, Content-Type(미디어 타입과 값 길이에 제약이 있음), Range(형식에 제약이 있음)가 포함됩니다. 안전 목록 헤더를 명시적으로 나열하면 값에 걸린 추가 제약이 사라집니다.
여러 헤더 이름은 쉼표로 구분된 목록으로 나타납니다.
헤더 이름 목록
서버가 실제 요청에서 받아들이는 헤더 이름을 쉼표로 구분한 집합입니다.
Access-Control-Allow-Headers: Content-Type, Authorization* (와일드카드)
별표는 자격 증명이 없는 요청에 대한 와일드카드로 작동하여 모든 헤더 이름을 허용합니다.
Access-Control-Allow-Headers: *참고
자격 증명이 포함된 요청에서 와일드카드 *는 와일드카드가 아니라 문자 그대로의 문자열로 취급됩니다. 자격 증명이 있을 때는 허용되는 각 헤더를 명시적으로 나열해야 합니다. Authorization 헤더는 와일드카드에 결코 포함되지 않으므로 언제나 명시적으로 이름을 적어야 합니다.
예시
사전 요청이 Content-Type과 커스텀 X-Request-ID 헤더가 허용되는지 묻습니다. 서버가 둘 다 확인해 줍니다.
요청
OPTIONS /api/data HTTP/1.1
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type, X-Request-ID응답
HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: POST
Access-Control-Allow-Headers: Content-Type, X-Request-ID
Access-Control-Max-Age: 86400자격 증명이 없는 요청에 와일드카드를 쓰는 서버는 한 글자로 응답합니다.
Access-Control-Allow-Headers: *문제 해결
요청 헤더와 관련된 사전 요청 실패는 콘솔 오류를 내고 실제 요청을 차단합니다.
콘솔에 “Request header field X is not allowed by Access-Control-Allow-Headers in preflight response.”가 표시됩니다. 서버가 해당 헤더 이름을 Access-Control-Allow-Headers 값에 나열하지 않은 것입니다. 빠진 헤더를 사전 요청 응답에 추가하십시오. nginx에서는 add_header Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”; Apache에서는 Header set Access-Control-Allow-Headers “Content-Type, Authorization, X-Request-ID”
사전 요청 응답에 헤더가 아예 없습니다. 서버가 OPTIONS 요청을 처리하지만 응답에 Access-Control-Allow-Headers를 포함하지 않습니다. 많은 프레임워크가 사전 요청 라우트에 대해 명시적인 CORS 설정을 요구합니다. OPTIONS 핸들러나 미들웨어가 Access-Control-Allow-Methods, Access-Control-Allow-Origin과 함께 이 헤더를 설정하는지 확인하십시오.
자격 증명이 포함된 요청에서 와일드카드 *가 동작하지 않습니다. Access-Control-Allow-Credentials가 true일 때 와일드카드는 문자 그대로의 문자열 *로 취급되어 아무것과도 일치하지 않습니다. 허용되는 각 헤더를 명시적으로 나열하십시오. Authorization 헤더는 자격 증명이 없는 요청에서도 와일드카드에 포함되지 않으므로 언제나 이름을 적어야 합니다.
일부 서버에서 헤더 이름이 대소문자를 구분하는 것처럼 보입니다. 프로토콜상 HTTP 헤더 이름은 대소문자를 구분하지 않지만, 일부 서버 프레임워크는 허용 목록을 확인할 때 대소문자를 구분하는 문자열 비교를 수행합니다. 서버가 Content-Type만 나열했다면 content-type을 보내는 요청이 실패할 수 있습니다. 클라이언트가 보내는 대소문자에 맞추거나, CORS 설정에서 양쪽을 모두 소문자로 정규화하십시오.
Content-Type: application/json을 보내면 예상치 못한 사전 요청이 발생합니다. Content-Type 헤더는 application/x-www-form-urlencoded, multipart/form-data, text/plain 값에 대해서만 안전 목록에 포함됩니다. application/json 값은 안전 목록을 벗어나므로 사전 요청을 강제합니다. Access-Control-Allow-Headers 목록에 Content-Type을 추가하십시오. 사전 요청이 발생하는지 확인하려면 DevTools의 Network 탭을 열고 메서드로 필터링하여 실제 요청에 앞서는 OPTIONS 요청을 찾으십시오.