HTTP 1.0

https://tools.ietf.org/html/draft-ietf-http-v10-spec-04 문서를 읽고 정리해보았습니다.
한글 번역본 http://www.deadfire.net/web/HTTP10.htm

1. Introduction 소개

1.1 Purpose 목적

HTTP 프로토콜은 SMTP, NNTP, FTP, Gopher, WAIS와 같은 애플리케이션 계층의 프로토콜입니다. 

브라우저와 프록시 혹은 게이트웨이 사이의 통신을 위한 프로토콜입니다.

요청에 목적을 나타내기 위해서 URI를 바탕으로 만들어집니다.

 

1.2 Terminology 용어

HTTP 통신에 요청자와 응답자가 수행하는 기능을 지칭하기 위해서 사용하는 용어를 설명합니다.

1. connection 연결
   두 개의 어플리케이션 프로그램의 통신을 목적으로 전송 계층의 가상 회선 연결.
2. message 메세지
   HTTP 통신의 기초적인 단위로, 연결을 통해서 전송될 구조화된 데이터 나열.
3. request 요청
   HTTP 요청 message
4. response 응답
   HTTP 응답 message
5. resource 자원
   URI에 의해 식별 가능한 서비스 혹은 네트워크 데이터 객체
6. entity 엔티티
   요청 또는 응답 메시지에 포함된 데이터 자원의 특정 표현, 서비스 자원의 응답.
   엔티티는 메타 데이터를 가진 헤더와 콘텐츠를 가진 바디로 구성.
7. client 클라이언트
   연결을 맺기 위한 요청을 전송하는 프로그램.
8. user agent 유저 에이전트
   요청을 시작하는 클라이언트.
   브라우저, 에디터, spiders(web-traversing robots), 다른 도구들
9. server 서버
   요청에 응답을 전송하여 연결을 승인하는 프로그램.
10. origin server 오리진 서버
    자원이 저장되어 있거나 생성될 서버.
11. proxy 프록시
    다른 클라이언트를 대신하여 요청하는 목적으로 서버와 클라이언트 역할을 모두 수행하는 중간 프로그램.
12. gateway 게이트웨이
    다른 서버의 중개자 역할을 하는 서버.
    프록시와 달리 게이트웨이는 요청된 자원의 오리진 서버인 것처럼 요청을 수신하며, 클라이언트는 게이트웨이인지 서버인지 모릅니다.
13. tunnel 터널
    터널은 두 연결 사이의 중계 역할을 하는 중간 프로그램.
    양쪽 끝이 닫히면 터널이 닫힌다. 터널은 포털이 필요하고 중계된 통신을 중간자가 해설할 수 없거나 해석해서는 안될 때 사용됩니다.
14. cache 캐시
    캐시는 응답 메시지의 저장하는 서브시스템.
    대응 시간과 네트워크 대역폭 소비를 줄이기 위해 저장할 수 있는 응답을 저장.

위의 용어들은 특정한 연결을 위해 프로그램에서 수행되는 역할들에 따라 달라질 수 있습니다. 마찬가지로, 모든 서버는 원본 서버, 프록시, 게이트웨이 또는 터널 역할을 할 수 있습니다.

 

1.3 Overall Operation 종합적인 동작 과정

HTTP 프로토콜은 request/response  패러다임을 기반으로 합니다.

클라이언트는 헤더에 request method, URI, 프로토콜 버전 바디에는 요청 수정자, 클라이언트 정보, 전송 가능한 본문 내용이 포함된 MIME과 같은 메시지를 전송합니다.

 

서버는 헤더에 상태 코드와 프로토콜 버전 바디에는 서버 정보, 엔티티 메타 데이터,  전송 가능한 본문 내용을 포함하는 MIME과 같은 메시지를 전송합니다.

 

대부분의 HTTP 통신은 유저 에이전트가 오리진 서버의 리소스를 요청하면서 시작합니다.

 

가장 간단한 케이스입니다.

v - connection, UA - User Agent, O - Origin Server

     request chain ------------------------->

UA -------------------v---------------------- O

     <----------------------- response chain

요청/응답 체인에 하나 이상의 중개자가 있을 경우 더 복잡한 상황이 발생합니다.
중개자는 proxy, gateway, tunnel이 있습니다.
프록시는 forwarding agent로 요청 메시지의 전부 혹은 일부를 다시 쓰고 서버로 전송합니다. 게이트웨이는 receiving agent로 서버 앞에서 동작합니다. 필요시 요청을 서버 프로토콜에 맞게 번역하는 기능을 수행합니다. 터널은 메시지의 변경 없이 서로 다른 연결을 연결하는 기능을 합니다. 대신 유효한 요청인지 검증과 같은 기능을 수행할 수 있습니다. (ex. firewall)

     request chain -------------------------------------->

UA -----v----- A -----v----- B -----v----- C -----v----- O

     <------------------------------------- response chain

위의 그림에서 유저 에이전트와 오리진 서버 사이에 A, B, C 3개의 중개자가 있습니다. 
전체 체인을 이동하는 요청과 응답은 4개의 별도 연결을 통과해야 합니다.
일부 HTTP 통신은 오리진 서버가 아닌 가장 가까운 비 터널 인접 네트워크와의 연결만으로 응답이 될 수 있기 때문에 구별이 중요합니다. 아래와 같이 캐시를 이용하여 응답할 수 있습니다.

 

캐시의 효과는 체인을 따라 참여하는 참가자 중 한 명이 해당 요청에 적용할 수 있는 캐시된 응답을 가질 경우 요청/응답 체인이 단축되는 것입니다.  아래의 그림은 UA와 A는 캐시되지 않은 요청에 B는 캐시가 되어있어서 캐시된 응답을 전송하는 경우입니다.

     request chain ---------->

UA -----v----- A -----v----- B - - - - - - C - - - - - - O

     <--------- response chain
모든 응답을 캐시할 수는 없습니다.

 

HTTP/1.0에서는 클라이언트가 각 요청 전에 연결을 설정하고 서버가 응답이후 연결을 닫아야합니다.

 

2. Notational Conventions and Generic Grammar (어휘분석에 관한 것 PASS)

 

3. Protocol Parameters 프로토콜 인자들

3.1 HTTP Version 

HTTP/<major>.<minor> 형태로 구성됩니다. 

<minor>버전은 프로토콜의 변경사항이 일반 메시지 구문 분서거 알고리즘을 변경하지 않지만 메시지 의미에 추가되거나 발신인의 추가 기능을 암시할 수 있는 기능이 추가되면 번호가 증가합니다.

<major>버전은 프로토콜 내의 메시지 형식이 변경되면 번호가 증가합니다.

3.2 Uniform Resource Identifiers

HTTP에 관해서 URI는 이름, 위치 또는 다른 특성을 통해 네트워크 리소스를 식별하는 문자열입니다.

3.3 Date/Time Formats

HTTP/1.0은 3가지 형태로 date/time stamps를 저장합니다.

• 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

첫 번째 형식은 인터넷 표준으로 선호됩니다. 

두 번째 형식도 일반적으로 사용되지만 옛날 버전의 RFC 850 날짜 형식을 기반으로 하며, 연도가 2자리입니다.

HTTP/1.0 date/time stamps는 예외없이 GMT이라는 Universal Time으로 표시되어야합니다.

3.4 Character Sets

Character Sets은 데이터를 문자로 변환하는데 사용되는 방법을 참조하기 위한 것입니다.

 

3.5 Content Codings

Content Codings은 리소스에 적용된 인코딩 변환을 나타내는 데 사용됩니다. 

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

x-gzip
파일 압축 프로그램 gzip에서 생성된 인코딩 형식입니다. 

x-compress

파일 압축 프로그램 compress에서 생성된 인코딩 형식입니다.

3.6 Media Types

HTTP는 미디어 타입을 Content-Type header field로 사용합니다. 미디어 타입을 IANA에 등록하여 전송되는 데이터가 어떠한 구조로 되어있는지 어떻게 처리해야 하는지 알 수 있습니다. 

3.7 Product Tokens

통신 응용 프로그램이 단순한 제품 토큰을 통해 자신을 식별할 수 있도록 하는데 사용됩니다.

 

4 HTTP message

4.1 Message Types

HTTP 메시지는 요청과 응답으로 구성됩니다.

HTTP-message = Simple-Request       ; HTTP/0.9 messages
                     | Simple-Response
                     | Full-Request            ; HTTP/1.0 messages
                     | Full-Response

HTTP/1.0의 요청과 응답은 다음과 같이 구성됩니다.

Full-Request = Request-Line ;             
                  *( General-Header ;        
                  | Request-Header ;          
                  | Entity-Header ) ;            
                  CRLF
                  [ Entity-Body ] ;               
Full-Response = Status-Line ;                
                   *( General-Header ;         
                   | Response-Header ;
                   | Entity-Header ) ; 
                   CRLF
                   [ Entity-Body ] ; 

4.2 Message Headers

HTTP 헤더는 General-Header, Request-Header, Response-Header, Entity-Header가 있습니다. 

순서는 General-Header , Request/Response-Header, Entity-Header 순으로 작성된다.

 

Header 필드에 여러 값이 들어가는 경우 쉼표로 구분합니다. 

4.3 General Header Fields

General Header Fields는 요청과 응답 모두에 적용되지만 body에서 최종적으로 데이터와 관련이 없는 헤더.

종류로는 Date, Cache-Control, Connection, MIME-Version, Pragma 등의 헤더가 있습니다. 

 

5 Request

요청 메시지의 가장 첫 줄에 자원에 적용되는 처리방법, 자원의 식별자, 프로토콜 버전으로 구성됩니다.

HTTP/0.9 하위 호환성 때문에 Simple-Request, Full-Request 두가지 형태를 가지고 있습니다.

5.1 Request-Line

요청의 첫줄로 다음과 같이 구성됩니다.

Request-Line = Method SP Request-URI SP HTTP-Version CRLF

5.2 Request Header Fields

클라이언트에 대한 정보를 전달하는데 사용합니다.

종류는 Authorization, From, If-Modified-Since, Referer, User-Agent가 있습니다.

 

6. Response

요청 메시지를 수신하고 해석한 후에 서버는 HTTP 응답 메시지 형식으로 응답합니다.

요청과 마찬가지로 하위 호환성 때문에 Simple-Response, Full-Response 두가지 형태를 가지고 있습니다. 

6.1 Status-Line

 Status-Line은 Full-Response 메시지의 첫 줄로 다음과 같이 구성됩니다.

 Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

HTTP/0.9에서는 바로 entity body를 응답받다 보니 메시지를 잘못 해석하는 경우가 있었습니다.

6.1.1 Status Code and Reason Phrase

• 1xx : Informational - 잘 사용되지 않습니다. 하지만 미래에 사용될 것을 위해 예약되었습니다.
• 2xx : Success - 성공적으로 응답을 받거나, 이해했거나 승인할 때 사용합니다.
• 3xx : Redirection - 요청의 완료하기 위해서 다음의 행동으로 이어질때 사용합니다.
• 4xx : Client Error - 요청에 잘못된 구문이나 충분하지 않을 때 사용합니다.
• 5xx : Server Error - 유효한 응답에 적절히 응답을 하지 못할 때 사용합니다.

6.2 Response Header Fields

서버에 대한 추가적인 정보를 전송할 때 사용합니다. entity-body에 대한 정보가 아닙니다.

종류는 Location, Server, WWW-Authenticate 등 이 있습니다. 

 

7. Entity

Full-Request/Response 메시지는 일부 요청 및 응답안에서 entity를 전송할 수 있습니다.

Entity는 Entity-Header fields와 Entity-Body로 구성됩니다.

7.1 Entity Header Fields

Entity Header Fields는 Entity-Body 혹은 Entity-Body가 없을 때 요청에 의해서 식별된 자원에 대한 선택적인 메타 정보를 정의합니다. 종류로는 Allow, Content-Encoding, Content-Length, Content-Type, Expires, Last-Modified 등 이 있습니다. 알려지지 않은 헤더는 포워드 프록시나 수신자에 의해서 무시될 수 있습니다.

7.2 Entity Body

Entity Body는 HTTP/1.0 요청과 응답과 함께 전송됩니다.

Entity Body를 포함하는 메시지인 경우 Content-Length  헤더를 가지고 있습니다. 
특정한 메시지인 경우에는 Entity Body를 포함하지 않는데 먼저 HEAD 메소드의 요청과, 모든 1xx 상태 응답, 204 (no content) 상태 응답, 304 (not modified) 상태 응답인 경우입니다. 또한 다른 모든 응답들은 Entity body를 포함 해야하며, Content-Length 값으로 0인 경우에 Entity-Body를 포함하지 않을 수 있습니다. 

7.2.1 Type

Entity Body는 다음과 같이 구성됩니다.

entity-body := Content-Encoding( Content-Type( data ) )

Content-Type은 전송하고자 하는 데이터의 미디어 타입을 나타냅니다.
Content-Encoding은 전송하고자 하는 데이터의 압축 인코딩 방식입니다.

7.2.2 Length

Entity-Body를 메시지에 포함할 때 length가 결정되는 방식이 2가지가 있습니다. 첫 번째는 Content-Length 헤더이고 두 번째는 서버가 연결을 닫으면서 body length를 결정하는 것입니다. 하지만 연결이 닫히면 메시지를 전송하지 못하므로 첫 번째 방법만 사용됩니다. 만약 length를 인식할 수 없는 경우에는 서버는 400 (Bad Request) 응답을 합니다.

 

8. Method Definitions

8.1 GET

GET 메소드는 URI로 식별되는 정보를 검색하는 것을 의미합니다. 만약 URI가 데이터 생성 프로세스를 참조하는 경우에는 해당 프로세스의 데이터 원본이 아닌 생성혹은 가공된 데이터를 응답받습니다.

 

요청 헤더에 If-Modified-Since 가 포함된 경우에는 "조건부 GET"이라고 합니다. 
조건부 GET은 If-Modified_Since 헤더가 제공한 날짜 이후에는 데이터가 수정된 경우에만 해당 리소스를 전송되도록 합니다. 이것은 (cache되어) 불필요한 데이터를 전송하지 않고 사용할수 있도록 해주며, 네트워크 사용을 줄일 수 있습니다. 

8.2 HEAD

HEAD 메소드는 서버가 Entity-Body를 반환하지않는 것을 제외하고는 GET과 동일합니다. URI로 식별되는 자원의 메타 데이터를 얻을 때 사용합니다. ( 자원은 전송되지 않습니다.) "조건부 GET"과 유사한 "조건부 HEAD" 요청은 없습니다. Entity-body가 없으니까요 ㅎㅎ 만약 If-Modified-Since 헤더를 가진 HEAD 요청이라면 서버에서 무시됩니다.

8.3 POST

POST 메소드 요청 메시지는 메시지의 Entity Body에 포함되어 있는 자원을 URI에 지정되어 있는 대로 서버에서 처리해달라고 할 때 쓰입니다. POST는 다음과 같은 기능을 수행하기 위한 한 가지 방법으로 설계되었습니다.

• 기존 문서에 주석을 붙이는 경우
• BBS 게시판, 메일링 리스트, 뉴스 그룹, 또는 글 모음 장소 등에 글을 올릴 때
• 어떤 프로그램의 실행을 위해 form과 같은 특정 규격의 데이터를 전송할 때
• 부가적인 동작을 통해 데이터베이스를 확장하고자 할 때

POST 요청에 대한 응답은 cache할 수 없습니다. 왜냐하면 서버가 추후의 요구 메시지에 대한 응답으로 똑같은 응답을 할지 알 수 없기 때문입니다.

 

9. Status Code Definitions

9.1 Informational 1xx

해당 상태 코드는 임시적인 응답을 의미합니다. HTTP/1.0은 아직 어떠한 1xx 상태코드에 대해서 정의하지 않았습니다. 

9.2 Sucessful 2xx

클라이언트의 요청이 성공적으로 응답 받았을 때 사용하는 상태코드입니다.

200 OK

요청이 성공했습니다. 응답과 함께 반환되는 정보는 다음과 같이 요청에 사용된 방법에 따라 달라집니다.

• GET 요청한 자원이 응답으로 전송받습니다.
• HEAD 자원 외에 자원에 해당하는 메타 정보인 헤더만 응답으로 전송받습니다.
• POST 동작의 결과 혹은 결과를 설명하는 데이터를 전송받습니다.

201 Created

요청으로 인하여 새로운 자원이 생성되었을 때 사용하는 상태코드입니다. 새로 생성된 자원은 응답으로 전송받은 URI로 참조할 수 있습니다. 오직 POST 메소드 요청인 경우에만 사용됩니다.

202 Accepted

요청으로 승인되었지만 아직 처리가 완료되지 않았을 경우에 사용합니다. 

204 No Content

서버가 요청을 완료했지만 다시 전송할 데이터가 없을 때 사용합니다. 

9.3 Redirection 3xx

이 상태 코드는 해당 요구를 수행하기 위해서 사용자 에이전트에서 수행되어야하는 추가 동작이 있을 때 사용합니다.

GET, HEAD인 경우에만 수행됩니다. 추가로 일반적으로 무한 루프가 될 수 있기 때문에 5회 이상 요청은 자동으로 리디렉션해서는 안되니다.

300 Multiple Choices

이 상태 코드는 HTTP/1.0에서 직접 사용되지 않지만 3xx 상태코드를 해석하는 기본으로 활용됩니다. 

요청받은 자원이 하나 또는 그 이상의 장소에서 사용 가능할 수 있습니다. 

301 Moved Permanently

이 상태 코드는 요청한 자원이 새로운 URL에 할당되어 활용되는 경우 사용됩니다. 이 새로운 URL은 응답 메시지의 Location 헤더 필드로부터 전달됩니다. 또한, HEAD 요청이 아닌 경우 새 URL에 대한 하이퍼링크가 포함된 짦은 메모가 포함되어야 합니다. 

302 Moved Temporarily

이 상태 코드는 요청한 자원이 다른 URL로 임시할당 되어 있는 경우 사용합니다. 301과 마찬가지로 Location 헤더에서 url을 얻을 수 있으며 HEAD요청이 아닌경우 entity body에 새 하이퍼링크에 대한 정보가 있어야 합니다.

304 Not Modified

만약 클라이언트가 "조건부 GET" 요청을 하였을 때 자원의 수정이 없었다면 서버는 entity-body를 전송하지않고 해당 상태 코드를 사용합니다. 

9.4 Client Error 4xx

클라이언트에 의해 생긴 오류 상황들에 대해 사용하는 상태코드입니다.

400 Bad Request

이 상태코드는 서버가 요청을 이해할 수 없을때 사용하는 사용합니다.

401 Unauthorized

요구 메시지가 처리되기 위해 사용자 인증이 필요할 때가 있습니다. 이 경우에는 요청된 자원에 대해 적용되는 challenge를 포함시켜 서버가 WWW-Authenticate 헤더 필드를 응답 메시지에 실어서 보낸다. 클라이언트는 적절한 Authorization 헤더 필드와 함께 요구 메시지를 다시 보낸다. 요구 메시지가 이미 Authorization credentials를 갖고 있다면, 이때의 401 응답은 해당 credentials에 대해 인증이 거절되었다는 것을 의미한다. 

403 Forbidden

이 상태 코드는 서버가 요청 메시지를 이해했지만 수행을 거절할 때 사용합니다.

404 Not Found

이 상태 코드는 요청메시지의 URI에 해당하는 자원이 없을 때 사용합니다.

9.5 Server Error 5xx

서버에서 일어난 오류상황이나 요구 사항을 처리할 수 없을 때 사용하는 상태코드입니다.

500 Internal Server Error

서버가 요청된 요구의 처리를 불가능하게 하는 예기치 못한 상황을 만났을 때 보내는 상태코드입니다.

501 Not Implemented

이 상태코드는 서버가 요청된 요구에 대한 처리 기능을 지원할 수 없을 때 사용합니다. 서버가 이해할 수 없는 요청 메소드를 받았을 때나 어떤 자원에 대해서 적용할 수 없을때 적절한 응답이 됩니다.

502 Bad Gateway

서버가 게이트웨이나 프록시로서 동작하고 있는 동안에 요구를 수행하도록 하기 위해 통과해가능 경로에 있어 다음 서버로부터 부적절한 응답을 받은 경우에 사용되는 것입니다.

503 Service Unavailable

서버가 일시적인 과부하나 서버 관리의 문제 때문에 지금 현재에 해당 요구를 처리할 수 없을 때 사용합니다. 약간의 시간 지연 후에는 다시 처리할 수 있는 일시적 상황이란 의미입니다.

 

10. Header Field Definitions

10.1 Allow (응답 헤더)

URI에 의해 지정되는 대상의 지원하는 methods들을 나열합니다. 

Allow: GET, HEAD

10.2 Authorization

브라우저가 서버에게 서비스 요청을 할 때 자신의 신분을 밝히고 인정받는 동작을 위해 사용됩니다.
다음과 같이 구성됩니다.

Authorization = "Authorization" ":" credentials
    credentials         = basic-credentials | (auth-scheme #auth-param)
    basic-credentials = "Basic" SP basic-cookie
    basic-cookie       = &lt;base64 encoding of userid-password, except
                              not limited to 76 char/line&gt;
    userid-password  = [token] ":" *TEXT
    auth-scheme       = token
    auth-param        = token "=" quoted-string
    quoted-string     = (&lt;"&gt; *(qdtext) &lt;"&gt;)
    qdtext               = &lt;any CHAR except &lt;"&gt; and CTLs, but including LWS&gt;

10.3 Content-Encoding

전송하는 데이터의 인코딩 방식에 대한 값을 필드로 가집니다.

Content-Encoding = "Content-Encoding" ":" content-coding
Content-Encoding: x-gzip

10.4 Content-Length

Entity-Body의 크기를 바이트 단위로 표시하여 수신측에 알려주는 용도로 사용됩니다.

Content-Length = "Content-Length" ":" 1*DIGIT
Content-Length: 3495

10.5 Content-Type

Entity-Body의 데이터 형식을 표시하는데 사용합니다.

Content-Type = "Content-Type" ":" media-type
Content-Type: text/html

10.6 Date

메시지가 만들어지는 날짜와 시간을 나타낼 때 쓰입니다.

Date = "Date" ":" HTTP-date
Date: Tue, 15 Nov 1994 08:12:31 GMT

10.7 Expires

Entity 헤더의 Expires 필드는 전달하는 데이타를 의미없는 대상으로 간주하는 시기를 표시합니다. Date 헤더 필드에 의해 지정된 것보다 앞선 날짜거나 같은 날짜라면 해당 데이터를 캐시해서는 안된니다.

Expires = "Expires" ":" HTTP-date
Expires: Thu, 01 Dec 1994 16:00:00 GMT

10.8 From (요청 헤더)

브라우저를 사용하여 요청 메시지를 보낸 사용자의 E - mail 주소가 들어갑니다. 이 정보는 클라이언트에서 사용자의 동의 하에 전달되어야합니다. 

From = "From" ":" mailbox
From: qkim@pec.etri.re.kr

10.9 If-Modifed-Since

요구 메시지의 If-Modiied-Since 헤더 필드는 8.1의 설명에서와 같이 GET method와 함께 조건부 동작으로 활용됩니다. 즉, 브라우저가 요구하는 문서에 대해 서버는 이 필드에 지정되어 있는 시각 이후에 수정된 화일만 제공합니다. 지정 시각 이후에 변경되지 않아서 해당 문서를 전달하지 않을 경우에는 Entity-Body 없이 304 (not modified) 응답만 보냅니다.

If-Modified-Since = "If-Modified-Since" ":" HTTP-date
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT

조건부 GET method는 지정된 자원이 If-Modified-Since 헤더에 의해 주어진 날짜 이후에 수정된 경우에만 전달하도록 하는 것이다. 이것을 결정하는 알고리즘은 다음의 경우들을 포함한다.

1. 만약 조건부 GET 요구가 200 (ok)가 아닌 다른 어느 상태를 유발하거나 전달된 If-Modified-Since 날짜가 부적절한 것이라면 응답은 일반적인 GET의 기능과 똑같이 처리되어야 한다. 서버의 현재 시각 및 날짜보다 늦는 경우에는 부적절한 것이다.
2. 자원이 If-Modified-Since 날짜 이후로 수정되었다면 응답은 일반적인 GET에서의 경우와 똑같이 처리되어야 한다.
3. 자원이 If-Modified-Since 날짜 이후로 수정되지 않았다면 서버는 304 (not modified) 응답을 돌려준다.

10.10 Last-Modified

전송측에서 이 문서의 마지막 작업 일자와 시간을 알려주는 용도로 사용합니다. 

Last-Modified = "Last-Modified" ":" HTTP-date
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT

10.11 Location

응답 메시지의 Location 헤더 필드는 URI에 의해 지정되어 있는 대상체의 정확한 위치를 표시합니다. 클라이언트가 원하는 자원의 URI가 다른 장소로 Redirection 되어 있을 때 새로운 URI를 전달하는 용도로도 사용됩니다.

Location = "Location" ":" absoluteURI
Location: http://www.w3.org/hypertext/WWW/NewLocation.html

10.12 MIME-Version

HTTP는 MIME 호환 프로토콜이 아닙니다. 그러나 HTTP/1.0 메시지에는 메세지 구성에 사용한 MIME 프로토콜을 나태내는 단일 MIME-Version을 포함할 수 있습니다. 

MIME-Version = "MIME-Version" ":" 1*DIGIT "." 1*DIGIT

10.13 Pragma

General Header의 Pragma 필드는 요구/응답의 연쇄 동작에 따라 어느 수신측에 적용되는 변수로서 구현에 관련된 것들을 포함하는 데 쓰입니다.

Pragma              = "Pragma" ":" 1#pragma-directive
pragma-directive  = "no-cache" | extension-pragma
extension-pragma = token ["=" word]

만약 "no-cache" 변수가 요구 메시지에 포함되어있다면 해당 자원이 캐시되어 있을지라도 다시 서버로 요구 메시지를 전달해야 합니다.

10.14 Referer

요구 메시지의 Referer 헤더 필드는 서버를 위해 사용하는 것인데, 클라이언트가 요청한 URI 정보를 얻게된 원래 문서의 주소를 나타낼 때 사용합니다. 

Referer = "Referer" ":" ( absoluteURI | relativeURI )
Referer: http://www.w3.org/hypertext/DataSources/Overview.html

10.15 Server

응답 메시지의 Server 헤더 필드는 요구 메시지를 처리하기 위해 서버가 사용하는 프로그램에 대한 정보를 담고 있습니다.

Server = "Server" ":" 1*( product | comment )
Server: CERN/3.0 libwww/2.17

10.16 User-Agent

요구 메시지의 User-Agent 필드는 사용자가 요구 메시지를 생성시키는 브라우저에 대한 정보를 나타냅니다.

User-Agent = "User-Agent" ":" 1*( product | comment )
User-Agent: CERN-LineMode/2.15 libwww/2.17b3

10.17 WWW-Authenticate

사용자의 요구 메시지에 지정되어 있는 정보가 보안이 필요로 하는 것이라면 서버는 서비스를 제공해주기 위해 사용자의 인증을 요구하는 것입니다. 그러므로 서버는 WWW-Authenticate 필드를 포함시켜 응답 메시지를 브라우저에게 전달하도록 합니다. 이러한 WWW-Authenticate 헤더 필드는 401 (unauthorized) 응답 메시지에는 반드시 포함되어야 합니다.

WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge

 

11. Access Authentication