HTTP 응답코드 [에러코드]

Network 2008. 11. 8. 16:04 |

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

:

[JEUS] WebtoB, JEUS 라이센스 확인법

JEUS 2008. 11. 5. 03:29 |

1. WebtoB License 확인법

  1) wsadmin -i <license.dat 파일의 절대 경로>

C:\>wsadmin -i C:\TmaxSoft\WebtoB4.1\license\license.dat
        ###############################################
          License Information (file: C:\TmaxSoft\WebtoB4.1\license\license.dat)
        ###############################################
License seqno: WDE-1224-462-0712
License issue date: 2008/10/20
License type: DEMO
        Expiration date: 2008/12/19
Edition: Enterprise
License check by hostname: nana
Unlimited license
C:\>


  2) wsadmin 접속하여 wi 명령어로 확인

C:\>wsadmin
--- Welcome to WebtoB Admin (Type "quit" to leave) ---
$$1 nana (wsadm): wi
WebtoB Enterprise System Info: DEMO version 4.1 SP 1 Fix #2 20071108/WINDOWS_I386:
         expiration date = 2008/12/19
         maxuser = UNLIMITED,
         node_count = 1,
         svgrpcount = 2,
         svr_count = 2, svc_alloc_count = 512
         cousin_groupcount = 0, cousin_elemcount = 0
         backup_groupcount = 0, backup_elemcount = 0
WebtoB All Node Info: node_count = 1:
--------------------------------------------------------------------------
  no   name     nodeport  racport  shmkey  shmsize  hth
--------------------------------------------------------------------------
   0   nana       7777     3333    54000    37472     1
$$2 nana (wsadm): q
ADM quit for node (nana)
C:\>

2. JEUS License 확인법

  1) jeusadmin -licenseinfo
  2) jeusadmin -licensedue

C:\>jeusadmin -licenseinfo
=================== JEUS LICENSE INFORMATION ===================
=== EDITION : Enterprise (Trial License)
================================================================
C:\>jeusadmin -licensedue
Unlimited
C:\>
:

[JEUS4,5] Thread Hang 발생시 조치 방법

JEUS 2008. 11. 4. 13:49 |
1.  webadmin에서 ti 정보로 hang 현상 확인
 
                JEUS 4.x : webadmin <서블릿엔진명> -U<admin계정> -P<admin암호>
                JEUS 5 : webadmin <컨테이너명> -U<admin계정> -P<admin암호>
 
예) webadmin tmaxi2_servlet_enigne1 –Uadministrator –Pjeusadmin
                위와 같이 실행 하면 webadmin console tool로 들어가게 된다.
 
webadmin 명령중에 ti 명령을 치게 되면 아래와 같이 JEUS WebContainer에서 수행중인 WorkerThread가어떤 Application을 수행 중 인지를 확인 할 수 있다.  Webadmin을 통해 Thread Hang 현상을 확인 할 수 있다.
 
$$47 [tmaxi2:engine1] ti
        >>>>>>>> tmaxi2_servlet_engine1 <<<<<<<<
-- Thread State [http1-hth0(localhost:7900)] --
[http1-hth0(localhost:7900)-w0][waiting, wt=57409 ms]
[http1-hth0(localhost:7900)-w1][active , rt=23026 ms, uri=/test.jsp]
[http1-hth0(localhost:7900)-w2][waiting, wt=57139 ms]
[http1-hth0(localhost:7900)-w3][waiting, wt=57183 ms]
[http1-hth0(localhost:7900)-w4][waiting, wt=57079 ms]
[http1-hth0(localhost:7900)-w5][waiting, wt=57093 ms]
[http1-hth0(localhost:7900)-w6][waiting, wt=57071 ms]
[http1-hth0(localhost:7900)-w7][waiting, wt=57078 ms]
[http1-hth0(localhost:7900)-w8][waiting, wt=57074 ms]
[http1-hth0(localhost:7900)-w9][waiting, wt=57080 ms]
[http1-hth0(localhost:7900)-w10][waiting, wt=57184 ms]
[http1-hth0(localhost:7900)-w11][waiting, wt=57076 ms]
[http1-hth0(localhost:7900)-w12][waiting, wt=57174 ms]
[http1-hth0(localhost:7900)-w13][waiting, wt=57144 ms]
[http1-hth0(localhost:7900)-w14][waiting, wt=57150 ms]
[http1-hth0(localhost:7900)-w15][waiting, wt=57144 ms]
[http1-hth0(localhost:7900)-w16][waiting, wt=57094 ms]
[http1-hth0(localhost:7900)-w17][waiting, wt=57094 ms]
[http1-hth0(localhost:7900)-w18][waiting, wt=57094 ms]
[http1-hth0(localhost:7900)-w19][waiting, wt=57155 ms]
[total : 20    active : 1    idle : 19    blocked : 0    reconnecting : 0]
 
 
위 webadmin ti 정보로는 20개의 WorkerThread중 w1 Thread가 23초 정도 수행중인 비 정상적 상황임을 알 수 있다. active는 수행 중, waiting은 요청 대기중인 상태를 의미한다.
 
위에서 Hang 현상 발생되고 있는 thread는 w1 Thread이다.
 
2. Dump를 뜨기 위한 WebContainer PID를 얻어내기 위한 방법
 
                        jeusadmin <호스트이름> -U<admin계정> -P<admin암호>
 
예) jeusadmin tmaxi2  –Uadministrator –Pjeusadmin
 
tmaxi2:/user/jichung/jeus40/bin>jeusadmin tmaxi2  –Uadministrator –Pjeusadmin
[ErrorMsgManager] Message Manager is initialized
[JeusCommander] JEUS 4.0.4.8 Jeus Manager Controller
tmaxi2>pidlist
tmaxi2_container1 : 18842
tmaxi2>
 
위의 방법으로 Container PID를 알아 낸 후
 
            Unix Machine의   경우 :   kill –3 <ContainerPID>
 
            Windows 계열의 경우 : jeus를 실행시킨 console창에서 CTRL + Break
 
위의 작업을 수행후 Dump Log가 $JEUS_HOME/logs/JeusServer_<날짜>.log에 쌓이게 된다.
(IBM Machine의 경우엔 jeus를 실행 시킨 디렉토리에 javacore.<pid>.<시간>.txt file로 남게 된다.)
 
아래는 w1 thread에서 수행중인 test.jsp 내부적으로 수행중인 것을 Dump로 확인한 내용이다.
 
"http1-hth0(localhost:7900)-w1" (TID:0x30096a88, sys_thread_t:0x35c0add8, state:C
W, native ID:0x2128) prio=5
        at java.lang.Thread.sleep(Native Method)
        at jeus_jspwork._403_test._jspService(_403_test.java:43)
        at jeus.servlet.jsp.HttpJspBase.service(HttpJspBase.java:54)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:269)
        at jeus.servlet.jsp.JspServletWrapper.executeServlet(JspServletWrapper.java:5
2)
        at jeus.servlet.engine.ServletWrapper.execute(ServletWrapper.java:129)
        at jeus.servlet.servlets.JspServlet.execute(JspServlet.java:71)
        at jeus.servlet.engine.WebtobRequestProcessor.run(WebtobRequestProcessor.java
(Compiled Code))
 
위의 test.jsp는 임의로 Thread.sleep Method를 수행한 것이지만
실제 Application상에서 수행 중 멈춰 더 이상 진행 되고 있지 않은 Method들을 확인 함으로서
장애 상황에 대한 중요한 정보를 얻을 수 있다.
:

티스토리툴바