5. Message Routing

HTTP 요청 메시지 라우팅은 대상 리소스, 클라이언트의 프락시 구성 및 인바운드 커넥션의 설정 또는 재사용을 기준으로 각 클라이언트에 의해 결정된다.

5.1 Identifying a Target Resource

대부분의 HTTP 클라이언트는 범용 웹 브라우저와 동일한 리소스 식별 메커니즘과 구성 기술에 의존한다.

5.2 Connecting Inbound

1.대상 URI가 결정되면 클라이언트는 바람직한 의미론을 달성하기 위해 네트워크 요청이 필요한지 여부를 결정해야 하며, 그렇다면 요청이 필요한 경우 어디에 요청되는 위치를 결정해야 한다.

2. 클라이언트에 캐시 [RFC7234] 가 있고 요청이 이에 의해 충족될 수 있는 경우, 일반적으로 요청은 먼저 해당 캐시로 전달된다.

3. 요청이 캐시에 의해 충족되지 않으면 일반 클라이언트는 해당 구성을 확인하여 요청을 충족하기 위해 프록시 사용할지 여부를 결정한다. 프록시 구성은 구현에 따라 다르지만 URI 접두사 일치, 선택적 권한 일치 또는 둘 다에 기반하는 경우가 많으며, 프락시 자체는 대개 "http" 또는 "https" URI로 식별된다. 프록시 적용 가능한 경우 클라이언트는 해당 프록시에 대한 커넥션을 설립(또는 재사용) 하여 인바운드를 연결한다.

4. 프록시가 적용되지 않는 경우, 일반적인 클라이언트는 대상 URI 의 scheme과 관련된 핸들러 루틴을 호출하여 대상 리소스에 대한 권한에 직접 연결한다.

5.3 Request Target

한번 인바운드 커넥션을 얻으면, 클라이언트는 대상 URI에서 파생된 request-target과 함께 HTTP 요청 메시지(Section 3)를 보낸다. 요청하는 방법과 프록시에 대한 요청인지 여부에 따라 request-target 형식은 네 가지로 구분된다.

request-target = origin-form / absolute-form / authority-form / asterisk-form

5.3.1 origin-form

대부분의 request-target의 공통적 양식은 origin-form이다.

origin-form = absolute-path [ "?" query ]

• CONNECT 또는 서버 전체 OPTIONS 요청 외에 원서버에 직접 요청할 때(아래에 자세히 설명 된 대로) 클라이언트는 대상 URI의 절대 경로 및 쿼리 구성 요소만 request-target으로 보내야 한다.(MUST)

• 대상 URI의 경로 구성 요소가 비어 있으면 클라이언트가 request-target의 origin-form 내에 경로로 “/" 를 반드시 보내야 한다.(MUST)

예를 들어, 클라이언트는 http://www.example.org/where?q=now 같은 식별된 리소스의 표시로 검색하는 것을 바랄 것이다.

원서버로부터 직접 포트 80에 대한 TCP 커넥션을 열고(또는 재사용하고) 호스트 "www.example.org"과 다음줄을 보냈을 것이다.

GET /where?q=now HTTP/1.1 Host: www.example.org

5.3.2 absolute-form

프록시에 요청을 할 때, CONNECT 또는 서버 측 OPTIONS 요청을 제외하고 (아래에 자세히 설명된 대로), 클라이언트는 absolute-form을 request-target으로 대상 URI를 보내야 한다.

GET http://www.example.org/pub/WWW/TheProject.html HTTP/1.1

• 일부 미래의 HTTP 버전에서 모든 요청을 위한 absolute-form으로 변환하려면, HTTP/1.1 클라이언트가 프록시에만 요청으로 absolute-form을 전송하더라도, 서버는 요청에서 absolute-form를 수용해야 한다.(MUST)

5.3.3 authority-form

하나 또는 그 이상의 프록시들을 통해 터널과 설립하기 위해 CONNECT 요청을 할 때, 클라이언트는 반드시 대상 URI의 권한 구성요소만 request-target으로 보내야 한다. (MUST)(어떤 userinfo나 “@“ 기호를 제외하고)

CONNECT www.example.com:80 HTTP/1.1

5.3.4 asterisk-form

request-target의 asterisk-form은 서버 전체 OPTIONS 요청에서만 사용된다.

• 클라이언트가 서버 전체에 대해 OPTIONS 요청을 하고자 할 때, 서버의 특정한 명명된 리소스와는 반대로, 클라이언트는 반드시 “*” (%x2A)만 request-target으로 보내야 한다.(MUST)

OPTIONS * HTTP/1.1

• 프록시가 URI에 빈 경로가 있고 쿼리 구성 요소가 없는 request-target의 absolute-form과 OPTIONS 요청을 수신하는 경우, 요청 체인의 마지막 프록시가 요청을 지정된 원서버로 전달 할 때 "*"의 request-target을 반드시 보내야 한다.(MUST)

예를들어, 요청에서

OPTIONS http://www.example.org:8001 HTTP/1.1

은 다음과같이 host “www.example.org"의 8001 포트에 연결된 후 마지막 프록시에 의해서 전송됐을 것이다.

OPTIONS * HTTP/1.1 Host: www.example.org:8001

5.4 Host

요청의 “Host” 헤더 필드는 대상 URI로 부터 호스트 및 포트 정보를 제공하므로 원서버가 단일 IP주소에서 다중 호스트 이름에 대한 요청을 처리하는 동안 리소스를 구분할 수 있다.

Host = uri-host [ ":" port ] ; Section 2.7.1

• 클라이언트는 모든 HTTP/1.1 요청 메시지에서 Host 헤더 필드를 반드시 보내야 한다.(MUST)

• 대상 URI에 권한 구성 요소가 포함된 경우, 어떤 userinfo나 “@“ 기호를 제외하고, 클라이언트는 해당 권한 구성 요소와 호스트에 대한 field-value를 반드시 보내야 한다. (MUST)

• 대상 URI 에 대한 권한 구성 요소가 없거나 정의되지 않은 경우 클라이언트는 빈 field-value가 포함된 Host 헤더 필드를 반드시 보내야 한다.(MUST)

• Host의 field-value는 요청을 처리하는 데 중요한 정보이므로 사용자 에이전트는 request-line 다음에 첫 번째 헤더 필드로 Host를 생성해야 한다.(SHOULD)

예를 들어, 원서버에 대한 <http://www.example.org/pub/WWW/>의 GET 요청은 다음과 같이 시작된다.

GET /pub/WWW/ HTTP/1.1 Host: www.example.org

• request-target이 absoluted-form인 경우라도 클라이언트는 HTTP/1.1 요청에서 Host 헤 더 필드를 반드시 전송해야 한다.(MUST)

• 프록시가 request-target의 absolute-form을 가진 요청을 수신하는 경우, 프록시는 수신된 Host 헤더 필드(있는 경우)를 무시하고 request-target의 호스트 정보로 대체해야 한다. (MUST)

• 서버는 Host 헤더 필드가 없는 HTTP/1.1 요청 메시지와 Host 헤더 필드의 유효하지 않은 field-value 또는 두 개 이상의 Host 헤더 필드를 포함하는 요청 메시지에 400 (Bad Request) 상태 코드로 반드시 응답해야 한다.(MUST)

5.5 Effective Request URI

request-target이 종종 사용자 에이전트의 대상 URI의 일부만 포함한 이래로, 서버는 요청을 적절하게 처리하기 위해 원하는 대상을 “effcetive request URI”로 재구성한다. 재구성에는 서버의 로컬 구성과 request-target에 있는 통신 정보, Host 헤더 필드 및 커넥션 컨텍스트에 서 전달되는 정보를 모두 포함한다.

5.6 Associating a Response to Request

• 커넥션에 대해 두개 이상의 결정되지 못한 요청이 있는 클라이언트는 보낸 순서대로 미결정 요청 목록을 반드시 유지해야 하며(MUST)

• 해당 커넥션에 대해 수신된 각 응답 메시지를 아직 최종 (non-1xx) 응답을 받지 않은 가장 우선순위가 높은 요청과 반드시 연결해야 한다.(MUST)

5.7 Message Forwarding

• 터널 역할을 하지 않는 중개자는 Section 6.1에 지정된 Connection 헤더 필드를 반드시 구현해야 하며, 들어오는 커넥션을 위해 전달되는 필드는 반드시 제외해야 한다.(MUST)

• 메시지가 무한 요청 루프로부터 보호되지 않는 한, 중개자는 메시지를 자기 자신에게 전달해서는 안 된다.(MUST NOT)

5.7.1 Via

“Via” 헤더 필드는 이메일의 “Received" 헤더 필드와 유사하게 사용자 에이전트와 서버(요청 시)또는 원서버와 클라이언트(응답 시)사이에 중개자 프로토콜과 수신자가 있음을 나타낸다.([RFC5322]의 Section 3.6.7).

• 프록시는 전달되는 각 메시지에서 아래 설명된 대로 적절한 Via 헤더 필드를 보내야 한다. (MUST)

• HTTP-to-HTTP 게이트 웨이는 각 인바운드 요청 메시지에서 적절한 Via 헤더 필드를 보내야 하며(MUST)

• 전달된 응답 메시지로 Via 헤더 필드를 보낼 수 있다.(MAY)

• 발신자는 received-protocol 값이 다른 항목을 결합해 서는 안 된다.(MUST) (e.g,. 1.0과 1.1을 결합하면 안 된다)

5.7.2 Transformations

일부 중개자는 메시지와 페이 로드를 변환하기 위한 기능을 포함한다. 예를 들어 프록시는 캐시 공간을 절약하거나 느린 링크의 트래픽 양을 줄이기 위해 이미지 형식 간에 변환할 수 있다.

의미론적으로 의미 있는 방식으로 메시지를 수정하도록 설계되거나 구성된 HTTP-to-HTTP 프락시를 “transforming proxy"라고 한다.

• request- target에 fully-qualified 도메인 이름이 포함된 경우 프락시는 호스트 이름을 변경해서는 안 된다.(MUST NOT)

• 프록시는 수신된 request-target을 다음 인바운드 서버로 전달할 때 빈 경로를 “/"또는 “*" 로 바꾸기 위해 위에서 설명한 경우를 제외하고 수신된 request-target의 “absolute-path” 및 “query" 부분을 수정해서는 안된다.(MUST NOT)

• 프락시는 no-trasnform cache-control 지시어를 포함한 메시지의 페이 로드([RFC7231]의 Section 3.3)를 변환해서는 안된다.(MUST NOT) ([RFC7234]의 Section 5.2).

• 페이 로드를 변환하는 프락시는 214 warn-code (“Transformation Applied”)가 아직 메시지에 없는 경우 Warning 헤더 필드에 추가해야 한다.(MUST)

• 프락시는 필드의 정의가 이러한 수정을 특별히 허용하거나 수정이 개인 정보 또는 보안을 위해 필요한 것으로 간주되지 않는 한 통신 체인의 엔드 포인트, 리소스 상태 또는 선택된 표현(페이 로드 제외)에 대한 정보를 제공하는 헤더 필드를 수정하면 안 된다.(SHOULD NOT)