상태코드번호 | 메세지 | 설명 |
---|---|---|
100 |
Continue |
클라이언트로부터 일부 요청을 받았으니 나머지 요청 정보를 계속 보내 달라는 것. |
101 |
Switching Protocols |
서버는 클라이언트의 요청대로 Upgrade 헤더를 따라 다른 프로토콜로 바꿀 것임 |
200 |
Ok |
모든 것이 정상적임. |
201 |
Created |
서버에서 문서를 만들었음. Location 헤더는 그 URL을 가리키는 것임. |
202 |
Accepted |
요청이 수행되었지만 처리는 끝나지 않았음 |
203 |
Non-Authoritative Information |
문서는 정상적으로 반환되었지만 복사본이 사용되었으므로 응답 헤더중 일부가 정확하지 않을 수 도 있음 |
204 |
No Content |
이것은 사용자가 페이지를 주기적으로 리로드를 하던 중 이전 페이지가 이미 만료되었을 때 사용할 수 있다. 하지만 Refresh 응답 헤더나 같은 헤더를 사용 해서 페이지를 자동으로 리로드 시켰을 때는 동작하지 않는다. 왜냐하면 이 상태 코드를 반환하면 추후의 리로딩이 멈추기 때문이다. 만 자바 스크립트로 리로드하게 해 주는 것은 작동한다. |
205 |
Reset Content |
새 문서 없음. 하지만 브라우저는 문서 창을 리셋해야 한다. 브라우저가 CGI 폼 필드를 전부 지우도록 할 때 사용 된다 |
206 |
Partial Content |
클라이언트가 Range 헤더와 함께 요청의 일부분을 보냈고 서버는 이를 수행했음 |
300 |
Multiple Choices |
모든 문서들을 나열할 것이다. 만약 서버가 선호하는 선택이 있으면 Location 응답 헤더에 나열해야 한다 |
301 |
Moved Permanently |
요청된 문서는 어딘가에 있고 그 문서에 대한 URL은 Location 응답 헤더에 주어졌음. 브라우저는 자동적으로새 URL의 링크를 따라가야 한다 |
302 |
Found |
301과 비슷하지만 새 URL은 임시 저장 장소로 해석된다. 이 메시지는 HTTP 1.0에서는 ‘Moved Temporarily’였다. 그리고 HttpServletResponse의 상수는 SC_FOUND가 아니라 SC_MOVED_TEMPORARILY다. 이것은 매우 유용한 헤더인데 이 헤더를 통해 브라우저가 자동적으로 새 URL의 링크를 따라가기 때문이다. 이 상태 코드는 아주 유용하기 때문에 이 상태 코드를 위해 sendRedirect 라는 특별한 메소드가 있다. response.sendRedirect(url)을 사용하는 것은 response.setStatus(response.SC_MOVED_TEMPORARILY)과 response.setHeader(“Location”, url)를 쓰는 것에 비해 몇 가지 장점이 있다. 첫째, 더 쉽게 사용할 수 있다. 둘째, sendRedirect을 써서 서블릿이 그 링크를 포함한 페이지를 자동으로 만들어 준다(자동으로 redirect를 따라갈 수 없는 오래 된 브라우저에서도 볼 수 있게 해 준다). 마지막으로, sendRedirect에서는 상대 URL이 절대 URL로 해석되기 때문에 상대 URL도 다룰 수 있다. 이 상태 코드는 종종 301번과 혼용된다. 예를 들어 (맨 마지막에 ‘/’이 빠짐)과 같이 오류가 있는 요청에 대해 어떤 서버는 301을 어떤 서버는 302 를 보낸다. 기술적으로 브라우저는 원 요청이 GET이었다면 자동적으로 리다이렉션을 따라 가도록 되어 있다. 더 자세한 사항은 307 헤더를 보세요 |
303 |
See Other |
301/302과 같지만 원래 요청이 POST였을 경우 리다이렉트 되는 문서(Location 헤더에 주어졌다) GET을 통해 받아야 한다. |
304 |
Not Modified |
클라이언트의 캐시에 이 문서가 저장되었고 선택적인 요청에 의해 수행됨(보통 지정된 날짜보다 더 나중의 문서만을 보여주도록 하는 If-Modified-Since 헤더의 경우). 서버는 클라이언트에게캐시에 저장된 이전 문서를 계속 사용해야 한다고 말할 것이다 |
305 |
Use Proxy |
된 문서는 Location 헤더에 나열된 프록시를 통해 추출되어야 함. |
307 |
Temporary Redirect |
302 (“Found” 또는 “Temporarily Moved”)와 같다. 많은 브라우저에서 메시지가 POST일 때 원래는 303 응답의 POST 요청의 리다이렉션을 따라 가야 함에도 불구하고 302의 응답을 따르기 때문에 HTTP 1.1에서 추가되었다. 303 응답은 모호하지 않도록 의도되었다. 303 응답의 경우에 대해서는 리다이렉트 된 GET과 POST 요청을 따르고 307 응답의 경우에는 GET 요청만 따른다. 몇 가지 이유로 HttpServletResponse에는 이 상태코드에 해당하는 상수가 없다. |
400 |
Bad Request |
요청에 문법적으로 잘못된 부분이 있음. |
401 |
Bad Request |
클라이언트가 올바른 허가를 받지 않고 허가가 필요한 페이지에 접근하려 함. 여기에 대한 응답으로 브라우저가 대화창을 열어 사용자 이름과 암호를 받아들이도록 하는 WWW-Authenticate 헤더를 포함해야 한다. |
403 |
Forbidden |
사용 권한에 관계없이 내용을 볼 수 없음. 종종 파일 이름이 잘못되었거나 서버의 디렉터리퍼미션이 잘못 되었을 때 나온다. |
404 |
Not Found |
이 주소에서는 어떤 내용도 발견할 수 없음. 이것은 표준 ‘no such page’응답이다. 이 상태 코드는 아주 일반적인 응답이다. 그래서 이 상태코드를 위한 HttpServletResponse:sendError(message)라는 특별한 메소드가 있다. sendError는 serStatus에 비해 에러 메시지를 보여주는 에러 페이지를 자동적으로 만들어 준다는 장점이 있다. |
405 |
Method Not Allowed |
요청 메소드(GET, POST, HEAD, DELETE, PUT, TRACE 등) 를 특정 자원에 대해서는 쓸 수 없음. |
406 |
Not Acceptable |
지정된 자원이 클라이언트의 Accept 헤더에 명시된 것과 호환 되지 않는 MIME content-type을 생성함. |
407 |
Proxy Authentication Required |
401과 비슷하지만 서버가 Proxy-Authenticate 헤더를 반환해야 한다. |
408 |
Request Timeout |
클라이언트가 요청을 보내는 데 너무 오랜 시간이 걸림. |
409 |
Conflict |
보통 PUT 요청과 관계 있다. 보통 틀린 버전의 파일을 업로드할 경우 발생한다. |
410 |
Gone d> |
문서가 사라졌고 포워딩할 주소도 없음. 404와 다른 점은 이 경우 문서가 완전히 사라졌다는 것을서버가 안다는 점이다. 404는 어떤 이유인지는 모르는데 단지 요청한 것을 사용할 수 없다는 것을 의미한다. |
411 |
Length Required |
클라이언트가 Content-Length를 보내지 않으면 서버가 처리할 수 없음. |
412 |
Precondition Failed |
요청 헤더에 설정되어 있는 어떤 조건이 맞지 않음. |
413 |
Request Entity Too Large |
요청된 문서가 현재 서버가 다룰 수 있는 크기보다 큼. 만약 서버에서 나중에 다룰 수 있다고 생각되면 Retry-After 헤더를 포함시켜야 한다.(HTTP 1.1에서 새로 등장) |
414 |
Request URI Too Long |
URI가 너무 길다 |
415 |
Unsupported Media Type |
요청이 알려지지 않은 형태임 |
416 |
Requested Range Not Satisfiable |
클라이언트가 요청에 적당하지 않은 Range 헤더를 포함시켰음 |
417 |
Expectation Failed |
Expect 요청 헤더의 값이 맞지 않음 |
500 |
Internal Server Error |
일반적인 ‘server is confused’ 메시지. 종종 CGI 프로그램이나 서블릿의 결과가 잘못되거나 적절하지 않은 헤더를 만들었을 때 발생한다. |
501 |
Not Implemented |
요청한 것을 서버에서 지원하지 않음. 예를 들면 클라이언트가 서버에서 지원하지 않는 PUT과 같은 명령을 내렸을 때 발생한다. |
502 |
Bad Gateway |
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 부적절한 응답을 받았음을 나타낸다. |
503 |
Service Unavailable |
처리할 수 있는 한계를 벗어나 과도하게 요청이 들어와서 서버가 응답할 수 없음. 예를 들면 스레드나 데이터베이스 연결이 가득 차 있을 때 서블릿에서 이런 헤더를 반환한다. 서버는 Retry-After 헤더를 낼 수 있다. |
504 |
Gateway Timeout |
프록시나 게이트웨이의 역할을 하는 서버에서 볼 수 있다. 초기 서버가 원격 서버로부터 응답을 받을 수 없음을 나타낸다 |
505 |
HTTP Version Not Supported |
서버가 요청 라인에 지정된 HTTP 버전을 지원하지 않음. |
답글 남기기