HTTP 1.1 : Semantics and Content - LOG.INFO

배경

이번 포스팅에는 HTTP 1.1 Semantics and Content을 정의한 RFC-7231를 읽고 포스팅한다.

목차는 다음과 같다

  1. 소개
  2. Resources
  3. Representations
  4. Request Methods
  5. Request Header Fields
  6. Response Statue Codes
    1. Informational 1xx
    2. Successful 2xx
    3. Redirection 3xx
    4. Client Error 4xx
    5. Server Error 5xx
  7. Response Header Fields
  8. IANA Considerations
  9. Security Considerations
  10. Acknowledgements

HTTP 1.1

HTTP

  • HyperText Transfer Protocol의 약자로,
  • 분산·종합·하이퍼미디어 정보 시스템들을 위한
  • StatelessApplication level프로토콜이다.

이 RFC 문서는 다음을 통해 표현되는 HTTP 1.1 메시지의 의미를 정의한다

  • 요청 메서드(Request methods)
  • 요청 헤더 필드(Request header field)
  • 응답 상태 코드(Response status code)
  • 응답 헤더 필드(Response header field)
  • 페이로드(Payload : meta-data + body)
  • Content-Negotiation의 메커니즘

1. 소개

각 HTTP 메시지는 요청 또는 응답이다.

서버는 각 HTTP 메시지 요청에 대한

  • 연결을 수신하고,
  • 각 메시지를 파싱하며,
  • 식별된 요청 대상에 대한 메시지를 해석하여,
  • 하나 이상의 메시지로 응답한다

2. Resources

Resource는 무엇이든 될 수 있으며, HTTP가 제공하는 균일한 인터페이스는 다른 쪽의 독립 행위자에게 메시지의 통신을 통해서만 조회하고 행동할 수 있는 유리창과 유사하다는 점을 고려하면, 현재 또는 기대되는 상태를 나타내는 추상화가 필요하다. 이러한 추상화REST라고 한다.

3. Representation

HTTP의 목적을 위해, Representation은 주어진 자원의 과거, 현재, 미래를 반영하기 위한 정보로서 다음으로 구성된다.

  • 메타데이터의 집합
  • 잠재적으로 무제한적인 Representation 데이터 흐름

3-1. Representation Metadata

Represention Header Fields는 표현에 대한 메타데이터를 제공한다.

메시지에 payload body가 포함되는 경우, Representation Fieldspayload bodyRepresentation data를 해석하는 방법을 설명한다.

Representation Meta-data의 예

  • Content-Type
  • Content-Encoding
  • Content-Language
  • Content-Location

3-1-1. Representation Data 처리

  • Media Type
    • HTTP는 개방적이고 확장 가능한 데이터 입력 및 Type Negotiation을 제공하기 위해 Content-TypeAccept 헤더 필드에 Internet media type들을 정의한다.
    • Media types데이터 형식다양한 처리 모델을 정의한다.
      • 다양한 처리 모델 정의 : 데이터를 수신하는 각 context마다 데이터를 어떻게 처리할지 정의
    • ex) text/html;charset=utf-8
  • Charset
    • Charset은 RFC2978에 따라 IANA “Character Sets” registry에 등록해야 한다.
  • Multipart Types
  • Content-Type

3-1-2. 압축 및 통합을 위한 인코딩

  • Content-Codings
  • Content-Encoding
    • Content-Encoding: gzip

3-1-3. Audience Language

  • Language Tags
  • Content Language
    • Content-Language: mi, en

3-1-4. Identification

  • Identifying a Representation
  • Content-Location
    • Content-Location = absolute-URI / partial-URI

3-2. Representation Data

HTTP 메시지에서 Representation Data는 메시지의 payload body로 제공되거나, 메시지의 sementic 또는 effective request URI를 통해 참조된다.

Representation Datarepresentation metadata header fields에 의해 정의된 formatencoding 안에 있다(?)

Representation Data의 데이터 타입은 Header fields의 Content-TypeContent-Encoding을 통해 결정된다.

  • representation-data := Content-Encoding( Content-Type( bits ) )

3-3. 페이로드 의미론

일부 HTTP 메시지들은 payload로 완전하거나 부분적인 representation를 전송한다. 경우에 따라서는 페이로드에 관련 representation header 필드(ex. HEAD에 대한 응답)나, representation의 일부(ex. 206 상태코드)만 포함될 수 있다.

다음과 같이, 요청에서 페이로드의 목적method sementic에 의해 정의된다.

  • payload of PUT request
    • 타겟 resource의 기대되는 상태(변경할 정보)
  • payload of POST request
    • 타겟 resource에 의해 처리될 정보(새로운 정보)

또한, 다음과 같이, 응답에서 페이로드의 목적request methodresponse status code 둘 다에 의해 정의된다.

  • payload of GET, status code 200 response
    • 대상 resource현재 상태
  • payload of POST, status code 200 response
    • 처리 결과 or 대상 resource새로운 현재 상태

관련 표현이 아닌 페이로드(payload header)를 구체적으로 기술하는 헤더 필드를 “페이로드 헤더 필드”라고 한다.

  • Content-Length
  • Content-Range
  • Trailer
  • Transfer-Encoding

3-4. Content Negotiation

HTTP 응답에서 다음과 같은 이유로 Content Negotitation을 위한 메커니즘을 제공한다.

  • 성공 또는 오류에 대한 페이로드를 전달할 때, 종종 서버는 다른 방법(다른 포맷, 언어, 인코딩 등)으로 정보를 표현한다.
  • 유저나 유저 에이전트에 따라 representation이 다른 기능, 특성, 선호도를 가질 수 있다.

Content Negotiation 방식은 다음 두 가지로 정의된다.

  • Proactive Negotiation
    • User agent의 명시적 선호에 따라 representation을 선택
    • Server-Driven
  • Reactive Negotiation
    • User agent가 서버에서 제공하는 representation 목록을 선택
    • Agent-Driven

그 외에 다른 Content Negotiation 방식으로는 다음과 같은 것들이 있고, 이 방식들은 상호 배타적이지 않고, 각각 적용 가능성(?)과 실용성에 있어 trade-off를 가지고 있다.

  • Conditinal Content
    • User agent의 파라미터에 따라 선택적으로 렌더링되는 여러 부분으로 representation을 구성
  • Active Content
    • User agent의 특성에 따라 (좀 더 구체적인)추가 요청을 하는 스크립트를 포함
  • Transparent Content Negotiation
    • 제 3자(intermediary)가 content를 선택

3-4-1. Proactive Negotiation (Server-Driven Negotiation)

명시적인 Section 5.3의 negotiation fields와 암시적인 특성들(클라이언트의 네트워크 주소, User-Agent field 등)을 포함한다.

서버의 추측(?)을 향상시키기 위해, user agent는 기본 설정을 묘사하는 요청 헤더 필드를 전송한다.

  • 유리한 경우
    • 사용 가능한 representation 중 선택 가능한 알고리즘을 user agent에게 설명하기 어려운 경우
    • 서버가 user agent에게 “최선의 추측”을 보내기를 기대하는 경우
  • 심각한 단점
    • 서버가 사용자에게 ‘최선’이 될 수 있는 것을 정확하게 결정하는 것은 불가능. 그러기 위해선 user agent의 기능과 응답의 의도된 용도에 대한 완전한 지식이 필요함
      • ex) 화면에 출력? 종이로 출력?
    • user agent가 모든 요청에서 자신의 능력을 설명하도록 하는 것은 매우 비효율적일 수 있음
    • 사용자의 프라이버시에 잠재적 위험
    • 응답을 하기 위한 알고리즘과 서버 구현을 복잡하게 만듦
    • 공유된 캐싱의 재사용성을 제한

3-4-2. Reactive Negotiation (Agent-Driven Negotiation)

대체 표현을 위한 리소스 목록이 포함된 원본 서버로부터 초기 응답을 받은 후 user agent에 의해 최상의 응답 표현(상태 코드와 관계없이)을 선택한다.

user agent가 초기 응답 표현에 만족하지 않는 경우, 목록에 포함된 메타데이터에 기반하여 선택한 하나 이상의 대체 리소스에 대해 GET 요청을 수행하여 해당 응답에 대한 다른 표현 형식을 얻을 수 있다.

8.

더 알아보자

  • IETF(Internet Engineering Task Force)
  • IANA(Internet Assigned Numbers Authority)
  • Content Negotiation
  • Type Negotitation

참고 문헌

RFC-7231