비 - 사용자 정의 헤더가 Access-Control-Request-Headers에 포함되는 이유는 무엇입니까?

Question

원본 출처 요청을 보내려고합니다. 지금까지 Access-Control-Request-Headers에 관한 한, FireFox, Chrome 및 Safari에서는 다른 동작이 나타납니다.

Chrome :- Access-Control-Request-Headers: origin, content-type, accept 
Safari :- Access-Control-Request-Headers: origin, content-type, accept 
Firefox:- Access-Control-Request-Headers: content-type 

내 질문이 있습니다 : -

1. 어떻게 브라우저에서 액세스 제어 - 요청 헤더의 일부가 될 것이다 헤더 결정합니까?
2. 내가 아는 한 Access-Control-Request-Headers에는 사용자 지정 헤더 만 있어야하지만 세 가지 (허용, 원본 및 내용 유형)는 사용자 지정 헤더가 아닙니다. 그렇다면 왜 그들은 Access-Control-Request-Headers의 일부입니까?
3. 브라우저마다 동작이 다른 이유는 무엇입니까?

Answer 1

여기에는 여러 가지 사항이 있으므로 한 번에 하나씩 답해 보겠습니다.

크롬과 사파리는 모두 WebKit을 기반으로하므로 브라우저에서 똑같은 동작을 보게됩니다 (Chrome은 곧 눈 깜빡 할 것 같지만 아직 사용자의 손이 아닙니다).

최신 CORS 사양에 따르면 Accept은 간단한 요청 헤더입니다. Origin은 단순 요청 헤더 목록에 포함되어 있지 않지만 CORS의 기초이므로 지원되지 않는 것은 어리석은 일입니다. 기술적으로 Firefox는 올바른 일을합니다.

그러나 크롬/사파리가 Accept 및 Origin 헤더를 포함하지만, 그들은 그 헤더가 Access-Control-Allow-Headers 응답 헤더에 포함되어 있는지 확인하지 있습니다. 프리 플라이트 요청 헤더 Access-Control-Request-Headers: accept, origin을 가지고

가

http://client.cors-api.appspot.com/client#?client_method=PUT&client_credentials=false&client_headers=Accept%3A%20%2A%2F%2A&server_enable=true&server_status=200&server_credentials=false&server_methods=PUT&server_tabs=local

참고하지만, 응답에는 Access-Control-Allow-Headers이없는 다음과 같은 링크를 방문하여 확인할 수 있습니다. 실제 CORS 요청은 여전히 ​​성공합니다. application/x-www-form-urlencoded, multipart/form-data 또는 text/plain : 그 값이 다음 중 하나 인 경우에만

Content-Type 헤더는 간단한 요청 헤더 여겨진다. 다른 모든 값은 프리 플라이트를 트리거합니다. 아마 당신이 여기서 본 것입니다.

브라우저가 왜 이런 식으로 행동하는지 알 수 없습니다. 웹킷이나 파이어 폭스 게시판에서 물어볼만한 가치가있을 것입니다.

https://trac.webkit.org/browser/trunk/Source/WebCore/loader/CrossOriginAccessControl.cpp?order=name#L117

그것은 단순한 헤더를 제거하지 않고, 모든 헤더를 나열하는 것 같다 : 여기 웹킷은 Access-Control-Request-Headers 헤더를 설정하는 코드입니다. 응답 측면에는 Access-Control-Allow-Headers 응답의 단순하지 않은 헤더 만 기대하는 코드가 있다고 생각합니다.