김영한 님의 HTTP 웹 기본지식 강의/5.HTTP 상태코드

HTTP 상태 코드란?

• 클라이언트가 서버를 향해 리퀘스트를 보낼 때 서버에서 그 결과가 어떻게 되었는지 알려주는 것아 상태 코드의 역할이다.  
• 서버가 리퀘스트를 정상적으로 처리했는지, 그렇지 않으면 리퀘스트 결과가 에러였는지 알 수 있다.

 

 - 상태 코드의 종류 

• 1XX ( informational ) : 요청이 수신되어 처리 중 (거의 사용하지 않음)
• 2XX ( Successful ) : 요청 정상 처리 
• 3XX ( Redirection ) : 요청을 완료하면 추가 행동이 필요 
• 4XX ( Client Error ) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음
• 5XX ( Server Error ) : 서버 오류, 서버가 정상 요청을 처리하지 못함

 

 - 만약 모르는 상태 코드가 나왔다면?

• 클라이언트가 인식할 수 없는 상태 코드를 서버가 반환하면? --> 클라이언트는 상위 상태 코드로 처리 
• 미래에 새로운 상태 코드가 추가되어도 클라이언트를 변경하지 않아도 됨

EX) 299 ??? ---> 2XX ( Successful ) : 요청 정상 처리 

EX) 451 ??? ---> 4XX ( Client Error ) : 클라이언트 오류, 잘못된 문법 등으로 서버가 요청을 수행할 수 없음

 

 

 

 - 2XX --> 처리 성공 

• 200 OK : 요청을 정상적으로 처리함

 

 

• 201 Created : 요청 성공해서 새로운 리소스가 생성됨 ( Location: URL, 이런식으로 POST 요청에 생긴 리소스를 표현한다 )

 

 

 

• 202 Accepted : 요청이 접수되었으나 처리가 완료되지 않음.

 - 배치 처리 같은 곳에 사용한다. EX ) 요청 접수 후 1시간 뒤에 배치 프로세스가 요청을 처리함

 

 

• 204 No Content : 서버가 요청을 성공적으로 수행했지만, 응답 페이로드 본문에 보낼 데이터가 없음.

 - 웹 문서 편집기에서 save 버튼

 - save 버튼의 결과로 아무 내용이 아무 내용이 없어도 된다. 

 - save 버튼을 눌러도 같은 화면을 유지해야 한다. 

 - 결과 내용 없이도 204 메시지 (2XX)만으로 성공을 인식할 수 있다.

 

 

 - 3XX --> 리다이렉션, 요청을 완료하기 위해 유저의 추가 조치 필요,

               웹 브라우저는 3XX 응답 결과에 Location 헤더가 있으면, Location 위치로 자동 이동 

 

   1) 리다이렉션의 이해 

 

1.  클라이언트가 /event의 위치로 요청을 한다.

 

2. (/event URL은 현재 사용하지 않는 URL) 서버에서 클라이언트에게 Location 헤더에 현재 사용하고 있는 URL을 삽입하여 보낸다.

 

3. 서버에서 넘겨준 주소로 redirect.

---> 웹 브라우저 스스로 주소창에 있는 주소를 새롭게 받은 경로로 바꾸고 엔터를 친다. 

 

4. 변경된 URL로 서버에게 다시 요청 / HTTP 메서드가 GET으로 변경됐다.

 

5. 서버에서 요청에 대한 응답을 보내준다.

 

 

 

  2) 리다이렉션의 종류

• 영구 리다이렉션  - 특정 리소스의 URL가 영구적으로 이동

EX ) /members -----> /users   (내부적 URL이 완전히 변경되었을 경우)

EX ) /event ---------> /new_event

 

• 일시 리다이렉션  - 일시적인 변경

EX ) 주문 완료 후 주문 내역 화면으로 이동

EX ) PRG: Post/Redirect/Get : 일시 리다이렉션에서 자주 쓰이는 패턴

 

• 특수 리다이렉션 - 결과 대신 캐시를 사용한다. 

 

   - 영구 리다이렉션 301, 308 

 

 리소스의 URL이 영구적으로 이동

 원래의 URL을 사용 X, 검색 엔진 등에서도 변경 인지 

 

• 301 Moved Permanently : 리다이렉트 시 요청 메서드가 GET으로 변하고 본문이 제거될 수 있음(MAY)

1. POST /event (메시지 존재) 방식으로 서버에 요청

2. 응답으로 새로운 URL( /new_event ) Locatrion 헤더에 삽입, 301 Moved Permanently 상태 코드로 응답한다. 

3. 서버에서 넘겨준 주소로 redirect.

4. 변경된 URL로 서버에게 다시 요청 / HTTP 메서드가 GET으로 변경됐고 바디 내용이 삭제됐다. 

5. 서버에서 요청에 대한 응답을 보내준다.

 

 

• 308 Permanent Redirect : 301과 기능은 같다. 리다이렉트시 요청 메서드와 본문 유지( 처음 POST를 보내면 리다이렉트도 POST 유지 )

1. POST,  /event (메시지 존재) 방식으로 서버에 요청

2. 응답으로 새로운 URL( /new_event ) Locatrion 헤더에 삽입, 308 Permanent Redirect 상태 코드로 응답한다. 

3. 서버에서 넘겨준 주소로 redirect.

4. 변경된 URL로 서버에게 다시 요청 / HTTP 메서드가 POST로 그대로 유지, 바디 내용도 그대로 유지한다.

5. 서버에서 요청에 대한 응답을 보내준다.

 

 

 

   - 일시 리다이렉션 302, 307, 303 

리소스의 URI가 일시적으로 변경된다. --> 따라서 검색 엔진 등에서 URL을 변경하면 안 됨

 

• 302 Found 

 - 리다이렉트 시 요청 메소드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)

 

• 307 Temporary Redirect

 - 302와 기능은 같음

 - 리다이렉트시 요청 메서드와 본문 유지(요청 메서드를 변경하면 안 된다. MUST NOT)

 

• 302 See Other

 - 302와 기능은 같음

 - 리다이렉트 시 요청 메서드가 GET으로 변경

 

 

 - 만약 POST 요청으로 주문 후에 웹 브라우저를 새로고침 하면?

 

---> 새로고침은 다시 요청하는 것.

---> 중복 주문이 될 수 있다.

 

PRG  사용전

 

이를 방지하는 패턴!

- PRG 패턴 ( POST/Redirect/Get ) 

• POST로 주문 후에 새로 고침으로 인한 중복 주문 방지 
• POST로 주문후에 주문 결과 화면을 GET 메서드로 리다이렉트
• 새로고침해도 결과 화면을 GET으로 조회 
• 중복 주문 대신에 결과 화면만 GET으로 다시 요청 

PRG 사용후

1. POST,  /order (메시지 존재) 방식으로 서버에 요청

2. 서버에서 DB로 주문 데이터 송신, DB에서 처리 후 서버로 데이터 송신

3. 서버에서 클라이언트로 응답 , Location 정보도 같이 준다

( 상태 코드 : 302 Found --> 리다이렉트 요청 시 메서드를 GET으로 바꾸고, 본문이 제거될 가능성이 있음)

4. 자동 리다이렉트 / URL : /order-result/19 를 브라우저가 주소창에 치고 엔터! 

5. GET 메서드를 사용해서 서버에 요청 / 주문 결과 페이지를 요청

6. 서버에서 DB로 주문 조회, DB에서 주문조회 완료 후 서버로 결과 리턴

7. 서버에서 주문 완료 HTML 코드를 바디에 넣고, 상태 코드 200 OK로 클라이언트에게 송신

8. 만약 결과 화면에서 새로고침을 한다면 5번으로 다시 이동.

 

 

- 그래서 무엇을 써야 할까? 302, 307, 303

• 302 found : GET으로 변할 수 있음
• 307 Temporary Redirect : 메서드가 변하면 안 됨
• 303 See Other : 메서드가 GET으로 변함 

현실 :  307, 303을 권장하지만 현실적으로 이미 많은 애플리케이션에서 라이브러리들이 302를 기본값으로 사용한다.

자동 리다이렉션 시에 GET으로 변해도 되면 그냥 302를 사용해도 큰 문제없음 

 

 

 

 

 

 

 

 

 

 

참고:

본 포스팅에 있는 모든 자료는 김영한 님의 HTTP 웹 기본지식 강의의 자료들입니다.

06. HTTP 웹 기본 지식 - HTTP 상태코드 소개 (aejeong.com)