[RFC1945] HTTP1.0

HTTP 목적

웹 상의 리소스(문서, 이미지, JSON 등)의 표현(representation)을 표준화된 요청/응답 방식으로 서로 주고받게 만드는 것

어떤 클라이언트(브라우저·앱)와 어떤 서버라도 상호운용되도록, 확장 가능하고, 캐시 가능한 방식으로 통신을 규정합니다.

전반적인 운영

HTTP 프로토콜은 요청/응답 패러다임을 기반으로 한다.

클라이언트는 서버와의 연결을 설정하고 요청 메서드, URI 및 프로토콜 버전 형식으로 서버에 요청을 보낸 다음 요청 수정자, 클라이언트 정보 및 가능한 본문 내용이 포함된 MIME 형식 메시지를 보냅니다.

서버는 메시지의 프로토콜 버전과 성공 또는 오류 코드를 포함하는 상태 줄과 서버 정보, 엔티티 메타 정보 및 ㄷ가능한 본문 내용을 포함하는 MIME 형식의 메시지가 표시됩니다.

대부분의 HTTP 통신은 사용자 에이전트에 의해 시작되며 일부 원본 서버의 리소스에 적용되는 요청으로 구성됩니다.
가장 간단한 경우 이는 사용자 에이전트와 원본 서버 간의 단일 연결을 통해 수행될 수 있습니다.

          request chain ------------------------>
       UA -------------------v------------------- O
          <----------------------- response chain

요청/응답 체인에 하나 이상의 중개자가 있으면 더 복잡한 상황이 발생합니다. 중개자에는 프록시, 게이트웨이, 터널의 세가지 일반적인 형태가 있습니다.

프록시는 절대 형식로 URI에 대한 요청을 수신하고, 메시지의 전부 또는 일부를 다시 작성하고, 형식이 변경된 요청을 URI로 식별되는 서버로 전달하는 전달 에이전트입니다.

게이트웨이는 다른 서버 위의 계층 역할을 하는 수신 에이전트 이며, 필요한 경우 요청을 기본 서버의 프로토콜로 변환합니다.

터널은 메시지를 변경하지 않고 두 연결 간의 중계 지점 역할을 합니다. 터널은 중개자가 메시지의 내용을 이해할 수 없는 경우에도 통신이 중개자(ex: 방화벽)를 통과해야할 때 사양됩니다.

          request chain -------------------------------------->
       UA -----v----- A -----v----- B -----v----- C -----v----- O
          <------------------------------------- response chain

위 그림은 사용자 에이전트와 원본 서버 사이의 세 가지 중개자(A, B, C)를 보여줍니다. 전체 체인을 이동하는 요청 또는 응답 메시지는 4개의 개별 연결을 통과해야합니다.

일부 HTTP 통신 옵션은 가장 가까운 터널이 아닌 이웃과의 연결에만 적용되거나 체인의 끝점에만 적용되거나 체인을 따른 모든 연결에 적용될 수 있으므로 이러한 구별이 중요합니다. 다이어그램은 선형이지만 각 참가자는 여러 동시 통신에 참여할 수 있습니다. 예를 들어, B는 A 이외의 많은 클라이언트로부터 요청을 수신하거나 A의 요청을 처리하는 동시에 C이외의 서버로 요청이 전달할 수 있습니다.

터널 역할을 하지 않는 통신 당사자는 요청 처리를 위해 내부 캐시를 사용할 수 있습니다. 캐시의 효과는 체인에 있는 참가자 중 하나가 해당 요청에 적용할 수 있는 캐시된 응답을 가지고 있는 경우 요청/응답 체인이 단축될 수 있습니다.

UA나 A의 요청을 B에다가 보냈을 때, O나 C를 통해 받은 응답 캐시를 보낼 수 있습니다.

          request chain ---------->
       UA -----v----- A -----v----- B - - - - - - C - - - - - - O
          <--------- response chain

모든 응답을 캐시할 수 있는 것은 아니지만 일부 요청에는 캐시 동작에 특별한 요구 사항을 적용하는 수정자가 포함될 수 있다.

HTTP Version

HTTP는 "." 번호 지정 체계를 사용하여 프로토콜 버전을 나타냅니다.

메이저 번호와 마이너 번호는 별도의 정수로 처리되어야 하며 각각은 한 자리보다 높게 증가할 수 있습니다. 따라서 HTTP/2.4는 HTTP/2.13보다 낮은 버전이고 HTTP/12.3보다 낮은 버전입니다. 수신자는 앞에 오는 0을 무시해야 하며 발신자는 절대 생성하지 않아야 합니다.

  HTTP/1.0 servers must:

      o recognize the format of the Request-Line for HTTP/0.9 and HTTP/1.0 requests;

      o understand any valid request in the format of HTTP/0.9 or HTTP/1.0;

  HTTP/1.0 clients must:

      o recognize the format of the Status-Line for HTTP/1.0 responses;

프록시 및 게이트웨이 애플리케이션은 애플리케이션의 기본 HTTP 버전과 다른 형식으로 수신된 요청을 전달할 때 주의해야 합니다. 프로토콜 버전은 보낸 사람의 프로토콜 기능을 나타내므로 프록시/게이트웨이는 기본 버전보다 높은 버전 표시가 있는 메시지를 보내면 안 됩니다. 더 높은 버전의 요청이 수신되면 프록시/게이트웨이는 요청 버전을 다운그레이드하거나 오류로 응답해야 합니다. 애플리케이션의 기본 형식보다 낮은 버전의 요청은 전달되기 전에 업그레이드될 수 있습니다. 해당 요청에 대한 프록시/게이트웨이의 응답은 위에 나열된 서버 요구 사항을 따라야 합니다.

Uniform Resurce Identifiers

URI는 WWW 주소, 범용 문서 식별자 (Universal Document Identifier), 범용 자원 식별자 (Universal Resource Identifier), URL(Uniform Resource Locator) 과 이름 (URN) 의 조합 등 다양한 이름으로 알려져 있습니다. HTTP에 관한 한, 통일 자원 식별자는 이름, 위치 또는 기타 특성을 통해 네트워크 자원을 식별하는 단순한 형식의 문자열입니다.

HTTP URL

"http" 구성표는 HTTP 프로토콜을 통해 네트워크 리소스를 찾는 데 사용됩니다. 이 섹션에서는 http URL에 대한 체계별 구문과 의미를 정의합니다.

       http_URL       = "http:" "//" host [ ":" port ] [ abs_path ]

       host           = <A legal Internet host domain name
                         or IP address (in dotted-decimal form),
                         as defined by Section 2.1 of RFC 1123>

       port           = *DIGIT

포트가 비어 있거나 지정되지 않은 경우 포트 80이 가정됩니다. 의미론은 식별된 리소스가 해당 호스트의 해당 포트에서 TCP 연결을 수신하는 서버에 있고 리소스에 대한 요청-URI가 abs_path라는 것입니다. URL에 abs_path가 없으면 Request-URI로 사용될 때 "/"로 제공되어야 합니다(섹션 5.1.2).

HTTP 프로토콜은 전송 계층 프로토콜과 독립적이지만 http URL은 TCP 위치로만 리소스를 식별하므로 비 TCP 리소스는 다른 URI 체계로 식별해야 합니다.

"http" URL의 표준 형식은 호스트의 모든 UPALPHA 문자를 해당 LOALPHA 문자로 변환하고(호스트 이름은 대소문자를 구분하지 않음) 포트가 80인 경우 [ ":" 포트 ]를 삭제하고 빈 abs_path를 " /".

Date/Time Formats

HTTP/1.0 애플리케이션은 역사적으로 날짜/시간 스탬프 표시에 대해 세 가지 다른 형식을 허용했습니다.

         Sun, 06 Nov 1994 08:49:37 GMT    ; RFC 822, updated by RFC 1123
       Sunday, 06-Nov-94 08:49:37 GMT   ; RFC 850, obsoleted by RFC 1036
       Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format

모든 HTTP/1.0 날짜/시간 스탬프는 예외 없이 GMT(그리니치 표준시)라고도 알려진 UT(세계시)로 표시되어야 합니다. 이는 시간대에 대한 3글자 약어로 "GMT"를 포함하여 처음 두 형식으로 표시되며 asctime 형식을 읽을 때 가정되어야 합니다.

Content Codings

콘텐츠 코딩 값은 리소스에 적용된 인코딩 변환을 나타내는 데 사용됩니다. 콘텐츠 코딩은 기본 미디어 유형의 ID를 잃지 않고 문서를 압축하거나 암호화하는 데 주로 사용됩니다. 일반적으로 리소스는 이 인코딩으로 저장되며 렌더링 또는 유사한 사용 전에만 디코딩됩니다.

       content-coding = "x-gzip" | "x-compress" | token

Media Type

HTTP는 개방적이고 확장 가능한 데이터 유형을 제공하기 위해 Content-Type 헤더 를 사용합니다.

        media-type     = type "/" subtype *( ";" parameter )
       type           = token
       subtype        = token

Canonicalization and Text Defaults

인터넷 미디어 유형은 표준 형식으로 등록됩니다. 일반적으로 HTTP를 통해 전송되는 Entity-Body는 전송 전에 적절한 표준 형식으로 표현되어야 합니다. 본문이 Content-Encoding으로 인코딩된 경우 기본 데이터는 인코딩되기 전에 표준 형식이어야 합니다.

"텍스트" 유형의 미디어 하위 유형은 표준 형식일 때 CRLF를 텍스트 줄 바꿈으로 사용합니다. 그러나 HTTP는 Entity-Body 내에서 일관되게 사용될 때 줄 바꿈을 나타내는 일반 CR 또는 LF만으로 텍스트 미디어를 전송할 수 있습니다. HTTP 애플리케이션은 HTTP를 통해 수신된 텍스트 미디어의 줄 바꿈을 나타내는 CRLF, 베어 CR 및 베어 LF를 허용해야 합니다.

또한 일부 멀티바이트 문자 집합의 경우처럼 텍스트 미디어가 CR과 LF에 각각 옥텟 13과 10을 사용하지 않는 문자 집합으로 표현되는 경우 HTTP는 다음과 같이 정의된 옥텟 시퀀스의 사용을 허용합니다. 줄 바꿈에 대한 CR 및 LF와 동일한 문자 집합입니다. 줄 바꿈과 관련된 이러한 유연성은 Entity-Body의 텍스트 미디어에만 적용됩니다. HTTP 제어 구조(예: 헤더 필드 및 멀티파트 경계) 내에서 CRLF를 베어 CR 또는 LF로 대체해서는 안 됩니다.

"charset" 매개변수는 일부 미디어 유형에서 데이터의 문자 집합을 정의하는 데 사용됩니다. 보낸 사람이 명시적인 charset 매개 변수를 제공하지 않으면 "text" 유형의 미디어 하위 유형은 HTTP를 통해 수신될 때 "ISO-8859-1"의 기본 문자 집합 값을 갖도록 정의됩니다. "ISO-8859-1" 이외의 문자 세트 또는 그 하위 세트의 데이터는 수신자가 일관되게 해석할 수 있도록 적절한 문자 세트 값으로 레이블을 지정해야 합니다.

참고: 현재 많은 HTTP 서버는 적절한 라벨링 없이 "ISO-8859-1" 이외의 문자 세트를 사용하여 데이터를 제공합니다. 이 상황은 상호 운용성을 감소시키므로 권장되지 않습니다. 이를 보완하기 위해 일부 HTTP 사용자 에이전트는 charset 매개변수가 제공되지 않을 때 사용자가 미디어 유형 문자 집합의 기본 해석을 변경할 수 있도록 구성 옵션을 제공합니다.

Multipart Types

MIME은 단일 메시지의 Entity-Body 내에 여러 엔터티를 캡슐화하는 다양한 "다중 부분" 유형을 제공합니다. IANA에 등록된 다중 부분 유형은 HTTP/1.0에 대해 특별한 의미를 갖지 않지만 사용자 에이전트는 각 본문 부분의 목적을 올바르게 해석하기 위해 각 유형을 이해해야 할 수 있습니다. HTTP 사용자 에이전트는 멀티파트 유형을 수신할 때 MIME 사용자 에이전트가 수행하는 것과 동일하거나 유사한 동작을 따라야 합니다. HTTP 서버는 모든 HTTP 클라이언트가 멀티파트 유형을 처리할 준비가 되어 있다고 가정해서는 안 됩니다.

모든 멀티파트 유형은 공통 구문을 공유하며 미디어 유형 값의 일부로 경계 매개변수를 포함해야 합니다. 메시지 본문은 그 자체로 프로토콜 요소이므로 본문 부분 사이의 줄 바꿈을 나타내기 위해 CRLF만 사용해야 합니다. 다중 부분 본문 부분에는 해당 부분의 의미에 중요한 HTTP 헤더 필드가 포함될 수 있습니다.

Method

Method 토큰은 Request-URI에 의해 식별된 리소스에 대해 수행될 메서드를 나타냅니다. 이 방법은 대소문자를 구분합니다.

  Method         =  "GET"  
                  | "HEAD"
                  | "POST"
                  | extension-method

  extension-method = token

특정 리소스에서 허용되는 메서드 목록은 동적으로 변경될 수 있습니다. 리소스에 메서드가 허용되지 않는 경우 클라이언트는 응답의 반환 코드를 통해 알림을 받습니다. 메서드가 인식되지 않거나 구현되지 않은 경우 서버는 상태 코드 501(구현되지 않음)을 반환해야 합니다.

GET 메소드는 요청-URI에 의해 식별되는 모든 정보(엔티티 형식)를 검색하는 것을 의미합니다. 요청-URI가 데이터 생성 프로세스를 참조하는 경우 해당 텍스트가 프로세스의 출력이 아닌 한 프로세스의 소스 텍스트가 아닌 응답의 엔터티로 반환되는 것은 생성된 데이터입니다.

요청 메시지에 If-Modified-Since 헤더 필드가 포함된 경우 GET 메서드의 의미가 "조건부 GET"으로 변경됩니다. 조건부 GET 메서드는 섹션 10.9에 설명된 대로 If-Modified-Since 헤더에 의해 제공된 날짜 이후 수정된 경우에만 식별된 리소스가 전송되도록 요청합니다. 조건부 GET 방법은 여러 요청을 요구하거나 불필요한 데이터를 전송하지 않고도 캐시된 엔터티를 새로 고칠 수 있도록 하여 네트워크 사용량을 줄이기 위한 것입니다.

HEAD 메소드는 서버가 응답에 Entity-Body를 반환해서는 안 된다는 점을 제외하면 GET과 동일합니다. HEAD 요청에 대한 응답으로 HTTP 헤더에 포함된 메타정보는 GET 요청에 대한 응답으로 전송된 정보와 동일해야 합니다. 이 방법은 Entity-Body 자체를 전송하지 않고 Request-URI에 의해 식별된 자원에 대한 메타정보를 얻는 데 사용될 수 있습니다. 이 방법은 하이퍼텍스트 링크의 유효성, 접근성 및 최근 수정 사항을 테스트하는 데 자주 사용됩니다.

조건부 GET과 유사한 "조건부 HEAD" 요청은 없습니다. If-Modified-Since 헤더 필드가 HEAD 요청에 포함된 경우 무시해야 합니다.

POST 메소드는 요청 라인의 Request-URI에 의해 식별되는 자원의 새로운 하위 항목으로 요청에 포함된 엔터티를 대상 서버가 수락하도록 요청하는 데 사용됩니다. POST는 다음 기능을 처리하는 균일한 방법을 허용하도록 설계되었습니다.

      o Annotation of existing resources;

      o Posting a message to a bulletin board, newsgroup, mailing list,
        or similar group of articles;

      o Providing a block of data, such as the result of submitting a
        form [3], to a data-handling process;

o 추가 작업을 통해 데이터베이스를 확장합니다.
POST 메서드에 의해 수행되는 실제 기능은 서버에 의해 결정되며 일반적으로 Request-URI에 따라 달라집니다. 게시된 엔터티는 파일이 이를 포함하는 디렉터리에 종속되고, 뉴스 기사가 게시된 뉴스 그룹에 종속되거나, 레코드가 데이터베이스에 종속되는 것과 같은 방식으로 해당 URI에 종속됩니다.

성공적인 POST에서는 엔터티가 원본 서버의 리소스로 생성되거나 향후 참조를 위해 액세스 가능하도록 요구되지 않습니다. 즉, POST 메서드로 수행된 작업으로 인해 URI로 식별할 수 있는 리소스가 생성되지 않을 수 있습니다. 이 경우 응답에 결과를 설명하는 엔터티가 포함되어 있는지 여부에 따라 200(정상) 또는 204(콘텐츠 없음)가 적절한 응답 상태입니다.

원본 서버에서 리소스가 생성된 경우 응답은 201(생성됨)이어야 하며 요청 상태를 설명하고 새 리소스를 참조하는 엔터티(가급적 "text/html" 유형)를 포함해야 합니다.

모든 HTTP/1.0 POST 요청에는 유효한 Content-Length가 필요합니다. HTTP/1.0 서버는 요청 메시지 내용의 길이를 확인할 수 없는 경우 400(잘못된 요청) 메시지로 응답해야 합니다.

애플리케이션은 서버가 향후 요청에 대해 동등한 응답을 반환할 것인지 알 수 없기 때문에 POST 요청에 대한 응답을 캐시해서는 안 됩니다.

Request Header Fields

  Request-Header = Authorization
  | From                     ;
  | If-Modified-Since        ;
  | Referer                  ;
  | User-Agent               ;

요청 헤더 필드를 사용하면 클라이언트는 요청 및 클라이언트 자체에 대한 추가 정보를 서버에 전달할 수 있습니다. 이러한 필드는 프로그래밍 언어 메소드(프로시저) 호출의 매개변수와 동일한 의미를 갖는 요청 수정자 역할을 합니다.

요청 헤더 필드 이름은 프로토콜 버전이 변경되는 경우에만 안정적으로 확장될 수 있습니다. 그러나 통신의 모든 당사자가 해당 헤더 필드를 요청 헤더 필드로 인식하는 경우 새롭거나 실험적인 헤더 필드에 요청 헤더 필드의 의미가 부여될 수 있습니다. 인식할 수 없는 헤더 필드는 Entity-Header 필드로 처리됩니다.

서버에 자신을 인증하려는 사용자 에이전트는 일반적으로 401 응답을 받은 후 반드시 그런 것은 아니지만 요청에 Authorization 요청 헤더 필드를 포함시켜 인증할 수 있습니다. Authorization 필드 값은 요청 중인 리소스 영역에 대한 사용자 에이전트의 인증 정보가 포함된 자격 증명으로 구성됩니다.

Status Code and Reason Phrase

Status-Code 요소는 요청을 이해하고 만족시키려는 시도의 3자리 정수 결과 코드입니다. Reason-Phrase는 상태 코드에 대한 간단한 텍스트 설명을 제공하기 위한 것입니다. Status-Code는 오토마타에서 사용하기 위한 것이고 Reason-Phrase는 인간 사용자를 위한 것입니다. 클라이언트는 이유 문구를 검사하거나 표시할 필요가 없습니다.

상태 코드의 첫 번째 숫자는 응답 클래스를 정의합니다. 마지막 두 자리에는 분류 역할이 없습니다. 첫 번째 숫자에는 5개의 값이 있습니다.

o 1xx: 정보용 - 사용되지 않지만 향후 사용을 위해 예약되어 있습니다.

o 2xx: 성공 - 작업이 성공적으로 수신되었습니다.

o 3xx: 리디렉션 - 요청을 완료하려면 추가 조치를 취해야 합니다.

o 4xx: 클라이언트 오류 - 요청에 잘못된 구문이 포함되어 있거나 이행할 수 없습니다.

o 5xx: 서버 오류 - 서버가 명백히 유효한 요청을 이행하지 못했습니다.