그런데, 내가 HTTP 상태코드에 대해 정리를 한적이 없다는 것을 어제 저녁에 알게 되니.. 아차 싶다.
이전 강좌들에서 주제를 설명하면서 들었던 예시들에 자주 등장했던게 바로 HTTP 상태코드인데... 그리 중요한것을 정리하지 않고 넘어갈 뻔 한게 아닌가?
그래서 HTTP 보안 그리고 가속의 내용으로 넘어가기 전에 오늘은 HTTP 상태코드에 대한 정리를 좀 해 보려 한다.
HTTP 상태코드는 클라이언트의 요청을 처리하고 난 후 결과를 설명하는 아주 중요한 정보이다. 상태코드는 숫자 3자리로 되어 있으며 첫번째 자리의 숫자를 기준으로 크게 다음과 같이 구분한다.
- 1xx : 단순 정보 제공
- 2xx : 성공 (클라이언트의 요청을 정상적으로 처리함)
- 3xx : 리다이렉트 (클라이언트를 다른 URI 또는 도메인으로 리다이렉트 함)
- 4xx : 클라이언트쪽 에러
- 5xx : 서버쪽 에러
각 코드별로 가장 첫번째 자리가 해당 코드군의 마스터 상태 코드이다.
그러니까 1xx 의 마스터는 100 이고, 2xx 의 마스터는 200 인것이다.
클라이언트는 서버가 정의되지 않은 HTTP 상태코드를 주는 경우는 마스터코드로 처리하게 된다. 예를 들어 미정의된 278 코드를 전달받으면 클라이언트는 200으로 여기고 처리한다는 뜻이다.
다음 테이블은 HTTP 상태코드를 정리해 놓은 것이니 참고하면 좋겠다.
클래스코드설명
| 클래스 | 코드 | 설명 |
|---|---|---|
| 1xx | Informational | |
| 100 | Continue | |
| 101 | Switching Protocols | |
| 2xx | Successful | |
| 200 | OK | |
| 201 | Created | |
| 202 | Accepted | |
| 203 | Non-Authoritative Information | |
| 204 | No Content | |
| 205 | Reset Content | |
| 206 | Partial Content | |
| 3xx | Redirect | |
| 300 | Multiple Choices | |
| 301 | Moved Permanently | |
| 302 | Found | |
| 303 | See Other | |
| 304 | Not Modified | |
| 305 | Use Proxy | |
| 307 | Temporary Redirect | |
| 4xx | Client Error | |
| 400 | Bad Request | |
| 401 | Unauthorized | |
| 402 | Payment Required | |
| 403 | Forbidden | |
| 404 | Not Found | |
| 405 | Method Not Allowed | |
| 406 | Not Acceptable | |
| 407 | Proxy Authentication Required | |
| 408 | Request Timeout | |
| 409 | Conflict | |
| 410 | Gone | |
| 411 | Length Required | |
| 412 | Precondition Failed | |
| 413 | Request Entity Too Large | |
| 414 | Request URI Too Long | |
| 415 | Unsupported Media Type | |
| 416 | Requested Range Not Satisfiable | |
| 417 | Expectation Failed | |
| 426 | Upgrade Required | |
| 5xx | Server Error | |
| 500 | Internal Server Error | |
| 501 | Not Implemented | |
| 502 | Bad Gateway | |
| 503 | Service Unavailable | |
| 504 | Gateway Timeout | |
| 505 | Version Not Supported | |
자 그럼 이제 상태코드 메시지에 대해서 하나하나 살펴보도록 하자.
1. Informational (1xx)
100 Continue
클라이언트가 데이터를 서버로 전송하려 하는데, 서버에는 데이터 사이즈에 대한 제약이 걸려있는 상황이다.
이걸 무시하고, 일단 클라이언트가 서버의 제약보다 큰 데이터를 보내게 되면 서버는 이를 처리하지 못하고 에러를 보낸다.
이렇게 되면,
첫째, 클라이언트는 원하는 데이터를 서버로 전송하지 못해서 불쾌하게 되며,
둘째, 네트워크상에는 불필요한 데이터가 전송에 사용되었으므로 이 역시 네트워크 자원측면에서도 손해이다.
클라이언트가 먼저 서버에게 자신이 보내려는 데이터 사이즈가 이정도인데, 처리가 가능한지 묻고 데이터를 보낸다면 위 두가지 문제점들이 해결되게 된다.
먼저, 처리가 불가능하다는 것을 알았기 때문에 불쾌한 결과를 경험하지 않아도 된다.
그리고, 불필요한 데이터 전송을 하지 않으므로 네트워크 자원 사용면에서도 이익이다.
이걸 가능하게 하는것이 "Expect: 100-continue" 헤더를 요청에 포함하여 보내는 것이다.
이에 대한 상세한 동작흐름도나 랩테스트 결과는 이전 강좌 중 Expect 헤더를 다룬 부분에서 이야기 한 적 있다.
Expect 헤더에 대한 상세한 내용은 여기 를 클릭하여 확인토록 하자.
100 Switching Protocols
클라이언트와 서버간 통신하는 프로토콜의 업그레이드가 필요한 경우 Upgrade 헤더를 사용한다는 것을 이전 강좌를 통해 배운적이 있다.
Upgrade 헤더에 대한 서버의 응답메시지에 바로 "100 Switching Protocols" 가 사용된다.
가령, HTTP 로 통신하다가 보안이 적용된 TLS 로 통신프로토콜을 바꾸고자 하는 경우가 이에 해당된다.
Upgrade 헤더에 대한 상세한 내용은 여기 를 클릭하여 확인하자.
2. Successful (2xx)
1. Informational (1xx)
100 Continue
클라이언트가 데이터를 서버로 전송하려 하는데, 서버에는 데이터 사이즈에 대한 제약이 걸려있는 상황이다.
이걸 무시하고, 일단 클라이언트가 서버의 제약보다 큰 데이터를 보내게 되면 서버는 이를 처리하지 못하고 에러를 보낸다.
이렇게 되면,
첫째, 클라이언트는 원하는 데이터를 서버로 전송하지 못해서 불쾌하게 되며,
둘째, 네트워크상에는 불필요한 데이터가 전송에 사용되었으므로 이 역시 네트워크 자원측면에서도 손해이다.
클라이언트가 먼저 서버에게 자신이 보내려는 데이터 사이즈가 이정도인데, 처리가 가능한지 묻고 데이터를 보낸다면 위 두가지 문제점들이 해결되게 된다.
먼저, 처리가 불가능하다는 것을 알았기 때문에 불쾌한 결과를 경험하지 않아도 된다.
그리고, 불필요한 데이터 전송을 하지 않으므로 네트워크 자원 사용면에서도 이익이다.
이걸 가능하게 하는것이 "Expect: 100-continue" 헤더를 요청에 포함하여 보내는 것이다.
이에 대한 상세한 동작흐름도나 랩테스트 결과는 이전 강좌 중 Expect 헤더를 다룬 부분에서 이야기 한 적 있다.
Expect 헤더에 대한 상세한 내용은 여기 를 클릭하여 확인토록 하자.
100 Switching Protocols
클라이언트와 서버간 통신하는 프로토콜의 업그레이드가 필요한 경우 Upgrade 헤더를 사용한다는 것을 이전 강좌를 통해 배운적이 있다.
Upgrade 헤더에 대한 서버의 응답메시지에 바로 "100 Switching Protocols" 가 사용된다.
가령, HTTP 로 통신하다가 보안이 적용된 TLS 로 통신프로토콜을 바꾸고자 하는 경우가 이에 해당된다.
Upgrade 헤더에 대한 상세한 내용은 여기 를 클릭하여 확인하자.
2. Successful (2xx)
200 OK
가장 많이 확인할 수 있는 응답 메시지 코드 중 하나이다. 클라이언트의 요청에 대해 웹서버가 정상적으로 응답한 경우 "200 OK" 를 보낸다.
요청 방식에 따라 200 OK 라는 상태코드와 함께 추가적인 정보가 전달되는데..
가령 GET의 경우 웹서버는 요청한 컨텐츠를 함께 전달하며, HEAD의 경우에는 그렇지 않다.
또한 컨텐츠의 종류 및 인코딩 타입등.. 메시지 바디에 해당되는 엔티티 헤더들도 함께 전달이 된다.
201 Created
클라이언트가 PUT 메소드를 이용하여 웹서버에 어떤 파일을 생성하는 경우, 파일 생성이 정상적으로 잘 되었다면 웹서버는 클라이언트에게 "201 Created" 상태코드를 보낸다.
상태메시지와 함께 Location 헤더에 파일이 생성된 위치정보(URI)를 함께 전달한다.
관련 예제는 우리 PUT 메소드를 다뤘던 이전 강좌에서 확인이 가능하다.
PUT 메소드 관련 강좌는 여기 를 클릭하여 확인할 수 있다.
202 Accepted
클라이언트의 요청을 받았으나 아직 처리는 하지 않는 그런 경우에 반환되는 상태 코드이다.
웹서버가 "응~ 일단 요청은 잘 받았어요.. 이따 정해진 시간에 당신의 요청은 처리됩니다." 라는 의미로 클라이언트에게 응답하는 경우라 할 수 있다.
서버에서 HTTP 의 요청에 대한 처리 동작을 배치형태로 정해진 시간에만 처리하는 경우 이 응답 코드가 사용되어진다.
하지만, 일반적인 인터넷 사용환경에서는 거의 볼 수 없는 응답코드이긴 하다.
203 Non-Authoritative Information
웹서버가 클라이언트의 요청을 정상적으로 처리하여 응답을 주었으나, 중간에 있는 프록시등의 중간 서버에 의해 메시지 바디가 변경되는 경우 반환되는 응답코드이다.
뭐.. 202 Accepted 코드와 마찬가지로 실제 환경에서는 거의 볼수 없는 응답코드이다.
204 No Content
"204 No Content" 상태코드 메시지는 웹서버가 클라이언트의 요청을 정상적으로 처리는 했지만, 응답 해줄 어떤 데이터도 없을 경우 반환되는 코드이다.
다음의 예를 살펴보면 이해가 쉽다.
아래와 같은 웹페이지가 있다고 가정하고..
전기요금 그래프 상태를 5초마다 갱신하고 싶은 경우 체크박스에 체크를 하면 된다.
하지만, 그래프 상태가 연단위라서 체크를 하던 안하던.. 브라우저를 통해 볼수 있는 페이지 정보는 변경이 없다.
클라이언트가 브라우저의 체크박스에 체크를 하게 되면, 이정보를 웹서버에게 전달하게 된다. 웹서버는 클라이언트의 요청을 처리한 후 처리결과를 응답으로 전송한다.
이때, 아래 화면에 포함된 그래프 정보등의 이미지도 같이 보내야 한다.
정보의 변경이 없는 경우에 .. 이런 상황이라면.. 얼마나 불필요한 동작을 수행해야 하는지 느낌이 올것이다.
따라서 이런 경우 클라이언트의 요청을 정상적으로 처리하였다는 메시지만 전달하고, 브라우저에 표시되는 내용 정보들은 기존의 것을 그대로 활용하게 끔 하는 목적에서 사용할 수 있는 상태코드가 필요한데 이게 바로 "204 No Content" 인것이다.
하지만 이 코드도 실제로 사용되는 경우를 본적이 없다.
이론적으로 보면, 참 유용한 동작 같은데..
이런 형태의 동작이 필요한 곳은 주로 어떤 현황을 모니터링 하는 관제쪽에 주로 사용될것 같은데.. 아직 그쪽으로의 지원경험이 거의 없어서 그런가?? ..
암튼.. 잘 알아두자. ^^
205 Reset Content
204 No Content 코드와 유사한 코드이다. 두 상태코드 모두 응답 데이터(메시지 바디)를 포함하지 않는다.
다만, 205 Reset Content 의 경우 일반적으로 웹 입력 폼 중에 Reset 버튼과 같은 역할을 한다고 보면 좋다.
우리가 회원가입등의 절차에 따라 요구되는 입력폼 (주소, 이름, 성별등등)에 내용을 채워나가다가 Reset 버튼을 누르면 입력된 내용이 모두 지워지는 것과 같이 현재의 브라우저에 표시된 Document View를 Reset 하게 된다.
206 Partial Content
우리가 앞서 Range 헤더를 배울때 상태코드로 언급되었던 코드이다.
Range 헤더는 대용량 파일을 클라이언트가 다운로드 하다가 중간에 중단된 경우 이를 이어받기를 원할때 사용되는 헤더이다.
클라이언트가 이어받기를 시도하면 웹서버가 이에 대한 응답코드로 "206 Partial Content" 와 함께 Range 헤더에 명시된 데이터의 부분(byte) 부터 전송을 시작한다.
Range 헤더의 상세한 내용을 알고 싶다면 여기 를 클릭하면 된다.
3. Redirect (3xx)
300 Multiple Choices
클라이언트의 요청에 대해 다른 URI 로 리다이렉트를 하는 것인데, 클라이언트가 선택할 수 있는 리스트를 하나 이상 부여한다.
300 Multiple Choices 상태코드와 함께 리다이렉트 URI 들을 메시지 바디에 담아 응답한다.
301 Moved Permanently
URI 의 변경을 지속적으로 하고 싶은 경우 301 Moved Permanently 상태코드를 전달한다.
이 상태코드를 받게 되는 경우, 클라이언트는 지속적으로 변경된 URI 로 요청을 하게 된다.
302 Found
302 Found 코드는 임시적으로 클라이언트가 새로운 URI 로 접속하게끔 유도한다.
302 Found 코드를 받은 클라이언트는 안내받은 URI로 GET 방식을 사용하여 접속을 시도하게 된다.
다시 말해, POST 요청방식으로 접속을 시도하더라도 302 Found 코드로 인해 리다이렉트가 되면 새로운 URI 접속 시 POST 방식을 다시 사용하지 않고 GET을 사용한다는 의미이다.
303 See Other
302 Found 상태코드와 같이 다른 URI 로 리다이렉트 하는 것은 같으나, 주로 PUT 또는 POST와 같이 클라이언트가 전송하는 데이터를 처리해야 하는 요청방식에 주로 사용된다.
303 See Other 상태코드와 함께 전달되는 Location 헤더의 경로는 완전 새로운 경로가 아닌 현재 요청과 관련된 URI 정보이다.
가령 PUT 또는 POST 를 이용해서 하나의 파일을 업로드 하는 경우 웹서버는 이를 처리하고 있음을 클라이언트에게 알리는 페이지를 보여주고 싶다고 하자.
이 경우 303 See Other 상태코드를 사용할 수 있다.
업로드 요청 URI와 현재 요청된 동작을 처리중이라는 페이지는 전혀 상관없는 페이지가 아니다. 즉 303 See Other 상태코드와 관련되는 URI 정보가 Location 헤더의 값으로 표시되는 것이다.
반면, 302 Found 는 요청 동작과 무관한 새로운 URI 정보가 Location 헤더에 담긴다.
효율적인 내용인 반면. 나로서는 실제로 사용되는 예는 아직 경험해 보진 못했다.
304 Not Modified
캐싱된 컨텐츠를 다시 사용해 된다는 의미를 클라이언트에게 전달하는 상태코드 메시지이다.
클라이언트가 요청헤더에 If-Modified-Since 또는 If-Match 와 같은 조건 내용을 전달하는 경우 웹서버는 이를 확인하여 요청하는 컨텐츠의 변경이 없다고 판단되는 경우 304 Not Modified 메시지를 전달한다.
305 Use Proxy
실제 웹서버가 클라이언트에게 프록시를 사용할 것을 요청하는 응답 상태코드이다.
최초 요청에 한해서만 반환될 수 있는 코드이다.
클라이언트가 요청한 컨텐츠들이 프록시를 경유해야만 정상적인 응답을 할 수 있는 경우 사용되는데, 시중에 있는 대부분의 웹브라우져(파이어폭스, 크롬, IE)들은 보안상의 이유로 이 메시지를 무시하는 경향이 많다.
307 Temporary Redirect
302 Found 상태코드와 동작 방식이 같다.
클라이언트가 요청한 URI에 대해 302 Found 메시지를 받게 되면 메시지와 함께 전달된 응답헤더 Location 의 정보를 참고하여 그 URI 로 접속을 시도한다.
307 Temporary Redirect 도 302 코드와 마찬가지로 Location 헤더의 내용을 참고하여 그쪽으로 새로 접속을 시도하게 된다.
302 코드와 차이가 있다면.. 302 코드는 클라이언트가 POST등과 같이 GET 이 아닌 요청 메소드를 사용해도 결국 Redirect 는 GET으로 하게 되지만, 307 코드는 POST 로 요청한 경우 Redirect 도 POST 방식으로 한다는 데 있다.
오늘은 여기까지 진행한다.
4xx 와 5xx에 대한 내용은 다음 포스팅에 정리하여 올리도록 한다.
4xx 코드의 내용이 많기도 하고, 이번주 업무와 함께 내용을 정리하려 하니 여유가 잘 나지 않는다. 그렇다고 정리가 다될때까지 기다리는 것도 좀 아닌거 같아서...
양해를 부탁드린다.
끝~
가장 많이 확인할 수 있는 응답 메시지 코드 중 하나이다. 클라이언트의 요청에 대해 웹서버가 정상적으로 응답한 경우 "200 OK" 를 보낸다.
요청 방식에 따라 200 OK 라는 상태코드와 함께 추가적인 정보가 전달되는데..
가령 GET의 경우 웹서버는 요청한 컨텐츠를 함께 전달하며, HEAD의 경우에는 그렇지 않다.
또한 컨텐츠의 종류 및 인코딩 타입등.. 메시지 바디에 해당되는 엔티티 헤더들도 함께 전달이 된다.
201 Created
클라이언트가 PUT 메소드를 이용하여 웹서버에 어떤 파일을 생성하는 경우, 파일 생성이 정상적으로 잘 되었다면 웹서버는 클라이언트에게 "201 Created" 상태코드를 보낸다.
상태메시지와 함께 Location 헤더에 파일이 생성된 위치정보(URI)를 함께 전달한다.
관련 예제는 우리 PUT 메소드를 다뤘던 이전 강좌에서 확인이 가능하다.
PUT 메소드 관련 강좌는 여기 를 클릭하여 확인할 수 있다.
202 Accepted
클라이언트의 요청을 받았으나 아직 처리는 하지 않는 그런 경우에 반환되는 상태 코드이다.
웹서버가 "응~ 일단 요청은 잘 받았어요.. 이따 정해진 시간에 당신의 요청은 처리됩니다." 라는 의미로 클라이언트에게 응답하는 경우라 할 수 있다.
서버에서 HTTP 의 요청에 대한 처리 동작을 배치형태로 정해진 시간에만 처리하는 경우 이 응답 코드가 사용되어진다.
하지만, 일반적인 인터넷 사용환경에서는 거의 볼 수 없는 응답코드이긴 하다.
203 Non-Authoritative Information
웹서버가 클라이언트의 요청을 정상적으로 처리하여 응답을 주었으나, 중간에 있는 프록시등의 중간 서버에 의해 메시지 바디가 변경되는 경우 반환되는 응답코드이다.
뭐.. 202 Accepted 코드와 마찬가지로 실제 환경에서는 거의 볼수 없는 응답코드이다.
204 No Content
"204 No Content" 상태코드 메시지는 웹서버가 클라이언트의 요청을 정상적으로 처리는 했지만, 응답 해줄 어떤 데이터도 없을 경우 반환되는 코드이다.
다음의 예를 살펴보면 이해가 쉽다.
아래와 같은 웹페이지가 있다고 가정하고..
전기요금 그래프 상태를 5초마다 갱신하고 싶은 경우 체크박스에 체크를 하면 된다.
하지만, 그래프 상태가 연단위라서 체크를 하던 안하던.. 브라우저를 통해 볼수 있는 페이지 정보는 변경이 없다.
클라이언트가 브라우저의 체크박스에 체크를 하게 되면, 이정보를 웹서버에게 전달하게 된다. 웹서버는 클라이언트의 요청을 처리한 후 처리결과를 응답으로 전송한다.
이때, 아래 화면에 포함된 그래프 정보등의 이미지도 같이 보내야 한다.
정보의 변경이 없는 경우에 .. 이런 상황이라면.. 얼마나 불필요한 동작을 수행해야 하는지 느낌이 올것이다.
따라서 이런 경우 클라이언트의 요청을 정상적으로 처리하였다는 메시지만 전달하고, 브라우저에 표시되는 내용 정보들은 기존의 것을 그대로 활용하게 끔 하는 목적에서 사용할 수 있는 상태코드가 필요한데 이게 바로 "204 No Content" 인것이다.
하지만 이 코드도 실제로 사용되는 경우를 본적이 없다.
이론적으로 보면, 참 유용한 동작 같은데..
이런 형태의 동작이 필요한 곳은 주로 어떤 현황을 모니터링 하는 관제쪽에 주로 사용될것 같은데.. 아직 그쪽으로의 지원경험이 거의 없어서 그런가?? ..
암튼.. 잘 알아두자. ^^
205 Reset Content
204 No Content 코드와 유사한 코드이다. 두 상태코드 모두 응답 데이터(메시지 바디)를 포함하지 않는다.
다만, 205 Reset Content 의 경우 일반적으로 웹 입력 폼 중에 Reset 버튼과 같은 역할을 한다고 보면 좋다.
우리가 회원가입등의 절차에 따라 요구되는 입력폼 (주소, 이름, 성별등등)에 내용을 채워나가다가 Reset 버튼을 누르면 입력된 내용이 모두 지워지는 것과 같이 현재의 브라우저에 표시된 Document View를 Reset 하게 된다.
206 Partial Content
우리가 앞서 Range 헤더를 배울때 상태코드로 언급되었던 코드이다.
Range 헤더는 대용량 파일을 클라이언트가 다운로드 하다가 중간에 중단된 경우 이를 이어받기를 원할때 사용되는 헤더이다.
클라이언트가 이어받기를 시도하면 웹서버가 이에 대한 응답코드로 "206 Partial Content" 와 함께 Range 헤더에 명시된 데이터의 부분(byte) 부터 전송을 시작한다.
Range 헤더의 상세한 내용을 알고 싶다면 여기 를 클릭하면 된다.
3. Redirect (3xx)
300 Multiple Choices
클라이언트의 요청에 대해 다른 URI 로 리다이렉트를 하는 것인데, 클라이언트가 선택할 수 있는 리스트를 하나 이상 부여한다.
300 Multiple Choices 상태코드와 함께 리다이렉트 URI 들을 메시지 바디에 담아 응답한다.
301 Moved Permanently
URI 의 변경을 지속적으로 하고 싶은 경우 301 Moved Permanently 상태코드를 전달한다.
이 상태코드를 받게 되는 경우, 클라이언트는 지속적으로 변경된 URI 로 요청을 하게 된다.
302 Found
302 Found 코드는 임시적으로 클라이언트가 새로운 URI 로 접속하게끔 유도한다.
302 Found 코드를 받은 클라이언트는 안내받은 URI로 GET 방식을 사용하여 접속을 시도하게 된다.
다시 말해, POST 요청방식으로 접속을 시도하더라도 302 Found 코드로 인해 리다이렉트가 되면 새로운 URI 접속 시 POST 방식을 다시 사용하지 않고 GET을 사용한다는 의미이다.
303 See Other
302 Found 상태코드와 같이 다른 URI 로 리다이렉트 하는 것은 같으나, 주로 PUT 또는 POST와 같이 클라이언트가 전송하는 데이터를 처리해야 하는 요청방식에 주로 사용된다.
303 See Other 상태코드와 함께 전달되는 Location 헤더의 경로는 완전 새로운 경로가 아닌 현재 요청과 관련된 URI 정보이다.
가령 PUT 또는 POST 를 이용해서 하나의 파일을 업로드 하는 경우 웹서버는 이를 처리하고 있음을 클라이언트에게 알리는 페이지를 보여주고 싶다고 하자.
이 경우 303 See Other 상태코드를 사용할 수 있다.
업로드 요청 URI와 현재 요청된 동작을 처리중이라는 페이지는 전혀 상관없는 페이지가 아니다. 즉 303 See Other 상태코드와 관련되는 URI 정보가 Location 헤더의 값으로 표시되는 것이다.
반면, 302 Found 는 요청 동작과 무관한 새로운 URI 정보가 Location 헤더에 담긴다.
효율적인 내용인 반면. 나로서는 실제로 사용되는 예는 아직 경험해 보진 못했다.
304 Not Modified
캐싱된 컨텐츠를 다시 사용해 된다는 의미를 클라이언트에게 전달하는 상태코드 메시지이다.
클라이언트가 요청헤더에 If-Modified-Since 또는 If-Match 와 같은 조건 내용을 전달하는 경우 웹서버는 이를 확인하여 요청하는 컨텐츠의 변경이 없다고 판단되는 경우 304 Not Modified 메시지를 전달한다.
305 Use Proxy
실제 웹서버가 클라이언트에게 프록시를 사용할 것을 요청하는 응답 상태코드이다.
최초 요청에 한해서만 반환될 수 있는 코드이다.
클라이언트가 요청한 컨텐츠들이 프록시를 경유해야만 정상적인 응답을 할 수 있는 경우 사용되는데, 시중에 있는 대부분의 웹브라우져(파이어폭스, 크롬, IE)들은 보안상의 이유로 이 메시지를 무시하는 경향이 많다.
307 Temporary Redirect
302 Found 상태코드와 동작 방식이 같다.
클라이언트가 요청한 URI에 대해 302 Found 메시지를 받게 되면 메시지와 함께 전달된 응답헤더 Location 의 정보를 참고하여 그 URI 로 접속을 시도한다.
307 Temporary Redirect 도 302 코드와 마찬가지로 Location 헤더의 내용을 참고하여 그쪽으로 새로 접속을 시도하게 된다.
302 코드와 차이가 있다면.. 302 코드는 클라이언트가 POST등과 같이 GET 이 아닌 요청 메소드를 사용해도 결국 Redirect 는 GET으로 하게 되지만, 307 코드는 POST 로 요청한 경우 Redirect 도 POST 방식으로 한다는 데 있다.
오늘은 여기까지 진행한다.
4xx 와 5xx에 대한 내용은 다음 포스팅에 정리하여 올리도록 한다.
4xx 코드의 내용이 많기도 하고, 이번주 업무와 함께 내용을 정리하려 하니 여유가 잘 나지 않는다. 그렇다고 정리가 다될때까지 기다리는 것도 좀 아닌거 같아서...
양해를 부탁드린다.
끝~
댓글 없음:
댓글 쓰기