개요

  • 메세지가 어떻게 흘러가는가
  • HTTP 메세지의 구조
  • 요청과 응답 메세지의 차이
  • 요청 메세지가 지원하는 메서드들
  • 응답 메세지가 반환하는 상태 코드들
  • HTTP 헤더의 역할

HTTP 메세지

  • 어플리케이션 간에 주고받은 데이터의 블록
  • 메세지의 내용과 의미를 설명하는 텍스트 메타 정보로 시작, 그 다음 선택적으로 데이터가 올 수 있음
  • '인바운드, 아웃바운드, 업스트림, 다운스트림'은 메세지의 방향을 의미

메세지의 방향

1. 메세지는 원 서버 방향을 인바운드로 하여 송신된다.

트랜잭션 방향을 표현하기 위해 '인바운드', '아웃바운드'라는 용어를 사용한다. 메세지가 원 서버로 향하는 것은 인바운드로 이동하는 것이고, 모든 처리가 끝난 뒤에 사용자에게 돌아오는 것은 아웃바운드로 이동하는 것이다.

2. 다운스트림으로 흐르는 메세지

요청/응답 메세지냐에 관계 없이 모든 메세지는 다운스트림으로 흐른다.
메세지의 발송자는 수신자의 업스트림이다.

메세지 구조

각 메세지는 클라이언트의 요청이나 서버로부터의 응답 중 하나를 포함한다.
메세지는 시작줄, 헤더, 본문 세 부분으로 이루어진다.

시작줄은 어떤 메세지인지 서술하고 있으며, 헤더는 속성, 본문은 데이터를 담고 있지만 본문이 없을 수도 있다.

메서드

Safe Method

GET과 HEAD 메서드는 안전하다고 할 수 있는데, 이 두 메서드를 사용하는 HTTP 요청의 결과로 서버에 어떤 작용도 없음을 의미한다.

예를 들어 온라인 쇼핑을 하다가 '구매' 버튼을 클릭했을 때, 신용카드 정보를 담은 POST 요청이 전송되고 서버에서 작용이 일어난다. 여기서 '작용'이란 구매로 인해 신용카드로 대금이 청구되는 것을 말한다.

안전한 메서드가 서버에 작용을 일으키지 않는다는 보장은 없다(개발자에게 달렸음).
안전한 메서드의 목적은 서버에 영향을 줄 수 있는 안전하지 않은 메서드가 사용될 때 사용자에게 그 사실을 알려주는데에 있다.

GET

  • 주로 서버에게 리소스를 요청하기 위해 쓰인다.
  • GET과 유사하지만, 서버는 응답으로 본문을 제외한 헤더만을 돌려준다.
  • 반환되는 헤더가 GET으로 얻는 것과 정확히 일치해야 한다.
  • HTTP//1.1 준수를 위해서 반드시 구현되어 있어야 한다.

PUT

  • 서버가 요청의 본문을 가지고 요청 URL의 이름대로 새 문서를 만들거나, 이미 URL이 존재한다면 본문을 사용해서 교체한다.
  • 콘텐츠를 변경할 수 있게 해주기 때문에, PUT을 수행하기 전에 사용자에게 로그인을 하도록 요구해야 한다.

POST

  • 입력된 데이터를 서버에 전송하기 위해 사용된다.

TRACE

  • 클라이언트에게 자신의 요청이 서버에 도달했을 때 어떻게 보이게 되는지 알려준다. (클라이언트가 요청을 할 때, 방화벽, 프락시, 게이트웨이 등의 애플리케이션을 통과할 수 있고, 요청을 수정할 수 있다)
  • TRACE 메서드는 주로 진단을 위해 사용된다.
  • 엔터티 본문을 보낼 수 없고, 응답 본문에는 서버가 받은 요청이 그대로 들어있다.

OPTIONS

  • 웹 서버에게 특정 리소스에 대해 어떤 메서드가 지원되는지 물어볼 수 있다.

DELETE

  • 서버에게 요청 URL로 지정한 리소스를 삭제할 것을 요청한다.
  • 삭제가 수행되는 것을 보장받지 못한다.(서버가 클라이언트에게 알리지 않고 요청을 무시하는 것을 허용한다.)

확장 메서드

  • HTTP는 필요에 따라 확장해도 문제가 없도록 설계되어 있어 새로 기능을 추가해도 레거시의 오동작을 유발하지 않는다.

    메서드설명
    LOCK       사용자가 리소스를 잠글 수 있게 해준다.
    예) 문서를 편집하는 동안 다른 사람이 동시에 같은 문서를 편집하지 못하도록 문서를 잠글 수 있다.
    MKCOL사용자가 문서를 생성할 수 있게 해준다.
    COPY서버에 있는 리소스를 복사한다.
    MOVE서버에 있는 리소스를 옮긴다.

상태 코드

상태 코드는 숫자로 된 코드, 문자열로 이루어져 사람이 이해하기 쉬운 형태로 응답 메시지의 시작줄에 담겨 반환된다.

상태 코드 종류

전체 범위정의된 범위분류
100-199100-101정보
200-299200-206성공
300-399300-305리다이렉션
400-499400-415클라이언트 에러
500-599500-505서버 에러

사유 구절

사유 구절은 상태 코드와 일대일로 대응되고 요청 중에 무슨 일이 일어났는지 알려주기 위해 사용되는 상태 코드의 이해하기 쉬운 버전이다.
사유 구절이 어때야 한다는 엄격한 규칙은 없다.

헤더

메서드와 마찬가지로 클라이언트와 서버가 무엇을 하는지 결정하기 위해 사용된다.

일반 헤더

메세지가 어떤 종류이든 상관없이 기본적이지만 유용한 정보를 제공한다.

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

일반 캐시 헤더

헤더설명
Cache_Control메세지와 함께 캐시 지시자를 전달하기 위해 사용
Pragma메세지와 함께 지시자를 전달하는 또 다른 방법. 캐시에 국한되지 않음

요청 헤더

요청 헤더는 요청 메세지에서만 의미를 갖는다. 요청이 최초 발생한 곳에서 누가 혹은 무엇이 요청을 보냈는지에 대한 정보나 클라이언트의 선호나 능력에 대한 정보를 준다.

헤더설명
Client-IP클라이언트가 실행된 컴퓨터의 IP를 제공
From클라이언트 사용자의 메일 주소를 제공
Host요청의 대상이 되는 서버의 호스트 명과 포트 제공
Referer현재의 요청 URI가 들어있었던 문서의 URL을 제공
User-Agent요청을 보낸 애플리케이션의 이름을 서버에게 말해준다.

Accept 관련 헤더

클라이언트는 Accept 관련 헤더들을 이용해 서버에게 무엇을 원하고 무엇을 할 수 있는지, 원치 않는 것은 무엇인지 알려줄 수 있다. 서버는 이 추가 정보들을 활용해 무엇을 보낼 것인가에 대해 결정을 내릴 수 있다.

헤더설명
Accept서버가 보내도 되는 미디어 종류를 말해준다
Accept-Charset서버가 보내도 되는 문자집합
Accept-Encoding서버가 보내도 되는 인코딩
Accept-Language서버가 보내도 되는 언어
TE서버가 보내도 되는 확장 전송 코딩

조건부 요청 헤더

때대로 클라이언트는 요청에 조건이 참인지 확인하게 하는 제약을 포함시킬 수 있다.

헤더설명
Expect클라이언트가 요청에 필요한 서버의 행동을 열거할 수 있게 함
If-Match문서의 엔터티 태그가 주어진 엔터티 태그와 일치하는 경우에만 문서를 가져옴
Range서버가 범위 요청을 지원한다면, 리소스에 대한 특정 범위를 요청
...기타 등등

요청 보안 헤더

HTTP는 자체적으로 요청을 위한 간단한 인증 요구/응답 체계를 가지고 있다. 요청하는 클라이언트가 어느 정도의 리소스에 접근하기 전에 자신을 인증하게 함으로서 트랜잭션을 안전하게 만들고자 한다.

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

프락시 요청 헤더

프락시의 기능을 돕기 위해 사용된다.

헤더설명
Max-Forwards요청이 원 서버로 향하는 과정에서 다른 프락시나 게이트웨이로 전달될 수 있는 최대 횟수. TRACE 메서드와 함께 사용된다.
Proxy-AuthorizationAuthorization과 같으나 프락시에서 인증을 할 때 쓰인다.
Proxy-ConnectionConnection과 같으나 프락시에서 연결을 맺을 때 쓰임.

응답 헤더

응답 메세지는 응답 메세지만의 헤더를 갖는다. 응답 헤더는 클라이언트에게 부가 정보를 제공한다.

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

협상 헤더

서버에 프랑스어, 독일어로 번역된 HTML 문서가 있는 경우와 같이 다국어 표현이 가능한 상황이라면, HTTP/1.1은 서버와 클라이언트가 어떤 표현을 택할 것인가에 대한 협상을 할 수 있도록 지원한다.

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

응답 보안 헤더

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

엔터티 헤더

  • 엔터티 헤더는 엔터티와 그것의 내용물에 대한, 개체의 타입부터 시작해서 주어진 리소스에 대해 요청할 수 있는 유효한 메서드등 메세지의 수신자에게 자신이 다루고 있는 것이 무엇인지 말해준다.
  • 요청과 응답 양쪽 모두 엔터티를 포함할 수 있기 때문에 양 타입의 메세지에 모두 나타날 수 있다.
헤더설명
Allow이 엔터티에 대해 수행될 수 있는 요청 메서드들을 나열
Location클라이언트에게 엔터티가 실제로 어디에 위치하고 있는지 말해 준다. 수신자에게 리소스에 대한 위치(URL)을 알려줄 때 사용.

콘텐츠 헤더

엔터티의 컨텐츠에 대한 구체적인 정보를 제공한다.

헤더설명
Content-Base본문에서 사용된 상대 URL을 계산하기 위한 기저 URL
Content-Encoding본문에 적용된 인코딩
Content-Lnaguage본문을 이해하는데 가장 적절한 자연어
Content-Length본문의 길이나 크기
ContentL-Location리소스가 실제로 어딩 위치하는지
Content-Range전체 리소스에서 이 엔터티가 해당하는 범위를 바이트 단위러 표현
Content-Type이 본문이 어떤 종류의 객체인지

엔터티 캐싱 헤더

엔터티 캐싱에 대한 정보를 제공한다.

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

0개의 댓글