참고 자료

• 이병록님이 번역하신 HTTP 1.1 Semantics and Content 번역본
  https://roka88.dev/106
• MDN Web Docs
  https://developer.mozilla.org/ko/docs/Web/HTTP

이외 자료는 내용 중 링크 추가

틀린 내용, 부족한 내용 꼭 지적 부탁드립니다!

4. Request Methods

4.1 Overview

Request 메소드 토큰은 Request 요청에서 가장 큰의미를 나타내며 클라이언트가 요청을 한 목적과 성공적인 결과로 클라이언트가 기대하는것을 나타낸다. (GET 요청을 했다면 리소스를 가져오는 목적이였을 것이며, 반환 값으로는 해당 리소스를 원했을 것이다) Request 메소드의 의미론은 Request에 어떠한 헤더 필드가 있을 때, 추가된 의미론과 메소드가 충돌되지 않는 경우 더 적합할 수 있다. 예를 들어 클라이언트는 조건부 요청 헤더 필드를 보내 대상 리소스의 현재 상태를 조건으로 요청된 작업을 수행 할 수 있다.

method = token

HTTP는 원래 분산 객체 시스템에 대한 인터페이스로 사용할 수 있도록 설계 되었다. 요청 메소드는 식별된 객체에 대해 정의된 메소드를 호출하는 것과 거의 동일한 방법으로 대상 리소스에 의미론을 적용하도록 구상 되었다. 메소드 토큰은 대소문자를 구분한다. 왜나하면 대소문자를 구분하는 객체 기반 시스템의 게이트웨이로 사용될 수 있기 때문이다.

분산된 객체와 달리, HTTP의 표준화된 요청 메소드는 리소스에 특정하지 않는다. 적합한 인터페이스는 네트워크 기반 시스템[REST]에서 더 나은 가시성과 재사용을 제공하기 때문이다. 표준화된 메소드는 어떠한 리소스에 적용될때 같은 의미론을 가진다. 각 리소스는 이러한 의미론이 구현되는지, 허용되는지는 자체적으로 결정한다. (개발자가 해당 메소드를 구현하냐 마냐에 대한 얘기인듯.)

다음 표에는 요약된 바와 같이 HTTP에서 일반적으로 사용되는 다수의 표준화된 메서드를 정의한다. 표준화된 메서드는 대문자 US-ASCII 문자로 정의된다.

모든 범용 서버는 GET 및 HEAD 메서드를 지원해야한다. 다른 메서드는 선택사항이다.

이 명세 범위를 벗어난 추가 메서드는 HTTP에서 사용할 수 있도록 표준화되었다. 이러한 모든 메서드는 IANA에 의해 유지 되는 “Hypertext TransferProtocol (HTTP) Method Registry” 내에 등록되어야 한다.

대상 리소스가 허용되는 메서드 집합은 Allow 헤더 필드에 나열할 수 있다. 그러나 허용된 메서드 집합은 동적으로 변할 수 있다. 서버에서 인식되지 않거나 구현되지 않은 요청 메서드가 수신되면 서버는 501(Not Implemented) 상태 코드로 응답해야 한다. 서버에서 구현은 되어 있지만 대상 리소스에 대해 사용 할 수 없는 메소드라면 서버는 405(Method Not Allowed) 상태 코드로 응답해야 한다.

4.2. Common Method Properties

4.2.1. Safe Methods

요청 메서드는 정의된 의미론이 읽기 전용인경우 ‘safe’로 간주한다. 예를 들어 리소스에 대해서 safe 한 method를 적용한 결과는 서버의 어떠한 상태변화에 대해서 요구하지도 기대하지도 않는다. 마찬가지로 safe method의 합리적인 사용은 서버에 어떠한 위협과 비정상적인 행위를 야기하지 않을것이다.

이러한 safe methods는 완전한 읽기 전용이 아니거나, 호출하는 동안 부작용을 일으키는 행동을 구현하는것을 막지 않는다. 중요한 것은 클라이언트가 추가 행동을 요구하지 않았고 이에 대한 책임을 물을 수 없기 때문에 안전하게 구현을 해야한다. 예를 들어 대부분 서버는 메서드 관계없이 모든 응답이 완료될 때 로그파일에 액세스 하기 위해 요청 정보를 추가하며, 로그 저장소가 가득 차서 서버가 다운될 수 있더라도 안전하다고 간주된다. 마찬가지로 웹에서 광고를 선택하여 시작된 safe 요청은 종종 광고 계정에 요금을 청구하는 부작용을 낳을 것이다.

이 명세에 의해 정의된 요청 메소드 중 GET, HEAD, OPTION, TRACE 메서드는 안전하다고 정의된다.

안전한 메서드와 안전하지 않은 메서드를 구분하는 목적은 자동 검색 프로세스(spider)와 캐시 성능 최적화(pre-fetching)가 문제를 일으키질 않도록 하기 위함이다. 또한 잠재적으로 신뢰할 수 없는 콘텐츠를 처리할 때 안전하지 않은 메서드의 자동 사용에 적절한 제약 조건을 적용할 수 있도록 한다.

사용자 에이전트는 사용자에게 잠재적 행동을 제시할 때 사용자가 요청하기 전에 안전하지 않은 메서드를 인지할 수 있도록 안전한 메서드와 안전하지 않은 메서드를 구분해야 한다.

유효한 요청 URI 내의 매개변수가 action 선택의 영향을 미치도록 리소스를 구성할 때, action이 요청 메소드의 의미와 일치하는지 확인하는 것은 리소스 소유자의 책임이다. 예를 들어 웹 기반 콘텐츠 편집 소프트웨어는 “page?do=delete”와 같은 쿼리 매개변수 내의 작업을 사용하는 것이 일반적이다. 이러한 리소스의 목적이 안전하지 않은 작업을 수행하는 것이라면, 리소스 소유자는 안전한 요청 메소드를 사용하여 액세스할 때 해당 작업을 비활성화하거나 허용하지 않아야 한다. 그렇게 하지 않으면 자동화된 프로세스가 링크 유지보수, pre-fetching (어플리케이션의 성능 향상을 위해서 구동에 필요한 데이터를 메모리에 먼저 올려 놓는것.), 검색 인덱스 작성 등을 위해 모든 URI 참조에 대해 GET을 수행할 떄 적절하지 못한 부작용을 초래할 수 있다.

4.2.2 Idempotent Methods

요청 메서드는 해당 메서드를 여러번 요청했을때와 한번 요청했을때의 결과가 동일 한 경우, “idempotent”으로 간주된다(멱등성) 이 명세에 의해 정의된 요청 메서드 중 PUT, DELETE, 및 safe method는 멱등하다.

안전함의 정의와 마찬가지로, 멱등의 속성은 사용자가 요청한 것에만 적용된다. 서버는 각 요청을 별도로 로깅하거나, 버전 기록을 유지하거나 또는 각각 멱등 요청에서 비-멱등한 결과를 구현하는것은 자유롭다.

멱등 메서드는 클라이언트가 서버의 응답을 읽기 전에 통신 장애가 발생하면 요청이 자동으로 반복될 수 있기 때문에 구별된다. 예를 들어 클라이언트가 PUT 요청을 보내고 응답이 수신되기 전에 기본 커넥션이 닫히면 클라이언트는 새로운 커넥션을 설정하고 멱등한 요청을 재시도할 수 있다. 응답은 다를수 있지만, 이전의 요청이 성공했더라도, 우리는 요청을 반복하는 것은 의도된 것과 같은 효과를 낸 다는것을 알고 있다.

4.2.3. Cacheable Methods

요청 메소드는 “cacheable”로 정의하여 향후 재사용에 대한 응답을 저장할 수 있다. 일반적으로 현재(아마 현재 상태와 의존하는 뜻인듯)와 권한 있는 응답에 의존하지 않는 safe 메서드는 캐시 가능으로 정의 된다. GET, HEAD 및 POST를 캐시 가능으로 정의하지만, 압도적으로 캐시구현은 GET와 HEAD만 지원한다. (POST는 safe method가 아니라고 했는데 뭐지?? 어떠한 상태 변화도 하지 않는 POST 요청은 괜찮다는건가?)

4.3. Method Definitions

4.3.1. GET

GET 메서드는 대상 리소스에 대해 현재 선택된 Representation의 전송을 요청한다. GET은 정보 검색의 주요 메커니즘이자 거의 모든 성능 최적화의 초점이다. 따라서 사람들이 HTTP를 통해 식별 가능한 정보를 검색하는 것을 일반적으로 GET 요청이라 말한다. 리소스 식별자를 원격 파일 시스템 경로, 그러한 파일의 내용을 복사한 것으로 생각한다. 실제로, 저런 방식으로 많은 리소스를 구현했다. 하지만 리소스 식별자를 표현하는 방법에는 한계가 없다. 리소스를 위한 HTTP 인터페이스는, 컨텐츠 객체의 트리, 다양한 데이터베이스 레코드에 대한 프로그램 뷰 또는 다른 정보 시스템으로의 게이트웨이처럼 구현될 가능성도 높다. URI 매핑 메커니즘이 파일 시스템에 연결되어 있는 경우에도 서버는 요청으로 파일을 입력으로 실행하고 파일을 직접 정송하지 않고 출력물을 Representation으로 전송하도록 구성할 수 있다. 그럼에도 서버는 각각의 리소스 식별자가 구현에 어떻게 대응하는지, GET에 대한 응답으로 대상 리소스의 현재 표현을 어떻게 선택하고 전송하는지를 알 필요가 있다.

클라이언트는 요청에서 Range 헤더필드를 전송하여 선택된 representation의 일부만 전송을 요청하는 GET의 의미를 range request로 변경할 수 있다.

GET 요청 메세지 내의 페이로드는 의미를 가지지 않는다. GET 요청에 페이로드 본체를 전송하면 일부 구현에서는 요청을 거부할 수 있다.

GET 요청에 대한 응답은 캐시가 가능하며, 캐시는 Cache-Control 헤더 필드에 달리 표시되지 않는 한 후속 GET 및 HEAD 요청을 충족하기 위해 캐시를 사용할 수 있다.

4.3.2. HEAD

HEAD 메서드는 GET과 동일하지만, 서버가 응답에서 메시지 본문을 전송하면 안된다. (응답에서 헤더까지만 옴). 페이로드 헤더 필드를 생략할 수 있다는 점을 제외하고, 서버는 HEAD 요청에 응답하여 GET 요청과 동일한 헤더필드를 전송해야 한다. 이 메서드는 representation 데이터를 전송하지 않고 선택된 표현에 대한 메타데이터를 얻는 데 사용할 수 있다 예를 들면 representation 데이터에 대해서 HTTP 링크로 해당 리소스가 유효한지, 접근 가능한지, 최근 수정이 되었는지 확인하는데 사용된다.

HEAD 요청 메시지 내의 페이로드는 의미를 가지지 않는다. HEAD 요청에 페이로드 본체를 전송하면 일부 구현에서는 요청을 거부할 수 있다.

HEAD 요청에 대한 응답은 캐시가 가능하며, 캐시는 Cache-Control 헤더 필드에 달리 표시 되지 않는 한 후속 HEAD 요청을 만족시키기 위해 캐시를 사용할 수 있다. HEAD 응답은 이전에 캐시된 GET 응답에도 영향을 미칠 수 있다.

4.3.3. POST

POST 메서드는 리소스 요청에 포함된 representation을 리소스 자체의 특정 의미에 따라 처리하도록 요청한다. 예를 들어, POST는 아래와 같은 기능에 사용된다.

• HTML 양식에 입력된 필드와 같은 데이터 블록을 데이터 처리 프로세스에 제공한다.
• 게시판, 뉴스 그룹, 메일 목록, 블로그등 유사한 그룹에 글을 포스팅할 수 있다.
• 서버에서 아직 식별되지 않은 리소스를 생성할 수 있다.
• 리소스의 기존 representation에 데이터를 추가 할 수 있다.

서버는 POST 요청 처리 결과에 따라 적절한 상태 코드를 선택하여 응답 결과의 의미를 표현해야하며, 대부분 응답으로 POST(206(Partial Content), 304(Not Modified), 416(Range Not Satisfiable)것들이 올 수 있다.

POST 요청을 성공적으로 처리한 결과로써 하나 이상의 리소스가 서버에 생성된 경우, 서버는 생성된 리소스의 식별자를 제공하는 Location 헤더 필드를 포함하는 201(Created)응답과 요청의 상태를 설명하는 representation을 전송해야 한다.

POST 요청에 대한 응답은 명시적으로 리소스가 변경되지 않았다는 정보를 포함하는 경우에만 캐시할 수 있다. 그러나 POST 캐싱은 잘 구현되지 않는다. 서버가 POST 요청후 결과를 GET으로 캐시할 수 있기를 원하는 경우, 서버는 결과를 포함하는 200(OK) 응답과 POST의 유효한 요청 URI와 동일한 값을 갖는 Content-Location 헤더 필드를 전송하여 나중에 GET으로 재사용 할 수 있는 방식으로 POST 결과를 캐시할 수 있다.

POST 처리 결과가 기존 리소스의 representation과 같을 경우, 서버는 Location 필드에 있는 기존 리소스 식별자와 함께 303(See Other) 응답을 전송하여 사용자 에이전트를 해당 리소스로 리다이렉트 할 수 있다. 이는 사용자 에이전트가 이미 캐시된 representation을 가지고 있지 않은 경우, 추가 요청의 비용으로 사용자 에이전트에 리소스 식별자를 제공하고, 공유 캐싱에 더 적합한 메서드를 통해 representation을 전송할 수 있는 이점이 있다. (이 말이 이해가 안된다면 303코드의 사용 예를 찾아보면 이해하기 쉬울 것이다.)

4.3.4. PUT

PUT 메서드는 대상 리소스의 상태를 생성하거나 요청 메시지 페이로드에 동봉된 representation에 정의된 상태로 대체할 것을 요청한다. 주어진 representation으로 PUT 요청을 성공했다면 동일한 대상 리소스에 대한 후속 GET이 200(OK) 응답으로 동등한 representation을 전송하게 된다는것을 암시할 수 있다. 대상 리소스가 다른 사용자 에이전트에 의해 병렬로 작용하거나, 후속 GET이 수신되기 전에 원서버에 의해 동적 처리될 수 있기 때문에 이러한 상태 변화를 관찰할 수 있다는 보장은 없다. 성공적인 응답은 사용자 에이전트의 의도가 원서버에 의해 처리되는 시점에 달성 되었음을 의미한다.

위에 대한 내용을 예를 들어보자. 한 리소스에 대해 여러 사용자 에이전트가 PUT 요청을 하는 예를 보자.

1. 1번 사용자 에이전트가 PUT 요청을 보낸다.
2. 2번 사용자가 1번 사용자와 동일한 시점에 PUT 요청을 보낸다.
3. 1번 사용자의 PUT 요청에 대한 성공 응답이 반환된다.
4. 2번 사용자의 PUT요청에 대한 성공 응답이 반환된다.
5. 1번 사용자가 GET 요청을 한다.
6. 1번 사용자의 GET 요청이 반환 되며 결과는 2번 사용자가 PUT 요청에 대한 결과값이 포함되어 반환된다.

이 처럼 후속 GET이 수신 되기전에 서버에 의해 동적 처리 되거나 병렬로 작용한다면 원하는 상태를 얻는다고 확신할 수 없다.

대상 리소스가 현재 representation을 가지고 있지 않고 PUT이 성공적으로 생성한다면. 서버는 201(Created) 응답을 전송하여 사용자 에이전트에게 알려야한다. 대상 리소스가 현재 representation을 가지고 있고 가지고 있는 representation이 수정될 representation(put 요청시 페이로드에 담기는)에 따라서 성공적으로 수정된다면 서버는 요청 성공 완료를 나타내기 위해 200 (OK) 또는 204(No Content) 응답을 보내야 한다.

서버는 PUT 요청으로 인식되지 않는 수신된 헤더 필드를 무시해야한다.(또한 헤더필드들을 리소스 상태의 일부로 저장하지 마라).

서버는 PUT representation이 PUT에 의해 변경될 수 없거나, 변경 되지 않을 대상 리소스에 대한 서버가 가지는 제약 조건과 일치하는지 확인해야한다. 이는 GET 응답에 대한 표현 메타데이터 값을 설정하기 위해 서버가 URI와 관련된 내부 구성 정보를 사용하는 경우에 특히 중요하다. PUT 표현이 대상 리소스와 일치하지 않을 경우, 서버는 representation을 변환하거나, 리소스 구성을 변경하여 일관성을 유지하거나, representation이 적합하지 않은 이유를 설명하기 위해 충분한 정보를 포함하는 적절한 오류 메시지로 반환해야한다. 409 (Conflict) 또는 415(Unsupported Media Type) 상태 코드가 제안되며, 후자는 Content-Type 값에 대한 제약 조건에 한정된다

예를 들어, 대상 리소스가 항상 “text/html”의 Content-Type을 가지도록 구성되고 PUT 표현이 “image/jpeg”의 Content-Type을 가지도록 구성된 경우, 서버는 다음 중 하나를 수행해야 한다.

1. 새로운 미디어 타입을 반영하도록 대상 리소스를 재구성한다.
2. PUT representation을 새 리소스 상태로 저장하기 전에 리소스의 representation과 일치하는 형식으로 변환한다.
3. 대상 리소스가 “text/html”로 제한됨을 나타내는 415(Unsupported Media Type) 응답으로 요청을 거부하며, 새 representation에 적합한 대상이 될 수 있는 다른 리소스에 대한 링크를 포함할 수 있다.

HTTP는 사용자 에이전트 요청의 의도와 서버 응답의 의미에 의해 표현될 수 있는것을 넘어 PUT 메서드가 서버의 상태에 어떻게 영향을 미치는지 정확히 정의하지 않는다. 어떤 의미에서도 HTTP를 통해 제공되는 인터페이스를 넘어 리소스가 무엇인지 정의하지 않는다. 그것은 리소스 상태가 “저장된” 방식이나, 리소스 상태의 변경으로 인해 그러한 저장소가 어떻게 변경될 수 있는지, 또한 서버가 리소스 상태를 representation으로 변환하는 방법을 정의하지 않는다. 일반적으로 리소스 인터페이스 뒤에 있는 모든 구현 세부사항은 서버에 의해 의도적으로 숨겨 진다. (그냥 개발자가 PUT 요청에 대한 의미를 부여하고 직접 위와 같은 내용을 구현해야한다는 내용 같음)

서버는 본문에 적용된 변환 없이 요청의 representation 데이터가 저장되고 validator filed가 새 representation을 반영하지 않으면 (리소스의 새 representation 데이터가 PUT 요청에서 받은 representation 데이터와 동일할때.) ETag 또는 Last-Modified field와 같은 validator header field를 성공적인 PUT 응답에 전송해서는 안 된다. 이 요구사항은 사용자 에이전트가 PUT의 결과로 메모리에 있는 표현 본문이 최신 상태로 유지되는 시기를 알 수 있또록 허용하며, 따라서 서버에서 다시 검색할 필요가 없으며, 응답에 수신된 새 검증자를 향후 조건부 요청에 사용하여 실수로 덮어 쓰지 않도록 할 수 있다. (이해가 안됨;)

POST 메서드와 PUT 메서드의 근본적인 차이는 동봉된 representation에 대한 다른 의도에 의해 강조된다. POST 요청의 대상 리소스는 리소스 자체의 의미에 따라 동봉된 representation을 처리하기 위한 것이며, PUT 요청의 동봉된 representation은 대상 리소스 상태를 대체하는 것으로 정의된다. 따라서 PUT의 의도는 멱등하며, 정확한 효과는 서버에 의해서만 알려져 있음에도 어떻게 변하는지 알 수 있다.

PUT 요청에 대한 적절한 해석은 사용자 에이전트가 원하는 대상 리소스를 알고 있다고 가정한다. 상태 변경 요청을 받은 후 클라이언트 대신 적절한 URI를 선택하는 서비스는, PUT이 아닌 POST 메서드를 사용해 실시해야 한다. 서버는 요청된 PUT 상태를 대상 리소스로 변경하지 않고, 리소스를 다른 URI로 이동한 경우와 같이 다른 리소스에 적용하려면, 서버가 적절한 3xx(Redirection) 응답을 보내야 한다. 사용자 에이전트는 요청을 리다이렉트 할지 여부에 대해 자체 결정을 내릴 수 있다.

대상 리소스에 적용되는 PUT 요청은 다른 리소스에 부작용을 일으킬 수 있다. 예를 들어, 신문 기사에서 각 특정 버전(한 시점에서 현재 버전 리소스와 동일한 상태를 공유하는 다른 리소스)을 식별하는 URI와 별도의 “현재 버전”을 식별하기 위한 URI가 있을 수 있다. 따라서 “현재 버전” URI의 PUT 요청이 성공하면 대상 리소스의 상태를 변경하는 것 외에 새 버전 리소스가 생성될 수 있으며 관련 리소스 간에 링크가 추가될 수 도 있다.

특정 대상 리소스에 PUT을 허용하는 서버는, PUT이 전체 representation으로서 잘못 표현된 부분 콘텐츠일 가능성이 있으므로 Content-Range 헤더필드를 포함하는 PUT 요청에 400(Bad Request) 응답을 보내야 한다. 부분 콘텐츠 업데이트는 큰 리소스의 일부와 겹치는 상태를 가진 별도의 식별된 리소스를 대상으로 하거나, 부분 업데이트에 대해 특별히 정의된 다른 메서드 (PATCH)를 사용하여 가능하다.

PUT 방법에 대한 응답은 캐시할 수 없습니다. 성공적인 PUT 요청이 유효 요청 URI에 대해 하나 이상의 응답이 저장된 캐시를 통과하면 저장된 응답은 무효화 된다.

4.3.5. DELETE

DELETE 메서드는 서버가 대상 리소스와 현재 기능간의 연결을 제거하도록 요청한다. 사실상, 이 메섣는 UNIX의 rm 명령과 유사하다. 이것은 이전에 연결된 정보가 삭제 될 것이라는 예상보다는 서버의 URI 매핑에 대한 삭제 작업을 나타낸다.

대상 리소스에 하나 이상의 현재 representation을 가지고 있는 경우, 대상 리소스가 서버의 의해 제거되거나 제거되지 않을 수 있으며, 리소스의 특성과 서버에 의한 구현에 따라 관련 저장소가 회수되거나 회수되지 않을 수 있다. 마찬가지로, 리소스의 다른 구현(데이터베이스나 게이트웨이 커넥션) 측면도 DELETE의 결과로 비활성화하거나 아카이브되어야 할 수 있다. 일반적으로 서버는 삭제를 수행하기 위해 규정된 메커니즘을 가진 리소스에 대해서만 DELETE를 허용한다고 가정한다.

비교적 적은 리소스로 DELETE 메서드를 사용할 수 있다. 이 메서드는 주로 사용자가 삭제효과에 대한 방향을 가지고 있는 원격 저작 환경에 사용된다. 예를 들어 PUT 요청을 사용하여 이전에 생성했거나 POST 요청에 대한 201(Created) 응답 후 Location 헤더 필드를 통해 식별된 리소스는 해당 DELETE 요청을 허용하여 해당 작업을 실행 취소할 수 있다.

DELETE 메서드가 성공적으로 적용된 경우, DELETE가 성공할 가능성이 높지만 아직 수행 되지 않은 경우 원본 서버는 202 (Accepted) 상태 코드를 반환하거나, DELETE가 수행 되어 추가 정보가 제공되지 않은 경우 204(No Content) 상태 코드를 전송하거나, DELETE가 정상적으로 수행 된 경우 200(OK) 상태 코드를 전송해야 한다. 그리고 body에는 상태를 설명하는 representation을 포함하는 응답 메시지를 전송해야 한다.

DELETE 요청 메시지 내의 페이로드에는 정의된 의미가 없으며, DELETE 요청에 따라 페이로드 본문을 전송하면 일부 기존 구현이 요청을 거부할 수 있다.

DELETE 메서드에 대한 응답은 캐시할 수 없다. 요청 URI에 대해 하나 이상의 저장된 응답이 있는 캐시를 통해 DELETE 요청이 전달되는 경우 저장된 응답은 무효화 된다.

4.3.6. CONNECT

CONNECT 메서드는 수신자에게 요청 대상으로 식별된 대상 서버에 터널(양방향 연결)을 설정하도록 요청하고, 그 후, 터널이 닫힐 때까지 패킷의 블라인드 포워딩으로 동작을 제한한다. 터널은 일반적으로 하나 이상의 프록시를 통해 end-to-end 가상 커넥션을 생성하는 데 사용되며, 이후 TSL(Transport Layer Security)를 사용하여 보안을 유지할 수 있다.

CONNECT는 프록시에 대한 요청에서만 사용할 수 있다. 자신에게 CONNECT 요청을 수신한 서버는 2xx (Successful) 상태 코드로 응답하여 커넥션이 설정되었음을 표시한다. 그러나 대부분의 서버는 CONNECT를 구현하지 않는다.

CONNECT 요청을 전송하는 클라이언트는 요청 대상의 권한 양식을 전송해야 한다. 즉, 요청 대상은 콜론으로 구분된 터널 대상의 호스트 이름과 포트번호로만 구성된다.

CONNECT server.example.com:80 HTTP/1.1 
Host: server.example.com:80

수신자 프록시는 request-target에 직접 연결하거나 다른 프록시를 사용하도록 구성된 경우 CONNECT 요청을 다음 인바운드 프록시로 전달하여 터널을 설정할 수 있다. 2xx(Successful) 응답은 발신자(및 모든 인바운드 프록시)가 성공적인 응답의 헤더 부문을 끝내는 빈 줄 바로 뒤에 터널 모드로 전환됨을 나타낸다. 빈 줄 이후에 수신된 데이터는 request-target으로 식별된 서버로부터 수신된다. 성공적인 응답 이외의 응답은 터널이 아직 형성되지 않았으며 커넥션은 HTTP에 의해 통제된 상태로 남아 있음을 나타낸다.

터널 중개자는 어느 한쪽이 커넥션을 닫았음을 감지할 때 터널이 닫힌다: 중개자는 닫힌 쪽에서 온 해결되지 않은 데이터를 다른 쪽으로 보내고, 양쪽 커넥션을 모두 닫은 다음, 전달되지 않은 나머지 데이터는 모두 폐기해야 한다. 프록시 인증을 사용하여 터널 생성 권한을 설정할 수 있다.

CONNECT server.example.com:80 HTTP/1.1 
Host: server.example.com:80 
Proxy-Authorization: basic aGVsbG86d29ybGQ=

임의 서버에 대한 터널을 설정하는 경우, 특히 대상이 웹 트래픽을 대상으로 하지 않는 잘 알려져 있거나 예약된 TCP 포트인 경우 상당한 위험이 있다. 예를 들어 “example.com:25”의 request-target에 대한 CONNECT는 프록시가 SMTP 트래픽을 위해 예약된 포트에 연결하도록 제안할 수 있으며, 허용된 경우 프록시를 속여 스팸 전자 메일을 전달할 수 있다. CONNECT를 지원하는 프록시는 제한된 알려진 포트 집합 또는 안전한 요청 대상의 구성 가능한 화이트리스트로 사용을 제한해야한다.

서버는 2xx(Successful) 응답으로 CONNECT에 Transfer-Encoding 또는 Content-Length 헤더 필드를 전송해서는 안 된다. 클라이언트는 CONNECT에 대한 성공적인 응답으로 수신된 Content-Length 또는 Transfer-Encoding 헤더 필드를 무시해야 한다.

CONNECT 요청 메시지 내의 페이로드는 의미론을 정의하지 않는다; CONNECT 요청에 페이로드 본체를 전송하면 일부 기존 구현이 요청을 거부할 수 있다.

CONNECT 메서드에 대한 응답은 캐시할 수 없다.

CONNECT에 대해선 더 학습이 필요할것같다

4.3.7. OPTIONS

OPTION 메서드는 대상 리소스에 사용할 수 있는 통신 옵션에 대한 정보를 오리진 서버 또는 중개자에게 요청한다. 이 메서드를 사용하면 클라이언트가 리소스 작업을 암시하지 않고 리소스 또는 서버의 기능과 관련된 옵션 또는 요구 사항을 결정할 수 있다.

” * “를 요청 대상으로 하는 OPTIONS 요청은 특정 리소스가 아닌 일반적으로 서버에 적용된다. 서버의 통신 옵션은 일반적으로 리소스에 따라 다르기 때문에, “ * “ 요청은 “ping” 또는 “no-op” 유형의 메소드만 유효하며, 클라이언트가 서버의 기능을 테스트할 수 있도록 허용하는것 외에는 아무것도 하지 않는다. 예를 들어, HTTP/1.1 적합성(적합하지 않은지)에 대한 프록시를 테스트하는 데 사용할 수 있다.

요청 대상이 별표가 아닌 경우 OPTION 요청은 대상 리소스와 통신할 때 사용할 수 있는 옵션에 적용된다.

OPTION에 대한 성공적인 응답을 생성하는 서버는 이 명세에 정의되지 않은 잠재적 확장을 포함하여 서버가 구현하고 대상 리소스(e.g, Allow)에 적용할 수 있는 선택적 기능을 나타낼 수 있는 헤더 필드를 전송해야한다.

사진처럼 URL에 OPTIONS 헤더를 보내면 allow 헤더를 통해 어떤 메서드를 사용할 수 있는지 나타난다.

응답 페이로드(있는 경우)는 기계나 사람이 읽을 수 있는 representation에서 통신 옵션을 설명할 수도 있다. 이러한 representation에 대한 표준 형식은 이 명세에 의해 정의되지 않지만 HTTP에 대한 향후 확장에 의해 정의될 수 있다. 응답에서 페이로드 본문을 전송하지 않으려면 서버는 “0”의 값을 가진 Content-Length 필드를 생성해야 한다.

클라이언트 OPTIONS 요청의 Max-Forwards 헤더 필드를 요청 체인의 특정 수신자를 대상으로 보낼 수 있다. 요청이 Max-Forwards 필드와 수신되지 않은 경우 프록시는 요청을 전달하는 동안 MaxForwards 헤더 필드를 생성해서는 안 된다.
MAX-Forwards에 대해선 이 분의 블로그에 잘 설명 되어 있으므로 참고하길 바란다.

페이로드 본문을 포함하는 OPTIONS 요청을 생성하는 클라이언트는 representation의 미디어 타입 유형을 설명하는 유효한 Content-Type 헤더 필드를 전송해야 한다. 이 명세는 이러한 페이로드에 대한 사용을 정의하지 않지만, 이 후 HTTP에 대한 확장은 OPTIONS 본문을 사용하여 대상 리소스에 대한 보다 상세한 쿼리를 할 수 있다.

OPTIONS 메서드에 대한 응답은 캐시 할 수 없다.

CORS에서 OPTIONS 메소드를 통해 프리플라이트 요청, 즉 사전 요청을 보내 서버가 해당 parameters를 포함한 요청을 보내도 되는지에 대한 응답을 줄 수 있게 한다.

Access-Control-Request-Method 헤더는 프리플라이트 요청의 일부분으로 서버에게 실제 요청이 전달 될 때 POST 요청 메소드로 전달될 것 임을 명시한다.

Access-Control-Request-Headers 헤더는 서버에게 실제 요청이 전달될 때 X-PINGOTHER 와 Content-Type custom headers 와 함께 전달될 것 임을 명시한다. 서버는 그럼 이러한 요구사항들에 맞춰 요청을 수락할 것인지 정할 수 있다.

OPTIONS /resources/post-here/ HTTP/1.1
Host: bar.other
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en;q=0.5
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Connection: keep-alive
Origin: http://foo.example
Access-Control-Request-Method: POST
Access-Control-Request-Headers: X-PINGOTHER, Content-Type

아래 응답을 보면 서버는 Access-Control-Allow-Methods로 응답하고, POST, GET 그리고 OPTIONS 메소드를 통해서 해당하는 자원을 query할 수 있음을 알려준다. 이 헤더는 Allow 응답 헤더와 비슷하지만 반드시 CORS에 한해서만 사용된다.

HTTP/1.1 200 OK
Date: Mon, 01 Dec 2008 01:15:39 GMT
Server: Apache/2.0.61 (Unix)
Access-Control-Allow-Origin: http://foo.example
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGOTHER, Content-Type
Access-Control-Max-Age: 86400
Vary: Accept-Encoding, Origin
Content-Encoding: gzip
Content-Length: 0
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/plain

4.3.8. TRACE

TRACE 메서드는 요청 메시지의 원격 어플리케이션-레벨 루프백을 요청한다. 요청의 최종 수신자는 아래에 설명된 일부 필드를 제외하고 수신된 메시지를 “message/http”의 내용 유형으로 200(OK) 응답의 메시지 본문으로 클라이언트에 다시 반영해야 한다. 최종 수신자는 요청에서 Max_Forwards의 0값을 수신한 첫 번째 서버 또는 원 서버 이다.

클라이언트는 TRACE 요청에서 응답에 의해 공개될 수 있는 중요한 데이터를 포함하여 헤더필드를 생성해서는 안 된다. 예를 들어 사용자가 에이전트가 저장된 사용자 자격 증명 또는 쿠기를 TRACE 요청으로 전송하는 것은 어리석은 일이다. 요청의 최종 수신자는 응답 본문을 생성할 때 중요한 데이터를 포함할 가능성이 있는 요청 헤더 필드를 제외해야한다.

TRACE는 클라이언트가 요청 체인의 다른 쪽 끝에서 수신되는 것을 확인하고 테스트 또는 진단 정보를 위해 해당 데이터를 사용할 수 있도록 한다. via 헤더 필드의 값은 요청 체인의 추적 역할을 하므로 특히 중요하다. Max-Forwards 헤더 필드를 사용하면 클라이언트가 요청 체인의 길이를 제한할 수 있으며, 이는 무한 루프에서 메시지 전달 프록시 체인을 테스트하는데 유용하다.

클라이언트는 TRACE 요청으로 메시지 본문을 보내서는 안된다.

TRACE 메서드에 대한 응답은 캐시할 수 없다.