HTTP로 프로토콜 구축

이 문서에서 핵심 단어 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 및 "OPTIONAL"은 모두 대문자로 표시된 경우에 한해 BCP 14 [RFC2119] 및 [RFC8174]에서 설명한 바와 같이 해석되어야 합니다.

애플리케이션은 위에서 정의한 기준을 충족하지 않더라도 HTTP에 의존할 수 있습니다. 예를 들어, 애플리케이션은 메시지 형식의 일부를 다시 명세하는 것을 피하려고 하지만 프로토콜 동작의 다른 측면을 변경하거나 애플리케이션별 메서드를 사용하려고 할 수 있습니다.

이렇게 하면 프로토콜 동작을 수정할 자유가 커지지만, 대부분의 HTTP 구현은 이러한 변경에 쉽게 적응하지 못하므로 섹션 3에 요약된 이점의 적어도 일부가 상실됩니다. 또한 마음의 점유 효과(mindshare)의 이점도 잃게 됩니다.

이러한 명세는 MUST NOT HTTP의 URI 스킴, 전송 포트, ALPN 프로토콜 ID 또는 IANA 레지스트리를 사용해서는 안 되며; 대신 자체적인 것을 설정하는 것이 권장됩니다.

HTTP의 많은 가치는 일반 의미론에 있습니다 — 즉, HTTP에 의해 정의된 프로토콜 요소는 모든 리소스에 적용될 수 있으며 특정 맥락에 국한되지 않습니다. 애플리케이션 특정 의미론은 상태 코드나 메서드(상태 코드와 메서드는 애플리케이션 상태와 관련된 일반적 의미론을 갖긴 하지만)를 재정의하기보다는 메시지 콘텐츠와 헤더 필드에 표현되는 것이 가장 좋습니다.

일반 의미론과 애플리케이션 특정 의미론의 이러한 분리는 공통 소프트웨어(예: HTTP 서버, 중개자, 클라이언트 구현 및 캐시)가 애플리케이션을 이해할 필요 없이 HTTP 메시지를 처리할 수 있게 합니다. 또한 사람들은 특정 애플리케이션에 대한 전문 지식 없이도 HTTP 의미론에 대한 지식을 활용할 수 있습니다.

따라서 HTTP를 사용하는 애플리케이션은 메서드, 상태 코드 또는 기존 헤더 필드와 같은 일반 프로토콜 요소의 의미론을 재정의, 세분화 또는 오버레이해서는 안 됩니다. 대신, 그들은 명세를 해당 애플리케이션에 특정한 프로토콜 요소 — 즉, 자신의 HTTP 리소스 — 에 초점을 맞추어야 합니다.

A POST request MUST result in a 201 (Created) response.

이것은 클라이언트에게 응답이 항상 201 (Created)이 될 것이라는 기대를 형성하는데, 실제 배포에서는 프록시가 인증을 요구할 수 있거나 서버 측 오류가 발생하거나 리디렉션이 있을 수 있는 등 상태 코드가 달라질 수 있는 여러 이유가 있습니다. 클라이언트가 이를 예상하지 않으면 애플리케이션의 배포는 취약해집니다.

자세한 내용은 섹션 4.2를 참조하십시오.

또 다른 일반적인 관행은 HTTP 서버의 네임스페이스(또는 그 일부)가 단일 애플리케이션의 전용으로 사용된다고 가정하는 것입니다. 이는 해당 공간에 애플리케이션 특정 의미를 덮어씌우는 것이며 다른 애플리케이션이 이를 사용하지 못하게 합니다.

[BCP190]에서 설명된 바와 같이, 표준이 URL 공간의 일부를 '점유'하는 것은 서버의 리소스에 대한 권한을 강탈하고 배포 문제를 일으킬 수 있으므로 표준 관행으로는 바람직하지 않습니다.

경로와 같은 URI 구성 요소를 정적으로 정의하는 대신, HTTP를 사용하는 애플리케이션은 배포의 유연성을 허용하기 위해 링크 [WEB-LINKING]을 정의하고 사용하는 것이 권장됩니다.

런타임 링크를 이러한 방식으로 사용하면 특히 애플리케이션이 다중 구현 및/또는 배포를 가지는 경우(표준화되는 경우가 흔함) 여러 가지 다른 이점이 있습니다.

예를 들어, 링크로 탐색하면 리디렉션의 오버헤드 없이 요청을 다른 서버로 라우팅할 수 있어 여러 머신에 걸친 배포를 잘 지원할 수 있습니다.

링크를 사용하면 동일한 서버에서 서로 다른 애플리케이션을 "혼합 및 매치"할 수 있게 됩니다. 링크의 문서는 그 대상에 대한 정보도 포함할 수 있기 때문에 확장성, 버전 관리 및 기능 관리에 대한 자연스러운 메커니즘을 제공합니다.

링크를 사용하면 웹에서 볼 수 있는 형태의 캐시 무효화도 제공됩니다; 리소스의 상태가 변경되면 애플리케이션은 영향을 받는 링크를 변경하여 항상 최신 복사본이 가져오도록 할 수 있습니다.

자세한 내용은 섹션 4.4를 참조하십시오.

• 메시지 프레이밍
• 다중화(HTTP/2 [HTTP/2] 및 HTTP/3 [HTTP/3]에서)
• TLS와의 통합
• 중개자(프록시, 게이트웨이, 콘텐츠 전송 네트워크(CDN)) 지원
• 클라이언트 인증
• 형식, 언어 및 기타 기능에 대한 콘텐츠 협상
• 서버 확장성, 대기시간 및 대역폭 감소, 신뢰성을 위한 캐싱
• 풍부한 URL 공간을 통한 접근 제어의 세분성
• 응답의 일부만 선택적으로 요청할 수 있는 부분적 콘텐츠
• 웹 브라우저를 사용하여 애플리케이션과 쉽게 상호작용할 수 있는 능력

HTTP를 사용하는 애플리케이션은 사용자가 이러한 기능으로부터 최대 이점을 얻고 다양한 상황에 배포될 수 있도록 프로토콜이 제공하는 다양한 기능을 활용하는 것이 권장됩니다. 이 문서는 특정 기능의 사용을 요구하지는 않습니다. 적절한 설계 절충은 특정 상황에 따라 매우 달라지기 때문입니다. 그러나 섹션 4의 관행을 따르는 것이 좋은 출발점입니다.

명세서는 HTTP에 대한 기본 참조로 [HTTP]를 사용해야 합니다; 특정 기능이 명시적으로 지적되는 경우를 제외하고 HTTP 제품군의 모든 명세를 참조할 필요는 없습니다.

HTTP는 홉별(hop-by-hop) 프로토콜이므로 연결은 애플리케이션이 제어하지 않는 구현(예: 프록시, CDN, 방화벽 등)에 의해 처리될 수 있습니다. 특정 HTTP 버전을 요구하면 이러한 상황에서 사용하기 어렵고 상호운용성에 해를 끼칩니다. 따라서 HTTP를 사용하는 애플리케이션이 최소 사용 버전을 지정하는 것은 권장되지 않습니다.

그러나 애플리케이션 배포가 특정 HTTP 버전의 사용(예: HTTP/2의 다중화)으로부터 이익을 얻는다면, 이는 명시되어야 합니다.

HTTP를 사용하는 애플리케이션은 프로토콜의 진화를 보장하기 위해 최대 버전을 지정해서는 안 됩니다.

GET /thing HTTP/1.1
Host: example.com
Accept: application/things+json
User-Agent: Foo/1.0

HTTP/1.1 200 OK
Content-Type: application/things+json
Content-Length: 500
Server: Bar/2.2

[content here]

• 종종 JSON과 같은 형식 관습에 기반한 미디어 타입 [RFC6838];
• 섹션 4.7에 따른 HTTP 헤더 필드;
• 링크 관계로 식별되는 리소스가 구현하는 동작(링크 관계 [WEB-LINKING]로 식별).

• 하나 이상의 미디어 타입으로 식별된 형식에서 GET을 사용하여 리소스 상태를 조회;
• 적절히 식별된 요청 콘텐츠 형식을 사용하여 POST 또는 PUT으로 리소스 생성 또는 업데이트;
• POST와 식별된 요청 및 응답 콘텐츠 형식을 사용한 데이터 처리;
• DELETE를 사용한 리소스 삭제.

"example-widget" 링크 관계 유형으로 링크된 리소스는 Widgets입니다. Widget의 상태는 "application/example-widget+json" 형식으로 가져올 수 있으며, 동일한 링크에 PUT하여 업데이트할 수 있습니다. Widget 리소스는 삭제할 수 있습니다.

Widget 표현에 있는 Example-Count 응답 헤더 필드는 발신자가 보유한 Widget의 수를 나타냅니다.

"application/example-widget+json" 형식은 Widget의 상태를 나타내는 JSON [RFC8259] 형식입니다. 그것은 Link 헤더 필드 값에 "example-other-info" 링크 관계 유형으로 표시된 링크에서 관련 정보를 가리키는 링크를 포함합니다.

애플리케이션은 또한 클라이언트가 런타임 데이터를 기반으로 URL을 생성할 수 있도록 URI 템플릿 [URI-TEMPLATE]의 사용을 명시할 수 있습니다.

애플리케이션이 클라이언트 동작에 대해 기대하는 바는 웹 브라우저의 기대와 밀접하게 맞추어야 서로 사용될 때 상호운용성 문제를 피할 수 있습니다.

이렇게 하는 한 가지 방법은 브라우저가 HTTP에 대해 사용하는 추상화인 [FETCH]를 기준으로 정의하는 것입니다.

리디렉션 처리:

애플리케이션은 리디렉션이 어떻게 처리되기를 기대하는지 명시할 필요가 있습니다; 섹션 4.6.1을 참조하십시오.

쿠키:

HTTP를 사용하는 애플리케이션은 쿠키가 필요하다면 쿠키 명세 [COOKIES]를 명시적으로 참조해야 합니다.

인증서:

HTTP를 사용하는 애플리케이션은 HTTPS가 사용될 때 TLS 인증서를 Section 4.3.4에 따라 확인하도록 명시해야 합니다.

HTTP를 사용하는 애플리케이션은 협상되는 것이 일반적인 HTTP 기능을 클라이언트가 정적으로 지원하도록 요구해서는 안 됩니다. 예를 들어 특정 콘텐츠 인코딩을 가진 응답을 클라이언트가 반드시 지원해야 한다고 요구([HTTP], Section 8.4.1)하는 대신 이를 위해 협상하도록([HTTP], Section 12.5.3) 요구하면, 그렇지 않은 준수 클라이언트는 애플리케이션과 상호운용할 수 없습니다. 다만 애플리케이션은 이러한 기능의 구현을 장려할 수 있습니다.

HTTP에서 클라이언트가 상호작용하는 리소스는 URL로 식별됩니다 [URL]. [BCP190]가 설명하듯, URL의 일부는 그 서버의 소유자(또는 "권한")가 제어하도록 설계되어 배포에서 유연성을 제공합니다.

이는 대부분의 경우 HTTP를 사용하는 애플리케이션 명세가 고정된 애플리케이션 URL이나 경로를 포함하지 않음을 의미합니다; 단일 배포 API의 명세에서 "/app/v1"과 같은 경로 접두사를 지정하는 것은 일반적이지만, IETF 명세에서 그렇게 하는 것은 부적절합니다.

따라서 명세 작성자는 클라이언트가 애플리케이션의 URL을 발견할 수 있도록 하는 메커니즘을 제공해야 합니다. 또한 어떤 URL 스킴을 사용할지, 전용 포트를 사용할지 HTTP의 포트를 재사용할지 여부를 명시해야 합니다.

HTTP를 사용하는 애플리케이션은 GET, POST, PUT, DELETE, PATCH와 같은 등록된 HTTP 메서드만 사용해야 합니다.

새로운 HTTP 메서드는 드물며, IETF 검토와 함께 "HTTP Method Registry"에 등록되어야 하며([HTTP] 참조), 또한 일반적이어야 합니다. 즉, 해당 메서드는 한 애플리케이션의 리소스에만 적용되는 것이 아니라 잠재적으로 모든 리소스에 적용될 수 있어야 합니다.

역사적으로 일부 애플리케이션(예: [RFC4791])이 애플리케이션 전용 메서드를 정의한 적이 있지만, [HTTP]은 이제 이를 금지합니다.

저자들이 새 메서드가 필요하다고 믿는 경우, 조기에 HTTP 커뮤니티와 논의(예: <mailto:ietf-http-wg@w3.org> 메일링 리스트)를 하고 애플리케이션 명세의 일부로서가 아니라 별도의 HTTP 확장으로 그 제안을 문서화하는 것이 권장됩니다.

HTTP 상태 코드는 캐시, 중개자 및 클라이언트와 같은 일반적인 HTTP 구성요소와 애플리케이션 자체를 위해 의미를 전달합니다. 그러나 애플리케이션은 이를 사용할 때 여러 함정에 직면할 수 있습니다.

첫째, 상태 코드는 종종 애플리케이션 자체가 아닌 다른 구성요소에 의해 생성됩니다. 이는 네트워크 오류가 발생하거나, 캡티브 포털, 프록시 또는 콘텐츠 전송 네트워크가 존재하거나, 서버가 과부하 상태이거나 공격을 받는다고 판단할 때 발생할 수 있습니다. 특정 오류 조건이 발생할 때 일반적인 클라이언트 소프트웨어가 상태 코드를 생성할 수도 있습니다. 그 결과, 애플리케이션이 이러한 상태 코드 중 하나에 특정 의미를 부여하면 클라이언트는 해당 상태 코드가 애플리케이션이 아니라 일반 구성요소에 의해 생성되었기 때문에 자신의 상태를 오해할 수 있습니다.

더욱이, 애플리케이션 오류를 개별 HTTP 상태 코드에 일대일로 매핑하면 적용 가능한 HTTP 상태 코드의 유한한 공간이 소진되는 상황으로 이어지는 경우가 많습니다. 이는 새로운 애플리케이션 전용 상태 코드를 생성하거나 기존 상태 코드를 애플리케이션 의미와 거의 관련이 없음에도 사용하는 등 여러 나쁜 관행으로 이어집니다.

대신, HTTP를 사용하는 애플리케이션은 가장 적용 가능한 상태 코드를 사용하고 의심스러운 경우 일반 상태 코드(200, 400, 500)를 관대하게 사용하는 것이 좋습니다. 중요하게도, 상태 코드와 애플리케이션 오류 간의 일대일 관계를 지정하지 않아야 합니다. 이렇게 하면 앞서 설명한 소진 문제를 피할 수 있습니다.

동일한 상태 코드에 매핑된 여러 오류 조건을 구별하고 앞서 언급한 잘못된 귀속 문제를 피하기 위해, HTTP를 사용하는 애플리케이션은 응답의 메시지 콘텐츠 및/또는 헤더 필드에서 더 세분화된 오류 정보를 전달해야 합니다. [PROBLEM-DETAILS]는 이를 구현하는 한 가지 방법을 제공합니다.

등록된 HTTP 상태 코드 집합은 확장될 수 있으므로, HTTP를 사용하는 애플리케이션은 클라이언트가 모든 적용 가능한 상태 코드를 우아하게 처리할 수 있어야 한다고 명시하는 것이 좋습니다(즉, 특정 상태 코드를 인식하지 못할 경우 해당 상태 코드의 일반적인 n00 의미로 폴백하는 것; 예: 499를 인식하지 못하는 클라이언트는 안전하게 400(Bad Request)으로 처리할 수 있음). 이는 가능한 상태 코드의 "목록"을 나열하는 것보다 바람직한데, 그러한 목록은 가까운 미래에 완전하지 않을 것이기 때문입니다.

HTTP를 사용하는 애플리케이션은 HTTP 상태 코드의 의미를 재명세해서는 안 됩니다, 설령 그것이 정의를 복사하는 것뿐이라도 마찬가지입니다. 또한 특정 이유 구문(reason phrase)의 사용을 요구하는 것은 권장되지 않습니다; 이유 구문은 HTTP에서 기능을 갖지 않으며 구현에 의해 보존될 것이라고 보장되지 않고 HTTP/2 메시지 형식에는 전혀 포함되지 않습니다.

애플리케이션은 반드시 등록된 HTTP 상태 코드만 사용해야 합니다. 메서드와 마찬가지로 새로운 HTTP 상태 코드는 드물며, [HTTP]에 의해 IETF 검토로 등록되어야 합니다. 유사하게, HTTP 상태 코드는 일반적이어야 하며([HTTP]에 의해 요구됨), 한 애플리케이션의 리소스에만 적용되는 것이 아니라 잠재적으로 모든 리소스에 적용 가능해야 합니다.

저자들이 새 상태 코드가 필요하다고 생각하면 조기에 HTTP 커뮤니티와 논의(예: <mailto:ietf-http-wg@w3.org> 메일링 리스트)를 하고 그 제안을 애플리케이션 명세의 일부로서가 아니라 별도의 HTTP 확장으로 문서화하는 것이 권장됩니다.

• 필드가 중개자에게 유용한 경우(중개자는 종종 메시지 콘텐츠를 파싱하지 않으려 함), 및/또는
• 필드가 일반 HTTP 소프트웨어(예: 클라이언트, 서버)에 유용한 경우, 및/또는
• 값을 메시지 콘텐츠에 포함할 수 없는 경우(일반적으로 형식이 허용하지 않음).

위 조건이 충족되지 않는 경우에는 일반적으로 애플리케이션 특정 정보를 메시지 콘텐츠나 URL 쿼리 문자열 등의 다른 장소에 전달하는 것이 더 낫습니다.

새 헤더 필드는 Section 16.3에 따라 등록되어야 합니다 ([HTTP]).

새 헤더 필드를 발행할 때 고려할 지침은 Section 16.3.2를 참조하십시오. [STRUCTURED-FIELDS]는 새 헤더 필드에 대한 공통 구조를 제공하여 파싱 및 처리의 여러 문제를 피하므로, 새 헤더 필드에 이를 사용하는 것이 권장됩니다.

헤더 필드 이름은 짧게 하는 것이 권장됩니다 (필드 압축이 사용되더라도 오버헤드가 있기 때문) 그러나 적절히 구체적이어야 합니다. 특히 헤더 필드가 애플리케이션에 특화된 경우, 애플리케이션 식별자가 하이픈으로 구분된 접두사로 필드 이름을 구성할 수 있습니다.

예를 들어 "example" 애플리케이션이 세 개의 헤더 필드를 만들어야 한다면 "example-foo", "example-bar", "example-baz"라고 부를 수 있습니다. 여기서 주요 동기는 네임스페이스의 더 일반적인 필드 이름을 소비하는 것을 피하기 위함이지, 애플리케이션을 위해 네임스페이스 일부를 예약하려는 것은 아닙니다; 관련 고려사항은 [RFC6648]를 참조하십시오.

기존 HTTP 헤더 필드의 의미는 등록을 업데이트하거나(허용되는 경우) 해당 확장을 정의하지 않고 재정의해서는 안 됩니다. 예를 들어, HTTP를 사용하는 애플리케이션은 특정 문맥에서 Location 헤더 필드에 특수한 의미를 부여할 수 없습니다.

헤더 필드와 HTTP 캐싱 간의 상호작용에 대해서는 섹션 4.9를 참조하십시오; 특히 응답 선택(선택에 사용되는 요청 헤더 필드, Section 4.1 참조)의 경우 캐싱에 영향을 미치므로 신중히 고려해야 합니다.

애플리케이션 상태(예: Cookie)를 전달하는 헤더 필드에 관한 고려사항은 섹션 4.10을 참조하십시오.

메시지 콘텐츠에 대한 일반적인 구문 관습에는 JSON [JSON], XML [XML], CBOR [RFC8949] 등이 있습니다. 이러한 사용에 대한 모범 사례는 이 문서의 범위를 벗어납니다.

애플리케이션은 정의하는 각 형식에 대해 고유한 미디어 타입을 등록해야 합니다; 이렇게 하면 해당 형식을 명확하게 식별하고 사용을 협상할 수 있습니다. 자세한 내용은 [RFC6838]를 참조하십시오.

HTTP 캐싱 [HTTP-CACHING]은 애플리케이션에 HTTP를 사용하는 주요 이점 중 하나입니다; 스케일링을 제공하고 대기시간을 줄이며 신뢰성을 향상시킵니다. 또한 HTTP 캐시는 브라우저 및 기타 클라이언트, 네트워크의 포워드 및 리버스 프록시, CDN, 서버 소프트웨어의 일부로서 쉽게 이용 가능합니다.

애플리케이션이 캐싱을 활용하도록 설계되지 않았더라도, 응답을 중간에 개입한 캐시가 어떻게 처리할지 고려하여 올바른 동작을 보존해야 합니다(네트워크, 서버, 클라이언트 또는 중간 인프라의 어느 쪽에 개입하든 상관없음).

애플리케이션은 상태 있는 쿠키 [COOKIES]를 사용하여 클라이언트를 식별하거나 클라이언트별 데이터를 저장하여 요청을 맥락화할 수 있습니다.

사용할 때는 쿠키의 범위(scope)와 사용을 신중하게 명시하는 것이 중요합니다; 애플리케이션이 민감한 데이터나 권한을 노출하면(예: 주변 권한(ambient authority)으로 작동) 악용될 수 있습니다. 완화책으로는 클라이언트의 의도를 보장하기 위한 요청별 토큰 사용 등이 있습니다.

클라이언트는 종종 작업을 수행하기 위해 여러 요청을 보내야 합니다.

HTTP/1 [HTTP/1.1]에서는 병렬 요청이 주로 여러 연결을 여는 것으로 지원됩니다. 너무 많은 동시 연결이 사용되면 연결의 혼잡 제어가 조정되지 않아 애플리케이션 성능에 영향을 줄 수 있습니다. 또한 애플리케이션이 언제 요청을 발행하고 특정 요청에 어떤 연결을 사용할지 결정하기 어려워 성능에 추가로 영향을 줄 수 있습니다.

HTTP/2 [HTTP/2] 및 HTTP/3 [HTTP/3]은 애플리케이션에 다중화를 제공하여 여러 연결을 사용할 필요를 제거합니다. 그러나 서버가 응답 우선순위를 선택하는 방식에 따라 애플리케이션 성능이 여전히 크게 영향을 받을 수 있습니다. 애플리케이션에 따라 서버가 응답의 우선순위를 결정하는 것이 최선인지, 아니면 클라이언트가 서버에 우선순위를 힌트로 제공하는 것이 좋은지(예: [HTTP-PRIORITY] 참조) 결정해야 합니다.

모든 HTTP 버전에서 요청은 독립적으로 이루어집니다 — 두 요청의 상대적 순서에 의존하여 처리 순서를 보장할 수 없습니다. 이는 요청이 중개자에 의해 다중화된 프로토콜로 전송되거나 서로 다른 오리진 서버로 전송되거나 서버가 처리 순서를 다르게 수행할 수 있기 때문입니다. 두 요청에 엄격한 순서가 필요하다면, 신뢰할 수 있는 유일한 방법은 첫 번째 요청에 대한 최종 응답이 시작된 후 두 번째 요청을 발행하는 것입니다.

애플리케이션은 단일 전송 연결에서 별도의 요청들 간의 관계에 대해 가정해서는 안 됩니다; 그렇게 하면 HTTP의 무상태성 가정 중 많은 부분을 깨뜨려 상호운용성, 보안, 운용성 및 진화에 문제를 초래합니다.

애플리케이션은 클라이언트를 식별하기 위해 HTTP 인증(Section 11의 [HTTP])을 사용할 수 있습니다. [RFC7617]에 따라 Basic 인증 방식은 채널이 안전하지 않다면(예: "https" URI 스킴 미사용) 민감하거나 가치 있는 정보를 보호하기에 적합하지 않습니다. 유사하게, [RFC7616]은 Digest 인증 방식을 안전한 채널에서 사용하도록 요구합니다.

HTTPS를 사용할 경우 클라이언트는 인증서를 사용하여 인증될 수 있지만 [RFC8446], 그러한 인증은 근본적으로 기저 전송 연결에 범위가 한정되어 있다는 점을 유의하십시오. 결과적으로 클라이언트는 인증된 상태가 응답 준비에 사용되었는지 알 수 있는 방법이 없으며(Vary: * 및/또는 private 캐시 지시어가 부분적인 표시를 제공할 수 있음), 특정하게 비인증 응답을 얻는 유일한 방법은 새 연결을 여는 것입니다.

사용할 때에는 인증의 범위와 사용을 신중하게 명시하는 것이 중요합니다; 애플리케이션이 민감한 데이터나 권한을 노출하면(예: 주변 권한으로 작동) 악용될 수 있습니다. 완화책으로는 클라이언트의 의도를 보장하기 위한 요청별 토큰 사용 등이 있습니다.

애플리케이션이 웹 브라우저와 함께 사용될 의도가 없더라도 그 리소스는 브라우저 및 다른 HTTP 클라이언트에서 여전히 접근 가능할 것입니다. 따라서 HTTP를 사용하는 모든 애플리케이션은 브라우저가 어떻게 상호작용할지, 특히 보안과 관련하여 고려해야 합니다.

예를 들어, 애플리케이션 상태를 POST 요청으로 변경할 수 있다면, 웹 브라우저는 임의의 웹 사이트로부터 교차 사이트 요청 위조(CSRF)를 쉽게 당할 수 있습니다.

또는 공격자가 애플리케이션 리소스에서 반환된 콘텐츠의 일부를 제어하게 되면(예: 요청의 일부가 응답에 반영되거나 응답에 포함된 외부 정보를 공격자가 변경할 수 있는 경우), 공격자는 브라우저에 코드를 주입하고 출처인 것처럼 데이터와 기능에 접근할 수 있습니다. 이는 교차 사이트 스크립팅(XSS) 공격으로 알려진 기법입니다.

이는 HTTP를 사용하는 애플리케이션이 고려해야 할 문제의 일부분에 불과합니다. 일반적으로 최선의 접근법은 애플리케이션을 실제로 웹 애플리케이션으로 간주하고 그들의 안전한 개발을 위한 모범 사례를 따르는 것입니다.

• Content-Type 헤더 필드에 애플리케이션 전용 미디어 타입을 사용하고, 클라이언트가 이를 사용하지 않으면 실패하도록 요구합니다.
• 브라우저가 공격자 제어 콘텐츠를 활성 콘텐츠로 해석하지 못하도록 X-Content-Type-Options: nosniff [FETCH]를 사용합니다.
• 활성 콘텐츠(스크립트를 실행할 수 있는 HTML [HTML] 및 PDF 등)의 기능을 제한하기 위해 Content-Security-Policy [CSP]를 사용하여 XSS 공격을 완화합니다.
• Referrer-Policy [REFERRER-POLICY]를 사용하여 URL의 민감한 데이터가 Referer 요청 헤더 필드에 유출되는 것을 방지합니다.
• 쿠키에 'HttpOnly' 플래그를 사용하여 쿠키가 브라우저 스크립팅 언어에 노출되지 않도록 합니다 [COOKIES].
• 인증 토큰이나 비밀번호와 같은 민감한 정보에는 압축 사용을 피하십시오. 브라우저가 제공하는 스크립팅 환경은 공격자가 압축 공간을 반복적으로 탐침할 수 있게 하며, 공격자가 통신 경로에 접근할 수 있는 경우 이 기능으로부터 정보를 복구할 수 있습니다.

배포 방식에 따라 HTTP를 사용하는 애플리케이션의 명세는 이러한 메커니즘의 사용을 특정 방식으로 요구할 수도 있고, 단지 보안 고려사항에서 이를 지적할 수도 있습니다.

HTTP/1.1 200 OK
Content-Type: application/example+json
X-Content-Type-Options: nosniff
Content-Security-Policy: default-src 'none'
Cache-Control: max-age=3600
Referrer-Policy: no-referrer

[content]

애플리케이션이 브라우저 호환성을 목표로 한다면, 클라이언트 상호작용은 브라우저가 HTTP에 대해 사용하는 추상화인 [FETCH]로 정의되어야 합니다; 이는 이러한 모범 사례 중 많은 것을 강제합니다.

많은 HTTP 기능이 출처(origin)에 범위가 한정되어 있기 때문에 [RFC6454], 애플리케이션은 동일한 오리진 서버를 사용하는 다른 애플리케이션(웹 브라우징 포함)과 배포가 어떻게 상호작용할지 고려해야 합니다.

예를 들어 애플리케이션이 애플리케이션 상태를 전달하기 위해 쿠키 [COOKIES]를 사용하는 경우, 쿠키는 기본적으로(경로로 범위가 지정되지 않는 한) 해당 오리진에 대한 모든 요청에 함께 전송되며, 애플리케이션은 동일한 오리진의 다른 애플리케이션으로부터 쿠키를 받을 수 있습니다. 이는 보안 문제와 쿠키 이름 충돌을 초래할 수 있습니다.

이러한 문제에 대한 한 가지 해결책은 애플리케이션에 전용 호스트 이름을 요구하여 고유한 오리진을 갖게 하는 것입니다. 그러나 여러 애플리케이션을 단일 호스트 이름에 배포하는 것이 바람직할 때가 많습니다; 그렇게 하면 배포의 유연성이 극대화되고 애플리케이션을 "혼합"할 수 있게 됩니다(자세한 내용은 [BCP190] 참조).

따라서 HTTP를 사용하는 애플리케이션은 오리진에서 여러 애플리케이션이 공존할 수 있도록 노력해야 합니다. 특히 쿠키, HTTP 인증 영역([HTTP]) 또는 다른 오리진 전체의 HTTP 메커니즘을 지정할 때 애플리케이션은 특정 이름의 사용을 강제하기보다는 배포가 이를 구성하도록 두어야 합니다. 해당 메커니즘이 제공하는 부분적 범위 지정 방식을 사용하는 것을 고려해야 합니다.

현대 웹 브라우저는 한 오리진의 콘텐츠가 다른 오리진의 리소스에 접근하는 것을 제한하여 개인 정보를 유출하지 않도록 합니다. 결과적으로 브라우저에 교차 출처 데이터를 노출하려는 애플리케이션은 CORS 프로토콜을 구현해야 합니다; [FETCH]를 참조하십시오.

• 서버 푸시는 홉별이며 중개자에 의해 자동으로 전달되지 않습니다. 따라서 프록시, 리버스 프록시 및 CDN과 쉽게(또는 전혀) 작동하지 않을 수 있습니다.
• 서버 푸시는 잘못 사용하면 클라이언트가 실제로 요청한 리소스와 경쟁하는 경우 특히 HTTP 성능에 부정적인 영향을 미칠 수 있습니다.
• 서버 푸시는 HTTP 캐싱과의 상호작용에 관해 클라이언트마다 다르게 구현되며 기능이 다양할 수 있습니다.
• 서버 푸시에 대한 API는 일부 구현에서 현재 제공되지 않으며 다른 구현에서는 크게 다릅니다. 특히 현재 브라우저용 API는 없습니다.
• 서버 푸시는 HTTP/1.1 또는 HTTP/1.0에서는 지원되지 않습니다.
• 서버 푸시는 HTTP의 "핵심" 의미론의 일부가 아니므로 향후 버전의 프로토콜에서 지원되지 않을 수 있습니다.

클라이언트가 전체 응답이 준비되기 전에 관련 작업을 수행할 수 있도록 최적화하려는 애플리케이션은 103 (Early Hints) 상태 코드 사용으로 이점을 얻을 수 있습니다; [RFC8297]를 참조하십시오.

서버 푸시를 직접 사용하는 애플리케이션은 교차 출처 푸시 공격을 피하기 위해 [HTTP/2], Section 8.4의 권한 관련 요구사항을 준수해야 합니다.

애플리케이션 프로토콜에 새 기능을 도입하고 기존 기능을 변경해야 하는 경우가 자주 있습니다.

• 새 기능을 구현하는 리소스의 URL을 식별하기 위해 별도의 링크 관계 유형을 사용하는 것 [WEB-LINKING].
• 새 기능을 가능하게 하는 형식을 식별하기 위해 별도의 미디어 타입을 사용하는 것 [RFC6838].
• 메시지 콘텐츠 외부에서 새 기능을 구현하기 위해 별도의 HTTP 헤더 필드를 사용하는 것.

HTTP 클라이언트는 서버에 다양한 정보를 노출할 수 있습니다. 애플리케이션의 동작의 일부로 명시적으로 전송되는 정보(예: 이름 및 사용자가 입력한 기타 데이터)와 "전송 중"의 정보(이것이 섹션 4.4.2에서 "https"가 권장되는 이유 중 하나입니다) 외에도, 덜 명백한 수단을 통해 시간이 지남에 따라 사용자의 활동을 연결하여 다른 정보를 수집할 수 있습니다.

여기에는 세션 정보, 클라이언트의 지문(fingerprinting)을 통한 추적, 코드 실행 등이 포함됩니다.

세션 정보에는 클라이언트의 IP 주소, TLS 세션 티켓, 쿠키, 클라이언트 캐시에 저장된 ETag 및 기타 상태성 메커니즘이 포함됩니다. 애플리케이션은 불가피하거나 운영에 필요하지 않는 한 세션 메커니즘의 사용을 피하는 것이 권장되며, 필요한 경우 이러한 위험을 문서화해야 합니다. 사용되는 경우 구현체가 이러한 상태를 지우도록 허용하는 것을 장려해야 합니다.

지문 추적은 클라이언트 메시지와 동작의 고유한 특성을 이용해 서로 다른 요청과 연결하는 기법입니다. 예를 들어 User-Agent 요청 헤더 필드는 구현에 관한 특정 정보를 전달하고, Accept-Language 요청 헤더 필드는 사용자의 선호 언어를 전달합니다. 이러한 여러 표시기가 결합되면 클라이언트를 고유하게 식별하는 데 사용되어 그 사용자의 데이터 통제에 영향을 줄 수 있습니다. 따라서 애플리케이션은 클라이언트가 요청에서 기능 수행에 필요한 정보만 발신하도록 지정하도록 권고합니다.

마지막으로, 애플리케이션이 코드 실행 기능을 노출하는 경우 환경을 관찰할 수 있는 모든 능력은 클라이언트 지문 생성과 개인 데이터(세션 정보 포함)의 획득 및 조작 기회로 사용될 수 있으므로 큰 주의가 필요합니다. 예를 들어 고해상도 타이머에 대한 접근(간접 포함)은 하드웨어를 프로파일링하여 시스템의 고유 식별자를 생성하는 데 사용될 수 있습니다. 애플리케이션은 가능한 한 모바일 코드 사용을 허용하지 않는 것이 권장되며, 피할 수 없는 경우 해당 시스템의 보안 속성을 신중하게 검토해야 합니다.