HTTP 총 정리 3편
안녕하시렵니까? HTTP 이야기의 세번째 시간인 서버가 보내는 응답 메시지와 서버와 클라이언트의 응답/요청 메시지 부분의 HTTP 헤더에 관해 글을 써!보!겠!습!니!다! 응답 메시지는 아래 그림과 같아요.
첫번째 글에서 각 부분에 대한 설명을 했지만, 다시 이야기 해보자면 맨 윗 줄인 시작라인에는 HTTP의 버전과 상태코드(200) 상태 코드에 대한 간략한 설명(OK) 가 있고 그 밑에는 header 부분으로서 밑에 나올 메시지 바디에 관한 참고 컨셉들이 나오게 됩니다.
일단, 상태 코드들에 대해서 먼저 다루어 봅시다!
1 상태코드
상태 코드는 크게 5가지 종류가 있지요~ 100번대부터 500번대 까지 있지요~ 각 부분에 대한 설명을 하지요~
1.1 1XX
요청이 수신되어 처리 중. 딱 봐도 거의 사용 안됨
1.2 2XX
요청이 성공했다는 의미.
200 (OK) : 위에서 보았듯이 OK~
201 (Created) : 요청에 성공해서 새로운 리소스가 생성되었다는 의미! 주로 PUT이나 POST의 응답 메시지 이겠죠? 응답 메시지 헤더 부분에 Location : /~~~ 을 통해 리소스의 주소를 주기도 합니다.
202 (Accepted) : 요청이 접수 되었으나 처리가 완료되지 않았다는 의미. 뭐 약간 1 시간 뒤에 있을 이벤트 설정 같은 거지요
204 (No Content) : 서버가 요청을 성공적으로 수행했으나, 딱히 보낼만한 데이터가 없을 때 사용. 예시로는 웹 문서 편집에서 save 버튼! 임시 저장 해도 내용이 바뀌지도 않고, 화면을 계속 유지해야하니 이럴 때 사용
1.3 3XX
리다이렉션으로서 요청을 완료하기 위해 클라이언트가 어떠한 행동을 하나 더 해야할 경우 뿌립니다. 리다이렉션이란 응답 메시지에 3XX 코드와 함께 응답 결과에 Location 헤더가 있으면 그 위치로 클라이언트가 요청 메시지를 만들어 서버에게 또 다른 요청 메시지를 보낸다요.
이 3XX에서도 종류가 있는데
i) 영구 리다이렉션 - 특정 리소스의 URI가 영구적으로 이동. 즉, A를 찾으려면 예전에는 /AAA로 가면 되었는데 이젠 /BBB로 가야 할 경우.
301 (Moved Permanently) : 리다이렉트 시 요청 메서드가 GET으로 변하고, 이에 본문이 제거 될 수 있음
308 (Permanent Redirect) : 301과 기능은 같지만 요청 메서드와 본문이 유지된다.
ii) 일시 리다이렉션 - 일시적인 변경. 예를 들어 주문 완료 후 주문 내역 화면으로 이동해야 할 경우. 리소스의 URI가 일시적으로 변경 되는 것이기에 검색 엔진 같은 서버에서는 URL을 변경하면 안돼요
302 (Found) : 리다이렉트 시 요청 메서드가 GET으로 변하고, 본문이 제거 될 수 있음. 근데 대부분 변하고 제거 된답니다. 밑에 303 안쓰고 그냥 사용해도 괜찮아요.
307 (Temporary Redirect) : 302와 기능은 같으나 308처럼 요청 메서드와 본문이 유지된다.
303 (See Other) : 302와 기능은 같으나 확실하게 GET으로 바꾸고 본문 제거해 버리고 싶다면 사용하세용.
PRG (Post/Redirect/Get) : 결재 시스템에 관련이 깊다. 주문 완료를 누르면 어떤 요청 메서드가 갈까~요~? 정답은, 두구구두구구두두 POST 메서드 입니다! 하지만 이때 새로고침을 누르게 되면 마지막 요청을 반복 해버리기에 중복 주문이 될 수 있답니다. 그래서 이를 방지하기 위해 주문! 버튼을 누르면 302나 303으로 상태코드를 줍니다. 그럼 주문 결과 화면을 GET메서드로 리다이렉트를 해서 새로 고침해도 결과 화면을 GET으로 조회하게 하면 해결!
iii) 특수 리다이렉션 - 결과 대신 캐시 사용. 이 부분은 다음 글에서 다룰 예정입니다. 대표적으로 304 (Not Modified) 가 있답니다. 간단하게는 응답 메시지로 온 리소스를 로컬PC에 저장하는데(캐시) 이 캐시를 재사용 해라! 라는 상태 코드입니다.
1.4 4XX
클라이언트 오류를 지칭하는 말로 클라이언트의 요청 메시지에 문법이 잘못 되었거나 없는 걸 보내는 식으로 클라이언트에게 오류의 원인이 있으니 재시도 해도 똑같이 실패 합니다.
400 (Bad Request) : 클라이언트가 잘못된 요청을 함. 요청 메시지의 문법 오류 같은 경우. 클라이언트는 요청 내용을 잘~ 확인해서 다시 보내시오!
401 (Unauthorized) : 해당 리소스에 대한 클라이언트의 인증이 필요함. 이름이 권한이 없다이지만, 사실 내용은 인증을 시도하라! 라는 의미에에요오. 그니깐 이 계정이 쏴장늼~ 인지 일반 사원인지 확인하라는 것이 아니라 로그인 해라 라는 의미랍니다.
403 (Forbidden) : 로그인 했지만 쏴장늼이 아니라서 접근 권한이 불충분한 경우의 코드랍디다.
404 (Not Found) : 정말 자주 본 상태코드! 요청 리소스가 서버에 없다는 것을 의미하기도 하지만! 서버가 해당 클라이언트에게 리소스 정보를 숨기고 싶을 때 사용 하기도 한답니다. (섭섭해)
1.5 5XX
서버 측에서 오류가 발생했다는 의미로 서버에 문제가 있으니 재시도 하면 성공할 수도 있어요.
500 (Internal Server Error) : 서버 문제로 오류 발생, 대부분의 상황에서 이 코드를 사용합니다.
503 (Service Unavailable) : 서버의 일시적인 과부화 또는 예정된 작업(업데이트) 로 인해 잠시 요청 처리 불가. Retry-After 헤더 필드에 얼마 뒤에 복구 되는지 명시 하기도 함니담.
2. HTTP 헤더
아래 사진의 노란 네모 부분이 헤더라고 부릅니다. 많이 이야기 했지요!
강조하지만 field-name":"(OWS) field-value (OWS) 에서 OWS를 제외한 부분에서 띄어 쓰기가 있으면 안돼요! field-name은 대소문자 구분이 없고요.
이 부분에서 HTTP 전송에 필요한 모든 정보들을 담고 있고 상당히 많은 양의 표준 헤더가 존재합니다. 더욱이 필요 시에는 임의의 헤더를 추가할 수도 있답니다.
과거에는 HTTP 헤더를 총 네 가지로 분류 했어요. General 헤더, Request 헤더, Response 헤더. 각각은 메시지 전체에 적용되는 정보, 요청 정보, 응답 정보로 각각 분류하고요 중요한 것은 Entity 헤더라고 불리는 엔티니 바디(메시지 바디) 정보를 담고 있지요. 즉 메시지 바디를 해석하는 컨셉은 Entity 헤더에 있었답니다. 예를 들면 데이터 유형(html, json), 데어티 길이, 압축 정보 같은 녀석들이지요.
하지만 최근에는 메시지 바디라고 부르며 메시지 본문을 payload라고 칭했습니다. 그에 따라 Entity 헤더가 아닌 표현 헤더라고 불리게 됩니다. 표현이란 뜻은 요청이나 응답에서 전달할 실제 데이터라고 생각하시면 됩니다.
2.1 표현 헤더
표현 헤더는 전송, 응답에 둘 다 사용 되는 헤더랍니다. 흔히 이 네가지를 볼 수 있는데 Content-Type, Content-Encoding, Content-Language, Content-Length 가 있어요.
먼저, Content-Type! 표현 데이터의 형식을 설명해요. 미디어 타입이라던지 문자 인코딩 즉 대게 아래 처럼 온답니다.
Content-Type: text/html; charset=utf-8
Content-Type: application/json
Content-Type: image/png
두 번째로 Content-Encoding이에요. 표현 데이터를 압축을 어떠한 방식으로 했는지 알려주지요. 그럼 데이터를 읽는 쪽에서 인코딩 헤더의 정보로 압축을 해제합니다.
Content-Encoding: gzip
Content-Encoding: deflate
Content-Encoding: identity
세 번째로 Content-Langauage 입니다. 표현 데이터의 자연 언어, 즉 어느 나라 말로 표현 해 줄지 입니다.
Content-Language: ko
Content-Language: en
Content-Language: en-US
마지막인 Contetn-Length는 표현 데이터의 길이이고 바이트 단위로 보냅니다. 단순히 Content-Length: 5 처럼요.
마무리
여기까지 세 번째 HTTP 이야기를 끝내고 다음 글에서는 협상, 전송 방식, 인증, 쿠키, 캐시와 조건부 요청을 끝으로 HTP 이야기를 마무리 하겠습돠~!