teklog

☼

HTTP 완벽 가이드 - 3 HTTP 메시지

2024/03/11

n°53

category : HTTP

img

지난 글에서 HTTP는 메시지를 기반으로 통신한다고 하였다. 메시지는 오직 요청/응답 두가지만 있으며, 머리-가슴-배 시작줄-헤더-본문으로 구성되는 것또한 살펴봤다. 요청, 응답은 시작줄에 각기 다른 내용을 갖는 다는 것 또한 확인했다.


이제 메시지의 구성 요소들과 각 요소들의 옵션들을 상세히 정리해볼 차례이다. 한번 쯤은 정리하고 넘어가도 좋을 내용이라 궁금한 건 더 찾아보면서 작성했다.


메시지의 흐름


  • HTTP 메시지는 HTTP 애플리케이션 간에 주고받은 데이터의 블록들이다
  • 클라이언트, 서버, 프록시 사이를 흐른다
  • 인바운드, 아웃바운드, 업스트림, 다운스트림은 메시지의 방향을 표현한다.
  • 인바운드: 원서버 방향으로 향하는 메시지 (서버 방향)
  • 아웃바운드: 메시지가 사용자로 돌아오는 메시지 (사용자 에이전트 방향)
  • 모든 HTTP 메시지는 다운스트림으로 흐른다.
  • 요청과 응답의 벌송자가 업스트림이고, 다운스트림은 목적지이다.


메시지의 각 부분


HTTP 메시지는 데이터의 구조화된 블록. 앞서 살펴본 대로, 시작줄, 헤더, 본문으로 구성된다.


  • 시작줄: 이것이 어떤 메시지인지 서술
  • 헤더: 속성
  • 본문: 데이터. 텍스트나 이진 데이터를 표현할 수 있다. 혹은 아예 생략될 수도 있다.


시작줄과 헤더는 아스키 문자 줄단위로 분리됨. 이 줄바꿈 문자를 CRLF라고 부른다.


메시지 문법


모든 HTTP 메시지는 요청 / 응답 메시지이다. 요청 메시지는 서버에 요청을, 응답은 요청의 결과를 클라이언트로 돌려준다.


요청 메시지의 형식:

<메서드><요청 URL><HTTP 버전> - 시작줄 = 요청줄
<헤더>
<엔터티 본문>

응답 메시지의 형식:

<HTTP 버전><상태 코드><사유 구절> - 시작줄 = 응답줄
<헤더>
<엔터티 본문>
  • 요청줄, 응답줄 : 시작줄의 요소들은 띄어쓰기로 구분된다.
  • 메서드: 서버에 어떤 동작이 일어나야 하는지 설명해준다.
  • 요청 URL: 클라이언트가 서버와 직접 대화하고 있고 경로 구성 요소가 리소스를 가리키는 절대 경로면 문제없다. 서버는 URL에서 생략된 호스트/포트가 자신을 가리키는 것으로 간주한다.
  • 버전 : 이 메시지에서 사용 중인 HTTP의 버전이다. HTTP/<메이저>.<마이너> (메이저, 마이너 모두 정수다) 요청과 응답 양쪽 모두에 기술된다. 자신이 따르는 프로토콜의 번호를 상대에 알리기 위한 수단이다. HTTP 버전 1.1 애플리케이션과 대화하는 1.2 애플리케이션은 1.2 버전의 새로운 기능을 사용할 수 없다.
  • 상태코드: 요청 중 무엇이 일어났는지 설명하는 세 자리 숫자. 200~299까지 성공을 나타낸다.
  • 사유 구절: 상태코드의 의미를 사람이 이해할 수 있게 설명해주는 짧은 문구. 상태 코드 이후부터 줄바꿈 문자열까지 사유 구절이다. 오로지 사람에게만 읽힐 목적으로 작성되어, HTTP 1.1 200 NOT OK나 HTTP 1.1 200 OK나 동등하게 성공 상태 코드를 갖고 있어 성공을 의미하는 것으로 처리한다. HTTP 명세는 사유 구절에 대한 엄격한 규칙을 적용하지 않는다.


헤더

이름, 콜론, 선택적인 공백, 값, CRLF가 순서대로 나타나는 0개 이상의 헤더. 헤더 목록은 빈줄(CRLF)로 끝나 본문과 구분한다. HTTP 1.1같은 특정 버전에서는 특정한 헤더를 포함하여야만 유효한 것으로 간주한다. 요청과 응답 메시지에 추가 정보를 더한다. 기본적으로 이름/값 쌍의 목록이다.

Content-length:19


분류


  • 일반 헤더: 요청과 응답 양쪽에 모두 나타낼 수 있다.
  • 요청 헤더: 요청에 대한 부가 정보
  • 응답 헤더: 응답에 대한 부가 정보
  • Entity 헤더: 본문 크기, 콘텐츠 혹은 리소스 그자체를 서술
  • 확장 헤더: 명세에 정의되지 않은 새로운 해더


각 Http 헤더는 간단한 문법을 지닌다. 이름, 쉼표, 공백(없어도 됨), 필드 값, CRLF가 순서대로 나온다. 긴 헤더는 여러 줄로 쪼개서 보낼 수 있다.


엔터티 본문:

임의의 데이터 블록을 포함한다. 모든 메시지가 엔터티 본문을 갖는 것이 아니어서 빈줄(CRLF)로 끝날 때도 자주 있다. 헤더나 본문이 없더라도, HTTP 헤더의 집합은 항상 CRLF로 끝난다. HTTP의 화물이라고 할 수 있다. 이미지, 비디오, HTML 문서, 소프트웨어 애플리케이션, 메일 등 다양한 데이터를 실어 나를 수 있다.

이어서 요청 메시지의 메서드, 응답 메시지의 상태코드, 헤더에 대해서 자세히 알아보자.


메서드


서버는 모든 메서드에 구현하지 않을 수 있다. 메서드는 대부분 제한적으로 사용된다. DELETE, PUT 요청은 아무나 저장된 리소스를 삭제하거나 수정하지 못하게 제한 할 수 있다. 이러한 제한은 일반적으로 서버 설정에 의해 정해지며, 사이트마다 서버마다 다를 수 있다.


안전한 메서드 = 서버에 '작용’이 일어나지 않는 요청 메서드


HTTP는 안전한 메서드라 불리는 메서드의 집합을 정의한다. GET, HEAD 메서드는 HTTP 요청의 결과로 서버에 아무 작용도 없음을 의미한다. 작용이 없다는 뜻은 HTTP 요청의 결과로 서버에 일어나는 일은 아무것도 없다는 일이다. 즉 서버 상의 데이터에 변화가 없다는 말과 같다. 예를 들어 POST 메서드로 데이터를 저장하는 요청을 보낸다면, 서버에는 이에 해당하는 작용이 일어날 것이다. 안전한 메서드가 서버에 작용을 유발하지 않는 보장은 없다. 안전한 메서드의 목적은, 서버에 어떤 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자들에게 그 사실을 아려주는 애플리케이션을 만들 수 있도록 하는 것이다.


GET

  • 서버에 리소스를 달라고 요청할 때 사용
  • get 요청 body에 무언가를 담아 요청을 보낼 수는 있지만, 표준 HTTP 설계에선 벗어난 사용법이다.
  • 특정한 데이터를 얻기 위해 앞장에서 살펴본 쿼리(질의)를 사용하는 것이 일반적이다.
  • get 요청을 통해 얻은 내용은 캐시를 할 수 있다. 같은 요청에 대한 서버의 응답을 저장하고 사용할 수 있다.
  • HEAD
  • 정확히 GET처럼 행동하지만, 서버는 응답으로 헤더만을 돌려준다. 엔터티 본문(body)는 반환되지 않는다.
  • 이를 통해 리소스를 가져오지 않고 그에 대한 메타데이터(컨텐트 타입, 크기 등)를 얻을 수 있다.
  • 응답 사태 코드를 통해 개체가 존재하는지 확인할 수 있다.
  • 헤더를 통해 리소스가 변경 여부를 확인할 수 있다.


PUT

  • 서버에 리소스를 생성하거나 업데이트할 때 사용
  • PUT 요청은 지정된 URI에 리소스를 생성하거나, 이미 존재하는 리소스를 대체하기 위해 사용된다.
  • 요청의 본문에 데이터를 담아 전송하며, 서버는 이 데이터를 사용해 지정된 URI의 리소스를 생성하거나 업데이트한다.
  • POST와 차이점: PUT 요청은 멱등idempotent하다. 즉, 같은 데이터로 같은 요청을 여러 번 수행해도 최종 서버 상태에 동일한 영향을 미친다.
  • 그렇게 때문에 주로 이미 존재하는 리소스를 대체할 때 사용한다.


POST

  • 서버에 리소스를 생성하라는 요청을 할 때 사용
  • POST 요청은 서버에 데이터를 제출하여 새 리소스를 생성하거나, 기존 리소스에 대한 처리를 요청할 때 사용된다.
  • 요청의 본문에 데이터를 담아 전송하며, 서버는 이 데이터를 기반으로 새로운 리소스를 생성하거나, 요청에 따른 특정 작업을 수행한다.
  • 폼 데이터 제출, 메시지 전송, 파일 업로드 등 서버에 데이터를 제출하여 처리를 요청할 때 사용된다.
  • POST 요청은 non-idempotent하다. 같은 요청을 여러 번 수행할 경우, 요청의 효과는 요청마다 달라질 수 있다.
  • 같은 POST 요청을 여러 번 수행하면 서버에 여러 개의 리소스가 생성될 수 있으며, 각 요청이 서버 상태에 다르게 영향을 미칠 수 있다.


TRACE

  • 서버에 대한 진단을 위해 사용되는 메서드
  • 엔티티 본문을 전혀 사용하지 않는다.
  • TRACE 메서드는 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이는지 알려줌.
  • 목적지 서버에서 ‘루프백’ 진단을 시작한다.
  • TRACE 요청은 서버로 전송된 요청 메시지를 그대로 받은 후, 응답 본문에 이 메시지를 포함하여 클라이언트에게 돌려보낸다. 이를 통해 클라이언트는 중간에 있는 프록시 서버들이 요청을 어떻게 수정하거나 추가하는지 확인할 수 있다.
  • 주로 네트워크 진단, 디버깅, HTTP 통신이 중간 서버에 의해 변경되는 방식을 추적하는 데 사용된다. 예를 들면 요청이 의도한 요청/응답 연쇄를 거쳐가는지 검사할 수 있다.
  • 하지만 보통 요청의 메서드에 따라 HTTP 애플리케이션은 다르게 동작한다. 예를 들어 POST는 바로 서버로 요청을 보내는 반면, GET은 웹 케시와 같은 HTTP 애플리케이션으로 전송한다. TRACE는 메서드를 구별하는 메커니즘이 없기에 TRACE 요청을 어떻게 처리할지는 중간 애플리케이션에서 결정해야한다.
클라이언트 -> proxy -> 서버
요청 메시지 
TRACE /sample/... 
Accept: *      
-> 프록시 통과
TRACE /sample/... 
Accept: *   
Via: 1.1 proxy
-> 서버 도착
-> 서버 응답 메시지에 Via필드가 추가되어 클라이언트에 도착한다.


OPTIONS

  • OPTIONS 메서드는 웹 서버에 메서드 지원 범위를 물어본다.
  • 특정 리소스에 대해 어떤 메서드를 지원하는 지 물어볼 수 있다.
  • 응답은 Allow 헤더를 포함하고 있으며, 이는 해당 리소스에 대해 사용할 수 있는 HTTP 메서드들을 나열한다.
  • OPTIONS 요청은 서버의 구성과 지원 기능을 파악하는 데 유용하며, 리소스를 변경하지 않는 안전한 메서드로 분류된다.


DELETE

  • 서버에 지정된 리소스를 삭제하도록 요청
  • DELETE 요청의 처리는 서버의 구현에 따라 다르다.
  • HTTP 명세는 서버가 클라이언트에 알리지 않고 요청을 무시하는 것을 허락하기 때문이다.


확장 메서드

확장 메서드는 HTTP/1.1 명세에 정의되지 않은 메서드다. WebDAV HTTP 확장 메서드의 몇가지 예시이다.


  • LOCK: 사용자가 리소스를 잠글 수 있게 해준다. 예를 들어 사용자가 편집 중일 때 다른 사람이 같은 문서를 편집할 수 없게 해준다.
  • MKCOL: 사용자가 문서를 생성할 수 있게 해준다.
  • COPY: 서버에 있는 리소스를 복사한다.
  • MOVE: 서버에 있는 리소스를 옮긴다.


모든 확장 메서드가 형식을 갖춘 명세로 정의되지 않는다. 누군가 임의로 정의한 메서드는 대부분의 HTTP 애플리케이션이 이해할 수 없을 것이고, 반대로 내 HTTP 애플리케이션이 이해할 수 없는 확장 메서드를 사용하는 애플리케이션과 마주칠 수도 있다.


상태 코드


상태 코드는 클라이언트에게 각 트랜잭션을 이해할 수 있는 쉬운 방법을 제공한다.


상태코드는 번호대에 따라 크게 다섯가지로 나뉜다.


100-199: 정보성 상태코드

HTTP/1.1에서 도입되었다. 비교적 새로운 코드들이다.


  • 100 Continue: 요청의 시작 부분 일부가 받아들여졌으며, 클라이언트는 나머지를 이어서 보내야 함을 의미. 이를 보낸 후 서버는 반드시 요청을 받아 응답해야한다.
  • 101 Switching Protocols: 클라이언트가 Upgrage 헤더에 나열한 것 중 하나로 서버가 프로토콜을 바꾸었음을 의미
  • 100 Continue와 클라이언트: 클라이언트에서 엔터티를 서버에 보내기 전에 100 응답을 기다린다면, Expect:100-contunue로 시작하는 요청 헤더를 보내야한다. 기다리지 않는 다면, 이 헤더를 보내지 않는다. 서버의 응답을 다시 기다리더라도, 약간의 타임아웃 이후 보내야한다.
  • 100 Continue와 서버: Expect:100-continue 요청 헤더를 받는다면, 에러코드 혹은 100 Continue 응답 둘 중 하나를 보내야한다. 만일 응답을 보내기 전에 클라이언트에서 엔터티의 일부(전체)를 받았다면 최종 응답을 보내야한다
  • .조건부 요청 헤더의 Expect 참조*


200-299: 성공 상태코드

성공한 요청에 대응하는 의미있는 상태 코드 배열이다. 각각 다른 종류의 요청에 대응한다.


  • 200 Ok: 요청은 정상이고 응답 body(엔터티 본문)에 요청한 리소스를 포함한다.
  • 201 Created: 서버 개체를 생성하는 요청의 성공 코드. 생성된 리소스에 대한 구체적인 참조가 담긴 Location 헤더와 그 리소스를 참조할 수 있는 여러 URL을 본문에 포함해야 한다. 서버는 201 상태 코드를 보내기 전에 반드시 객체를 생성해야 한다.
  • 202 Accepted: 요청은 받아들여졌으나 서버는 아직 그에 대한 어떤 동작도 수행하지 않았다. 서버가 요청의 처리를 완료할 것인지에 대한 어떤 보장도 없다.요청이 받아들이기에 적법해 보인다는 의미 뿐이다. 서버는 응답 엔터티 본문에 요청에 대한 상태, 요청 처리가 언제 완료될 것인지 추정도 포함하는 것이 좋다.
  • 203 Non-Authoritative Information: 엔터티 헤더에 들어있는 정보가 원래 서버가 아닌 리소스의 사본에서 왔다. 중개자(프록시)가 리소스 사본을 갖고 있지만 메타데이터를 검증하지 못한 경우 발생한다. 반드시 사용되어야할 코드는 아니다.
  • 204 No Content: 응답 메시지는 헤더, 상태줄을 포함하지만 body는 포함하지 않는다. 주로 브라우저를 새 문서로 이동시키지 않고 갱신하고자 할 때 사용했다.
  • 205 Reset Content: 주로 브라우저를 위해 사용되는 코드. 브라우저에게 현재 페이지에 있는 HTML 폼에 채워진 모든 값을 비우라고 한다. (요즘은 잘 안쓰일듯)
  • 206 Partial Content: 부분 혹은 범위 요청이 성공. Range 헤더 참조. 206 응답은 Content-Range와 Date 헤더를 반드시 포함. Etag, Content-Location 중 하나는 반드시 포함해야한다.


300-399: 리다이렉션 상태코드

클라이언트가 관심있어 하는 다른 리소스의 위치를 사용하라고 말해주거나, 그 리소스의 내용 대신 다른 대안 응답을 제공한다. 만약 리소스가 옮겨졌다면 옮겨진 리소스가 옮겨졌으며, 어디서 찾을 수 있는 지에 대한 정보를 줄 수 있다. 이는 브라우저가 자동으로 새 위치로 이동할 수 있게 해준다.

300번대의 몇몇 코드는 리소스의 로컬 복사본이 원서버와 비교해 유효한지 확인할 때 사용한다. 이를 통해 복사본이 여전히 최신인지 혹은 수정이 이루어졌는지 검사할 수 있다.


  • 300 Multiple Choices: 요청된 리소스가 여러 형태로 존재하며, 클라이언트가 선호하는 형태를 선택해야 하는 경우
  • 301 Moved Permanently: 요청된 리소스가 새로운 URI로 영구적으로 이동됐을 때. 클라이언트는 미래의 요청에서 새 URI를 사용.
  • 302 Found: 요청된 리소스가 일시적으로 다른 URI에 위치. 이 상태 코드는 리소스의 임시 이동을 나타냄.
  • 303 See Other: 요청에 대한 응답을 다른 URI에서 찾을 수 있으며, GET 메서드를 사용하여 리소스를 검색해야함
  • 304 Not Modified: 클라이언트가 조건부 GET 요청을 했고, 리소스가 마지막 요청 이후 변경되지 않았다면, 서버는 이 상태 코드를 사용하여 응답합니다. 이는 리소스의 로컬 복사본을 사용할 수 있음을 나타냄.
  • 307 Temporary Redirect: 요청된 리소스가 일시적으로 다른 URI에 위치해 있으며, 클라이언트는 미래의 요청에 대해 원래의 URI를 계속 사용해야함
  • 308 Permanent Redirect: 요청된 리소스가 새로운 URI로 영구적으로 이동되었으며, 클라이언트는 미래의 모든 요청에서 새 URI를 사용해야함


400-499: 클라이언트 에러 상태코드

클라이언트가 서버에서 다룰 수 없는 요청을 보내는 경우. 잘못 구성된 요청 메시지, 존재하지 않는 URL이나 접근 권한이 없는 요청 등이 있다. 많은 클라이언트는 브라우저에 의해 처리되나 404를 비롯한 몇몇은 서버로 전달된다.

  • 400 Bad Request: 일반적으로 잘못된 요청을 보냈음을 알린다.
  • 401 Unauthorized: 리소스를 얻기 전에 클라이언트에 인증을 하라고 요구하는 응답. 클라이언트는 요청에 인증 정보를 포함해야 한다.
  • 403 Forbidden: 서버가 요청을 이해했지만, 서버에 의해 거부할 때 사용. 보통 서버가 거절의 이유를 숨기고 싶을 때 사용한다.
  • 404 Not Found: 서버가 요청한 리소스를 찾을 수 없을 때.
  • 405 Method Not Allowed: URL에 대해 지원하지 않는 메서드로 요청했을 때 사용. 어떤 메서드가 가능한지 알려주기 위해 응답 헤더에 Allow를 포함한다.
  • 406 Not Acceptable: 요청된 리소스 중 받아들일 수 없는 것이 없는 경우 사용. 클라이언트의 Accept 헤더와 일치하지 않을 때 발생할 수 있다. 서버는 왜 요청이 만족될 수 없는지 알려주는 헤더를 포함시킬 수 있다.
  • 407 Proxy Authentication Required: 401과 동일하나 리소스에 대해 인증을 요구하는 프락시 서버를 위해 사용.
  • 408 Request TImeout: 클라이언트의 요청을 완수하기에 시간이 너무 많이 걸리는 경우, 서버는 이 상태 코드로 응답하고 연결을 끊을 수 있다.
  • 409 Conflict: 요청이 리소스에 대해 일으킬 수 있는 몇몇 충돌을 지칭하기 위해 사용. 서버는 충돌을 일으킬 염려가 있을 때 보낼 수 있음.
  • 410 Gone: 404와 비슷하나, 서버가 한 때 그 리소스를 갖고 있었다는 점이 다름.
  • 429 Too Many Requests: 클라이언트가 주어진 시간 동안 너무 많은 요청을 보낼 때.


500-599: 서버 에러 상태코드

클라이언트에서 올바른 요청을 보내도 서버 자체에서 에러가 발생하는 경우. 클라이언트가 서버의 제한에 걸리거나 게이트웨이 리소스와 같은 서버의 보조 구성요소에서 발생한 에러일 수도 있다.

  • 500 Internal Server Error: 서버에 문제가 있으며, 요청을 처리할 수 없을 때 사용.
  • 501 Not Implemented: 클라이언트가 서버의 능력을 넘은 요청을 했을 때. 예를 들어 서버가 요청 메서드를 지원하지 않을 때.
  • 502 Bad Gateway: 서버가 게이트웨이나 프록시 역할을 하며, 상위 서버로부터 유효하지 않은 응답을 받았을 때. (ex: 만약 자신의 부모 게이트웨이에 접속하는 것이 불가능할때.)
  • 503 Service Unavailable: 서버가 일시적으로 요청을 처리할 수 없을 때. 보통 유지 보수 또는 과부하 때문에 발생.
  • 504 Gateway Timeout: 409과 비슷하지만, 다른 서버에게 요청을 보내고 응답을 기다리다가 타임아웃이 발생할 떄. (ex:서버가 게이트웨이나 프록시 역할을 하며, 상위 서버로부터 시간 내에 응답을 받지 못했을 때.)
  • 505 HTTP Version Not Supported: 요청에 사용된 HTTP 프로토콜 버전이 지원하지 않을 때 사용. 몇몇 프로토콜은 서버가 오래된 버전을 지원하지 않도록 설정한다.


헤더


헤더와 메서드는 클라이언트와 서버가 무엇을 하는지 결정하기 위해 함께 사용됨. 앞서 살펴본 5가지 헤더의 분류를 살펴보자.


일반 헤더


요청과 응답 양쪽에 모두 사용한다. 일반적으로 기본적인 정보를 제공한다. Date는 요청/응답 모두 메시지가 생성된 일시라는 같은 의미를 갖기 때문에 양쪽 모두 동일한 헤더를 갖는 게 일반적이다.


  • Connection: 클라이언트와 서버가 요청/응답 연결에 대한 옵션을 정할 수 있게 해준다.
  • Date: 메시지가 언제 만들어졌는지 날짜와 시간을 제공
  • MIME-Version: 발송자가 사용한 MIME 버전
  • Trailer chunked transfer: 인코딩으로 인코딩된 메시지의 끝 부분에 위치한 헤더들의 목록을 나열
  • Transfer-Encoding: 수신자에게 안전한 전송을 위해 메시지에 어떤 인코딩이 적용되었는지 알림
  • Upgrade: 발송자가 '업그레이드’하길 원하는 새 버전이나 프로토콜을 알려줌.
  • Via: 어떤 중개자(프록시, 게이트웨이)를 거쳐 왔는지 보여줌.


일반 캐시 헤더


HTTP/1.0은 HTTP 애플리케이션에게 매번 원 서버로부터 객체를 가져오는 대신, 로컬 복사본으로 캐시할 수 있도록 해주는 최초의 헤더를 도입함. 최신 버전의 HTTP는 풍부한 캐시 매개변수 집합을 갖는다. 7장에서 자세히 살펴볼 예정.

  • Cache-Control: 메시지와 함께 캐시 지시자를 전달하기 위해 사용
  • Pragma: 메시지와 함께 지시자를 전달하는 또다른 방법. 캐시에 국한되지 않는다. (Cache-Control로 인해 deprecated될 예정이다.)


요청 헤더


요청 메시지를 위한 헤더다. 클라이언트가 받고자 하는 데이터 타입이 무엇인지와 같은 부가 정보를 제공. 예를 들어 Accept: * 가 있는 요청 헤더는, 해당 요청으로 어떠한 미디어 타입도 받아들일 것을 의미한다.

  • Client-IP: 클라이언트가 실행된 컴퓨터의 IP를 제공
  • From: 클라이언트 사용자의 메일 주소를 제공
  • Host: 요청의 대상이 되는 서버의 호스트명과 포트
  • Referer: 현재의 요청 URI가 들어있던 문서의 URL을 제공
  • User-Agent: 요청을 보낸 애플리케이션의 이름을 서버에 전달
  • UA-Color: 클라이언트 기기 디스플레이의 색상 능력 정보
  • UA-CPU: 클라이언트 CPU의 종류, 제조사 등의 정보
  • UA-Disp: 클라이언트 디스플레이 능력에 대한 정보
  • UA-OS: 클라이언트기기에서 동작 중인 운영체제의 이름과 버전
  • UA-Pixels: 클라이언트 디스플레이에 대한 픽셀 정보


Accept 관련 요청 헤더


클라이언트는 Accept 관련 헤더를 이용해 서버에 무엇을 원하고 할 수 있는지, 원치 않는지를 알릴 수 있다. 서버는 그후 이 정보를 활용해서 무엇을 보낼 지 더 나은 선택을 할 수 있다. Accept 관련 헤더는 양쪽에 모두 유익하다. 클라이언트는 원하는 리소스를 명확히 전달할 수 있고, 서버는 사용하지 않거나, 할 수 없는 것을 보내지 않아 시간과 대역폭 낭비를 막을 수 있다.


  • Accept: 서버에게 서버가 보내도 되는 미디어 종류를 전함
  • Accept-Charset: 서버에게 서버가 보내도 되는 문자집합을 전함
  • Accept-Encoding: 서버에게 서버가 보내도 되는 인코딩을 전함
  • Accept-Language: 서버에게 서버가 보내도 되는 언어를 전함
  • TE: 서버에게 서버가 보내도 되는 확장 선송 코딩을 전함


조건부 요청 헤더


헤더를 통해 요청에 제약을 추가할 수 있다. 조건부 요청 헤더를 사용해 서버에 요청에 응답하기 전에 먼저 조건이 참인지 확인하게 할 수 있다.

  • Expect: 클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 해준다. ex) Expect:100-continue. 이 헤더를 사용하여 클라이언트가 대용량 파일을 서버에 업로드할 때 추가한다. 실제로 데이터를 전송하기 전에 서버가 요청을 수락할 준비가 되었는지 확인한다. 서버가 요청을 처리할 준비가 되면 100 Continue를 전송한다. 아닌 경우 서버에서 에러 응답을 보내주도록 처리한다.
  • If-Match: 문서의 엔터티 태그가 주어진 엔터티 태그와 일치하는 경우에만 문서를 가져옴
  • If-None-Match: 반대로 문서의 엔터티 태그가 주어진 엔터티 태그와 일치하지 않는 경우에만 가져옴
  • If-Modified-Since: 주어진 날짜 이후 리소스가 변경되지 않았다면 요청을 제한
  • If-Unmodified-Since: 반대로 주어진 날짜 이후에 리소스가 변경되었다면 요청을 제한.
  • If-Range: 문서의 특정 범위에 대한 요청을 할 수 있게 해줌
  • Range: 서버가 범위 요청을 지원한다면, 리소스에 대한 특정 범위를 요청


*요청 보안 헤더


HTTP는 자체적으로 요청을 위한 간단한 인증요구/응답 체계를 갖고 있다.


  • Authorization: 클라이언트가 서버에 제공하는 인증 자체에 대한 정보
  • Cookie: 클라이언트가 서버에 토큰을 전달할 때 사용한다. 진짜 보안 헤더는 아니지만, 보안에 영향을 줄 수 있다.
  • Cookie2: 요청자가 지원하는 쿠키 버전을 알려줄 때 사용.


응답 헤더


응답 메시지를 위한 헤더. 클라이언트에 정보를 제공하기 위한 고유의 헤더를 갖고 있다. 예를 들어 Server 헤더는 클라이언트가 어떤 종류의 서버와 대화하고 있는지 설명을 제공한다.


  • Age: 응답이 얼마나 오래되었는지.
  • Public: 서버가 특정 리소스에 대해 지원하는 요청 메서드 목록
  • Retry-After: 현재 리소스가 사용 불가 상태일때, 언제 가능해지는지 날짜 혹은 시각
  • Server: 서버 애플리케이션의 이름과 버전
  • Title: HTML 문서에서 주어진 것과 같은 제목
  • Warning: 사유 구절에 있는 것보다 더 자세한 경고 메시지


협상 헤더


서버와 클라이언트가 최적의 응답을 선택하기 위한 협상을 지원한다. 추후 더 살펴볼 예정


  • Accept-Ranges: 서버가 자원에 대해 받아들일 수 있는 범위의 형태
  • Vary: 서버가 확인해 보아야 하기 때문에 응답에 영향을 줄 수 있는 헤더들의 목록. (ex: 서버가 클라이언트에게 보내줄 리소스의 가장 적절한 버전을 선택하기 위해 살펴보아야 하는 헤더들의 목록)


응답 보안 헤더


요청 보안 헤더와 마찬가지로 기본적인 인증요구 헤더를 살펴본다.


  • Proxy-Authenticate: 프록시에서 클라이언트로 보낸 인증요구의 모록
  • Set-Cookie: 진짜 보안 헤더는 아니지만 보안에 영향을 줄 수 있다. 서버가 클라이언트를 인증할 수 있도록 클라이언트 측에 토큰을 설정하기 위해 사용.
  • Set-Cookie2: Set-Cookie와 비슷하게 RFC 2965로 정의된 쿠키.
  • WWW-Authenticate: 서버에서 클라이언트로 보낸 인증 요구의 목록


엔터티 헤더

본문(body)에 대한 헤더. 본문에 들어있는 데이터의 타입이 무엇인지 말할 수 있다. 예를 들어 Content-Type: text/html; charset=iso-larin-1는 데이터가 iso-latin-1 문자집합으로 된 HTML 문서임을 알린다.

엔터티 정보 헤더

일반적으로 엔터티 헤더는 메시지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말한다.

  • Allow: 이 엔터티에 대해 수행될 수 있는 요청 메서드를 나열한다.
  • Location: 클라이언트에게 엔터티가 실제로 어디에 위치하는지 알려준다. 리소스에 대한 위치(URL)을 알려줄 때 사용한다.


엔터티 콘텐츠 헤더

콘텐츠에 대한 구체적인 정보를 제공한다. 종류, 크기, 기타 등등… 브라우저는 Content-Type을 보고 그 객체를 어떻게 보여줄 지 결정할 수 있다.

  • Content-Base: 본문에서 사용된 상태 URL을 계산하는 base url
  • Content-Type: 이 본문이 어떤 종류의 객체인지
  • Content-Encoding: 본문에 적용된 인코딩이 무엇인지
  • Content-Language: 본문을 이해하는데 적절한 자연어
  • Content-Length: 본문의길이나 크기
  • Content-Location: 리소스가 실제 어디에 위치하는지
  • Content-MD5:본문의 MD5 체크섬(checksum)
  • Content-Range: 전체 리소스에서 이 엔터티가 해당하는 범위를 바이트 단위로 표현


*MD5: HTTP 메시지 본문의 내용을 MD5 알고리즘을 사용하여 계산된 체크섬(checksum) 값. MD5는 메시지 다이제스트 알고리즘 5(Message Digest Algorithm 5)의 약자로, 임의 길이의 데이터를 입력 받아 128비트 고정 길이의 해시값을 출력하는 암호화 해시 함수다. 체크섬은 데이터의 무결성을 검증하는 데 사용되는 값으로, 데이터가 전송이나 저장 과정에서 변경되었는지 확인하기 위해 사용한다.


엔터티 캐싱 헤더


일반 캐싱 헤더는 언제 어떻게 캐시가 되어야 하는지에 대한 지시자를 제공한다. 엔터티 캐싱 헤더는 엔터티 캐싱에 대한 정보를 제공한다.

  • Etag: 이 엔터티에 대한 엔터티 태그
  • Expires: 이 엔터티가 더이상 유효하지 않아 원본을 다시 받아와햐 하는 일시
  • Last-Modified: 가장 최근 이 엔터티가 변경된 일시


확장 헤더

명세에 정의되지 않은 새로운 해더. 애플리케이션 개발자들에 의해 만들어졌지만 아직 승인된 HTTP 명세에는 추가되지 않은 비표준 헤더다.