HTTP OPTIONS 요청에 응답하는 방법은 무엇입니까?

Question 1

HTTP OPTIONS메서드는 서버가 주어진 리소스에서 지원하는 다른 메서드를 결정하는 데 사용됩니다. 이를 감안할 때 두 가지 질문이 있습니다.

이 응답은 어떻게 생겼습니까? 나는에서 CSV의 목록과 예를 보았다 Public, Allow그리고 심지어 Access-Control-Allow-Methods헤더를. 모두 필요합니까? 차이점이 뭐야? RFC 2616 은 여기에서별로 도움이되지 않는 것 같습니다.
비 REST-API 환경에서 리소스가 지원하는 작업을 나열하는 데 이것을 사용하는 것이 적절합니까? 예를 들어, 내가 ConversionController행동을 지원 한다면convert 과 같은 응답이 의미가 있습니다.

의뢰:

OPTIONS /conversion HTTP/1.1

응답:

HTTP/1.1 200 OK
...
Allow: CONVERT
...

Question 2

RFC 2616은 "허용"( http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.14.7 )을 정의합니다 . "공개"는 더 이상 사용되지 않습니다. "Access-Control-Allow-Methods"는 CORS 사양에 정의되어 있습니다 ( http://www.w3.org/TR/cors/ 참조 ).

Question 3

제목 : "HTTP OPTIONS 요청에 응답하는 방법"에 대한 응답 이에 대한 대답을 위해 OPTIONS 요청에 응답하려는 이유를 알고 싶습니다. 누가 / 무엇을 OPTIONS 요청을 보내고 있으며 그 이유는 무엇입니까? 많은 공용 서버가 "오류"또는 "허용되지 않음" (500, 501, 405) 형식으로 응답 합니다. 따라서 클라이언트가 OPTIONS 요청을 합리적으로 보내고 유용 / 의미있는 정보 (예 : WebDAV, CORS)를 기대하는 특정 상황에 있지 않는 한 "하지 마십시오."

"OPTIONS / conversion HTTP / 1.1"요청에 대한 질문과 관련하여 : 서버의 일부 클라이언트가 있다는 것을 알지 못하는 경우 "/ conversion"에 OPTIONS 요청을 보내고 "허용 : CONVERT"로 응답을 기대하는 클라이언트 , "대답은 '아니오'입니다. 그렇게 응답하는 것은 말이되지 않습니다. 나는 대부분의 구현 생각 할 수 와 지원 옵션 및 응답이 "허용"표준 HTTP 방법과 응답.

주제에 대한 훌륭한 기사가 있습니다.

요약 : OPTIONS는 캐싱을 지원하지 않기 때문에 즉시 문제가됩니다. 대안 : 서버 전체 메타 데이터 : 잘 알려진 URI의 . 리소스 별 : 응답에 링크 헤더 를 사용 하거나 해당 리소스에 대한 표현 형식의 링크를 사용해보십시오 .

마지막으로 서비스 설명이 필요한 경우 WADL 또는 RSDL을 살펴보십시오 .

편집하다:

dotnetguy는 아래 주석에서 좋은 지적을합니다. OPTIONS는 특정 컨텍스트 (예 : CORS)에서 부인할 수없는 가치가 있습니다. 나는 분명히 달리 제안 할 의도가 없었다.

Question 4

HTTP OPTIONS 요청이란 무엇입니까?

서버가 허용 할 HTTP 메소드를 알기위한 클라이언트의 요청입니다. GET , POST등

의뢰

특정 리소스에 대한 옵션을 요청할 때 요청은 다음과 같을 수 있습니다.

OPTIONS /index.html HTTP/1.1

또는 일반적으로 서버에 대해 질문 할 때 다음과 같이하십시오.

OPTIONS * HTTP/1.1

응답

응답에는 Allow허용 된 메소드 가있는 헤더 가 포함됩니다 .

Allow: OPTIONS, GET, HEAD, POST

서버가 HTTP OPTIONS 요청을 수신하는 이유는 무엇입니까?

일부 REST API에는 필요합니다 (하지만 API를 정의하는 경우 알고있을 것입니다)
브라우저는 서버가 CORS를 이해하는지 확인하기 위해 "프리 플라이트 된"요청으로 서버에 전송합니다.
공격자는 API에 대한 더 많은 정보를 얻기 위해 그것을 보냅니다.