HTTP 웹 기본 지식 (6) - HTTP 상태코드

김영한님의 HTTP 웹 기본지식을 들으며 정리하였습니다.

 

HTTP 상태코드

서로가 합의된 코드를 사용해서 소통하는 것임. 200이 오면 아 성공했구나~ 이걸 클라이언트가 알 수 있는 것. 근데 만약에 278 이런 이상한 코드가 온다면 ? 그래도 200번대니까 성공했구나 하고 넘길 수 있음.

• 100번대 : 요청이 수신되어 처리중 (안씀)
• 200번대 Successful : 요청 성공
• 300번대 Redirection : 아직 완료 X, 추가 행동이 필요.
• 400번대 Client Error : 클라이언트 오류 (잘못된 문법 등 요청 잘못보냄)
• 500번대 Server Error : 서버 오류 (DB오류 등)

 

2XX Successful 

• 200 OK : 요청 성공
• 201 Created : 어떤 리소스가 생성됨. Post로 등록한 상황 등)
• 202 Accepted : 요청이 접수되었으나, 처리가 완료되지 않았음. 1시간 뒤에나 처리예정 이런 상황. (잘안씀)
• 204 No Content : 요청 성공했는데, 응답으로 return할 데이터가 없음. (티스토리 임시저장 누를 때, 같은 화면 유지한채로 "작성중인 글이 저장되었습니다" 문구만 뜸. 이렇게 보낼 데이터 없는 경우)
• 200, 201 정도를 주로 씀. 그러나 상태코드가 엄청 많기 때문에 팀 내부에서 정한 규칙 따르면 됨.

 

3XX Redirection

• Redirection : 응답결과로써 Location 헤더에 300번대 결과를 보내면, 웹브라우저는 적혀있는 Location 위치로 자동 이동하게 됨. ex) 기존 이벤트 페이지A , 새로운 이벤트 페이지B가 있음. 누가 A페이지 링크 있어서 그거 타고 들어가면 B로 가게끔 유도하는 거임.
• 일단 Redirect 자체가 뭔가 내용도 바뀌고, Post였던 게 Get으로 바뀌고 이런 게 당연히 일어날 수 있다는 생각 하에 아래 내용 살펴보기. 

1. 영구 Redirection (301, 308) : 위 예시처럼, 특정 리소스의 URI가 영구적으로 이동함. 일단 301, 308은 기능이 서로 같음.

• 301 Moved Permanently : Post 요청했었는데 Get으로 바뀌는 등 요청 메소드가 바뀔 수 있고, 이에 따라서 본문이 제거될 "수" 있음. (301이 자주 사용되지는 않는다고 함)
• 308 Permanent Redirect : 리다이렉트 보낼 메소드를 유지함. 내용도 body에 그대로 유지해서 보냄. 즉, 처음 Post였으면 리다이렉트도 본문 내용 유지한채로 Post 보냄. 근데 어차피 Redirect하는 것 자체가 본문 내용을 바꾸는 경우가 대부분이라 308은 안쓰게 됨.

2. 일시적인 Redirection (302, 307, 303) : 주문 완료후, 주문 내역으로 이동하는 것. 이때 PRG라는 패턴이 사용됨. (Post Redirect Get) 일단 302 307 303 기능은 다 같음.

• 리소스 URI가 일시적으로 변경되는 것.
• 302 Found : 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 "수" 있음. (301때 상황이랑 똑같음.)
• 307 Temporary Redirect : 리다이렉트시 요청 메서드와 본문이 안바뀜. 즉, Post로 보냈으면 반드시 Post로만 리다이렉트 하게 됨.
• 303 See Other : 리다이렉트시 요청 메서드가 GET으로 변경이 되어야함. 무조건 GET으로 요청하고 싶을 때 사용.
• 정리 : 302는 모호해서 307, 303을 만들었지만 이미 302를 기본값으로 쓰는 경우가 많음. 그래서 리다이렉션시 Get으로 변해도 상관 없는 상황이라면 302 써도 상관없음.

3. 특수 Redirection (300, 304)  : 결과 대신 캐시를 리다이렉트 해준다.

• 300 Multiple Choices : 안씀.
• 304 Not Modified : 많이 씀. 예를 들어 별 이미지 캐시가 만료된줄 알고 서버로 다시 캐시해달라고 보냈는데 아직 만료가 아니니까, 클라이언트 네가 지금 갖고있는 거 쓰라고 캐시로 리다이렉트 해줌. 즉, 로컬에 저장된 캐시를 재사용하게 되는 것. 그래서 응답에 메세지 바디를 포함하면 안됨.

Q. 일시적 Redirect는 언제 쓸까 ?? - PRG (Post, Redirect, Get) 

주문 완료 후 리다이렉트 없이 200 OK 응답을 주게 되면, 주문완료 페이지에서 새로고침을 했을 때 마지막 요청이었던 주문 Post가 또 날라가서 주문이 2번 되는 수가 있음. 이를 서버에서 당연히 안전장치를 걸어놓아야 하고, 클라이언트쪽에서도 방지하고자 함.

 

>> 해결책

새로고침했을 때 Post가 다시 날라가는 게 아니고, 주문 결과 화면 페이지만 Get으로 날라가게 만들면 됨.

▶ 응답으로 302를 보내면서 주문완료 페이지를 주문번호와 리다이렉트 해줌.

→ 그러면 웹브라우저는 3XX 왔으니까 Location 확인하고, 보니까 주문내역이 써있음. (ex. musinsa/order/result/120 )

→ 클라이언트는 302니까 이 Location에 대해서 GET을 다시 요청하게 됨.

→ 그러면 최종적으로 주문 내역을 보여주는 화면이 뜨고 이건 GET으로 받아온 거라서 새로고침 해도 GET요청을 다시 보내는 꼴이라 Post랑 관련 없음.

→ 즉, Post를 Get으로 바꾸는 리다이렉트를 하는건데 이 과정이 너무 빨라서 우리가 보기에는 그냥 주문 내역이 바로 나오게 보여지는 것임. 

 

4XX Client Error

오류의 원인이 클라이언트에 있을 때(문법 등 요청 잘못 보냄) 사용한다. 이때, 클라이언트가 이미 잘못된 요청을 만든 것이라서 재시도를 해도 똑같이 실패하게 됨. (재시도 해도 복구 불가능)

• 400 Bad Request : 클라이언트가 문법 오류, 파라미터 오류(숫자를 요구하는데 문자를 보내거나) 등으로 요청 자체를 잘못해서 서버가 요청을 처리할 수 없는 상태.
• 401 Unauthorized : 로그인이 안된 상황. 클라이언트가 인증(Authentication) 이 필요함. 401 오류와 함께 응답으로 인증 방법을 설명해줘야함. → 단어만 보면 Unauthorized라서 인가가 안됐다는 것처럼 보이지만 사실은 Unauthentication이 맞음. 인증이 없는 거지, 인가가 안된 것은 아니라서 작명 미스라고 볼 수 있음. 
  • 인증(Authentication) : 본인이 누구인지 확인(로그인)
  • 인가(Authorization) : 권한이 없어서 못본다는 것.
• 403 Forbidden : 접근 권한이 없을 때. 즉, 요청을 이해했지만 거절한 상황. (일반인이 admin 접근했을 때)
• 404 Not Found : 요청 리소스를 찾을 수 없음. 또는 클라이언트가 권한이 없는 리소스에 접근할 때 리소스를 숨기고 싶을 때 사용할 수 있음.

5XX Server Error

서버 오류로 생긴 문제. 그래서 요청 재시도 하면 성공할 수도 있음. 500에러는 서버 문제가 확실할 때만 사용하고, 웬만해서는 쓰지 말아야한다. 예외케이스(ex. 19세 이상 영화관에 17세가 들어옴)를 서버 오류로 착각하면 안됨.

• 500 Internal Server Error : 서버 내부 문제. 애매하면 500 오류를 냄.
• 503 Service Unavailable : 서비스 이용 불가. 서버가 일시적인 과부화 or 작업하고 있어서 요청을 처리할 수 없다는 뜻. 그러나 장애 복구 시간을 예측하기 힘드므로 그냥 500을 내는 경우가 많음.