힌트를 나타내기 위한 HTTP 상태 코드

초록

이 메모는 클라이언트가 최종 응답을 처리하기 위한 준비를 하는 데 도움이 되는 힌트를 전달하는 데 사용할 수 있는 정보성 HTTP 상태 코드를 소개한다.

이 메모의 상태

이 문서는 인터넷 표준 트랙 명세가 아니며, 검토, 실험적 구현 및 평가를 위해 발행되었다.

이 문서는 인터넷 커뮤니티를 위한 실험적 프로토콜을 정의한다. 이 문서는 인터넷 공학 태스크 포스(IETF)의 산출물로서 IETF 커뮤니티의 합의를 반영한다. 공개 검토를 거쳤으며 인터넷 공학 운영 그룹(IESG)에 의해 발행이 승인되었다. IESG에서 승인된 모든 문서가 인터넷 표준의 후보가 되는 것은 아니다; 자세한 내용은 RFC 7841의 섹션 2를 참조하라.

이 문서의 현재 상태, 정정표(errata) 및 피드백 제공 방법에 대한 정보는 https://www.rfc-editor.org/info/rfc8297에서 확인할 수 있다.

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. 소개
- 1.1. 표기 규약
2. HTTP 상태 코드 103: 조기 힌트
3. 보안 고려사항
4. IANA 고려사항
5. 참조
- 5.1. 규범적 참조
- 5.2. 정보 참조
Appendix A. 감사의 글
저자 주소

1. 소개

웹 브라우저가 HTML을 렌더링하는 등 사용 전에 미리 가져와야 하는 외부 리소스에 대한 링크를 HTTP 응답이 포함하는 것은 흔한 일이다. 이러한 링크를 가능한 한 빨리 클라이언트에게 제공하면 인지된 지연을 최소화하는 데 도움이 된다.

"preload" [Preload] 링크 관계는 HTTP 응답의 Link 헤더 필드에서 이러한 링크를 전달하는 데 사용할 수 있다. 그러나 원본 서버가 요청을 받은 직후 최종 응답의 헤더 블록을 즉시 생성할 수 없는 경우도 있다. 예를 들어, 원본 서버가 원격지에서 동작하는 상위(upstream) HTTP 서버에 요청을 위임하거나 상태 코드가 데이터베이스 쿼리 결과에 따라 달라질 수 있다.

여기서의 딜레마는 원본 서버가 요청을 받는 즉시 일부 헤더 필드를 전송하는 것이 바람직하지만, 최종 HTTP 응답의 상태 코드와 전체 헤더 필드가 결정될 때까지 그렇게 할 수 없다는 점이다.

HTTP/2 [RFC7540]의 서버 푸시는 서버가 권한을 가진 리소스에 대해서는 전달을 가속할 수 있다. 서버 푸시의 또 다른 한계는 클라이언트에 해당 응답이 캐시되어 있든 아니든 관계없이 응답이 전송된다는 점이다. 최악의 경우 서버 푸시보다 한 번의 왕복이 더 들지만, 적시에 Link 헤더 필드를 전달하는 것이 더 유연하며 대역폭을 덜 소비할 수도 있다.

이 메모는 최종 응답에 포함될 가능성이 있는 헤더 필드를 포함하는 정보성 응답([RFC7231], 섹션 6.2)을 전송하기 위한 상태 코드를 정의한다. 서버는 일부 헤더 필드를 포함한 정보성 응답을 전송하여 클라이언트가 최종 응답을 처리하기 위한 준비를 시작하도록 도울 수 있으며, 그 후에 시간이 오래 걸리는 작업을 수행하여 최종 응답을 생성할 수 있다. 정보성 응답은 또한 원본 서버가 캐시 중개자에서 HTTP/2 서버 푸시를 트리거하도록 하는 데 사용할 수 있다.

1.1. 표기 규약

이 문서에서 핵심 단어인 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 BCP 14 [RFC2119] [RFC8174] 에 설명된 대로, 여기처럼 모두 대문자로 나타날 때에만 해석되어야 한다.

2. HTTP 상태 코드 103: 조기 힌트

정보성 상태 코드인 103 (Early Hints)은 서버가 정보성 응답에 포함된 헤더 필드를 포함하는 최종 응답을 보낼 가능성이 있음을 클라이언트에 알린다.

일반적으로 서버는 103 (Early Hints) 응답에 전송된 헤더 필드를 최종 응답에도 포함한다. 다만, 최종 응답이 전송되기 전에 서버가 103 응답의 헤더 필드가 올바르지 않다는 것을 알게 되는 경우처럼 이것이 바람직하지 않은 경우가 있을 수 있다.

클라이언트는 최종 응답을 기다리는 동안 103 (Early Hints) 응답에 포함된 헤더 필드를 추측적으로 평가할 수 있다. 예를 들어, 클라이언트는 Link 헤더 필드 값에서 rel 유형 "preload"를 인식하고 대상 리소스의 가져오기를 시작할 수 있다. 그러나 이러한 헤더 필드는 클라이언트에 대한 힌트일 뿐이며 최종 응답의 헤더 필드를 대체하지 않는다.

성능 최적화와는 별개로, 103 (Early Hints) 응답의 헤더 필드에 대한 그러한 평가는 최종 응답의 처리 방식에 영향을 주어서는 안 된다. 클라이언트는 103 (Early Hints) 응답의 헤더 필드를 정보성 응답 자체에 적용되는 것처럼 해석해서는 안 된다(예: 103 응답에 대한 메타데이터로서 해석하지 말 것).

서버는 최종 응답에서 찾을 것으로 예상되는 일부 헤더 필드만을 나타내기 위해 103 (Early Hints) 응답을 사용할 수 있다. 클라이언트는 103 응답에 헤더 필드가 존재하지 않는 것을 그 헤더 필드가 최종 응답의 일부일 가능성이 낮다는 추측으로 해석해서는 안 된다.

다음 예시는 103 (Early Hints) 응답이 관련된 전형적인 메시지 교환을 설명한다.

클라이언트 요청:

  GET / HTTP/1.1
  Host: example.com

서버 응답:

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  <!doctype html>
  [... rest of the response body is omitted from the example ...]

모든 정보성 응답의 경우와 마찬가지로, 서버는 최종 응답을 보내기 전에 하나 이상의 103 (Early Hints) 응답을 발행할 수 있다. 예를 들어, 캐싱 중개자가 오래된(stale) 캐시 응답의 헤더 필드를 기반으로 103 응답을 생성한 다음, 재검증 요청에 대해 원본 서버가 보낸 103 응답과 최종 응답을 전달할 때 이런 일이 발생할 수 있다.

서버는 처리 도중 새로운 정보가 이용 가능해짐에 따라 추가 헤더 필드를 포함한 다수의 103 (Early Hints) 응답을 발행할 수 있다. 이미 발행된 필드를 반복할 필요는 없지만, 반복하지 않아도 된다. 클라이언트는 최종 응답에 포함될 것으로 예상되는 헤더 필드 목록을 예상할 때 여러 103 응답에서 수신된 헤더 필드들의 조합을 고려할 수 있다.

다음 예시는 서버가 발행할 수 있는 일련의 응답을 보여준다. 예제에서 서버는 두 개의 103 (Early Hints) 응답을 사용하여 최종 응답에 세 개의 Link 헤더 필드가 포함될 가능성이 있음을 클라이언트에게 알린다. 세 개의 예상 헤더 필드 중 두 개는 최종 응답에서 발견되고, 다른 하나는 다른 값의 Link 헤더 필드로 대체된다.

  HTTP/1.1 103 Early Hints
  Link: </main.css>; rel=preload; as=style

  HTTP/1.1 103 Early Hints
  Link: </style.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  HTTP/1.1 200 OK
  Date: Fri, 26 May 2017 10:02:11 GMT
  Content-Length: 1234
  Content-Type: text/html; charset=utf-8
  Link: </main.css>; rel=preload; as=style
  Link: </newstyle.css>; rel=preload; as=style
  Link: </script.js>; rel=preload; as=script

  <!doctype html>
  [... rest of the response body is omitted from the example ...]

3. 보안 고려사항

일부 클라이언트는 정보성 응답이 Expect 헤더 필드를 포함하지 않은 요청에 대한 응답으로 거의 사용되지 않기 때문에 103 (Early Hints) 응답을 처리하는 데 문제가 있을 수 있다([RFC7231], 섹션 5.1.1).

특히, 정보성 응답을 최종 응답으로 잘못 처리하는 HTTP/1.1 클라이언트는 동일한 연결에서 이어지는 후속 요청들에 대한 모든 응답을 최종 응답의 일부로 간주할 가능성이 있다. 이러한 동작은 클라이언트가 서로 다른 출처로의 요청들을 단일 지속 연결로 다중화하는 경우 교차 출처 정보 노출 취약점을 초래할 수 있다.

따라서 서버는 클라이언트가 정보성 응답을 올바르게 처리하는 것으로 알려져 있지 않는 한 HTTP/1.1 상에서 103 (Early Hints) 응답 전송을 자제할 수 있다.

HTTP/2 클라이언트는 응답 헤더 필드 처리가 응답 본문의 종료를 결정하는 방식에 영향을 주지 않기 때문에 잘못된 프레이밍에 의한 문제를 겪을 가능성이 적다.