Tomcat서버 로그정리

WebService/Tomcat 2019. 10. 16. 13:22

톰켓에 로그 파일이 복잡하게 생성되어 관리가 복잡합니다.

관련해서 운영에 필요한 정보만(catalina.out 1개 파일만 관리) 생성하도록 처리하는 방법입니다.

 

** 기관에 납품하기전 관련내용 확인 후 변경여부 결정하시기 바랍니다. **

 

 

** handlers 관련 변경하고 나머지 모두 주석처리

# vi $CATALINA_HOM/conf/logging.properties

    handlers = java.util.logging.ConsoleHandler
    .handlers = java.util.logging.ConsoleHandler

    #handlers = 1catalina.org.apache.juli.FileHandler, 2localhost.org.apache.juli.FileHandler, 3manager.org.apache.juli.FileHandler, 4host-    manager.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
    #
    #.handlers = 1catalina.org.apache.juli.FileHandler, java.util.logging.ConsoleHandler
    #
    #############################################################
    ## Handler specific properties.
    ## Describes specific configuration info for Handlers.
    #############################################################
    #
    #1catalina.org.apache.juli.FileHandler.level = FINE
    #1catalina.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
    #1catalina.org.apache.juli.FileHandler.prefix = catalina.
    #
    #2localhost.org.apache.juli.FileHandler.level = FINE
    #2localhost.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
    #2localhost.org.apache.juli.FileHandler.prefix = localhost.
    #
    #3manager.org.apache.juli.FileHandler.level = FINE
    #3manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
    #3manager.org.apache.juli.FileHandler.prefix = manager.
    #
    #4host-manager.org.apache.juli.FileHandler.level = FINE
    #4host-manager.org.apache.juli.FileHandler.directory = ${catalina.base}/logs
    #4host-manager.org.apache.juli.FileHandler.prefix = host-manager.
    #
    #java.util.logging.ConsoleHandler.level = FINE
    #java.util.logging.ConsoleHandler.formatter = java.util.logging.SimpleFormatter
    #
    #
    #############################################################
    ## Facility specific properties.
    ## Provides extra control for each logger.
    #############################################################
    #
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].level = INFO
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].handlers = 2localhost.org.apache.juli.FileHandler
    #
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].level = INFO
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/manager].handlers = 3manager.org.apache.juli.FileHandler
    #
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].level = INFO
    #org.apache.catalina.core.ContainerBase.[Catalina].[localhost].[/host-manager].handlers = 4host-manager.org.apache.juli.FileHandler
    #
    ## For example, set the org.apache.catalina.util.LifecycleBase logger to log
    ## each component that extends LifecycleBase changing state:
    ##org.apache.catalina.util.LifecycleBase.level = FINE
    #
    ## To see debug messages in TldLocationsCache, uncomment the following line:
    ##org.apache.jasper.compiler.TldLocationsCache.level = FINE

 

 

** Valve 부분 주석처리

# vi $CATALINA_HOME/conf/Catalina/localhost/ROOT.xml

    <?xml version='1.0' encoding='utf-8'?>
    <Context docBase="/usr/local/jakarta/nextbsc/WebRoot" path="/" reloadable="true" antiResourceLocking="false" antiJARLocking="false">
        <Loader delegate="false"/>
        <!-- <Valve className="org.apache.catalina.valves.AccessLogValve" prefix="localhost_access_log." suffix=".txt" pattern="common"/>-->
        <Resource name="jdbc1/dbms" auth="Container" description="DB Connection"
                type="javax.sql.DataSource"
                factory="org.apache.commons.dbcp.BasicDataSourceFactory"
                driverClassName="com.tmax.tibero.jdbc.TbDriver"
                url="jdbc:tibero:thin:@DB:8629:NEXTBSC"
                username="xxxxx"
                password="xxxxx"
                maxActive="100"
                initialSize="30"
                maxIdle="30"
                minIdle="30"
                maxWait="-1"
                validationQuery="SELECT 1 FROM DUAL"
                testOnBorrow="true"
                testOnReturn="false"
                testWhileIdle="false"
                timeBetweenEvictionRunsMillis="60000"
                numTestsPerEvictionRun="5"
                minEvictableIdleTimeMillis="3600000"
        />

        :
        :
        :
    </Context>

 

** catalina.out 파일만 존재여부 확인

# ls $CATALINA_HOME/logs

저작자표시
블로그 이미지

유효하지않음

,

Tomcat에서 POST 전송시 용량문제 발생 처리방법

WebService/Tomcat 2019. 10. 16. 13:13

서버 전송 용량 처리가 설정되어 있지 않으면 Tomcat의 경우 POST 기본 전송 용량은

2MB(우리가 알고 있는 그... 아닙니다.) 입니다. 용량이 큰 HWP 파일의 경우 2MB 이상

될 수 있어 전송시 문제가 발생할 수 있습니다.



$CATALINA_HOME/conf/server.xml 설정 파일의 파라미터 수정


** 변경전 Tomcat 8.x **

<Service name="Catalina">
   <Connector port="80"   protocol="HTTP/1.1" connectionTimeout="200000" redirectPort="8443"
              URIEncoding="MS949" allowLinking="true" allowTrace="false" disableUploadTimeout="true"/>
   <Connector port="8011" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
   <Connector port="8009" protocol="AJP/1.3"  connectionTimeout="20000" redirectPort="8443" />
   <Connector port="8009" protocol="AJP/1.3"  redirectPort="8443" />



** 변경후 Tomcat 8.x **

<Service name="Catalina">
   <Connector port="80"   protocol="HTTP/1.1" connectionTimeout="200000" redirectPort="8443"
              URIEncoding="MS949" allowLinking="true" allowTrace="false"
              disableUploadTimeout="true" maxPostSize="60000000"/>  <!-- 약 57MB 제한 -->
   <Connector port="8011" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" maxPostSize="-1"/> <!-- 무제한 -->
   <Connector port="8009" protocol="AJP/1.3"  connectionTimeout="20000" redirectPort="8443" maxPostSize="-1"/> <!-- 무제한 -->
   <Connector port="8009" protocol="AJP/1.3"  redirectPort="8443" maxPostSize="-1"/> <!-- 무제한 -->

 


** 주의 ** 

 - Tomcat 7.0.63 미만 : maxPostSize="0"  무제한
 - Tomcat 7.0.63 이상 : maxPostSize="-1" 무제한

저작자표시
블로그 이미지

유효하지않음

,

서버 이중화 구성도 비교(상용 vs 오픈소스)

WebService 2019. 6. 28. 18:09

 ** ClusterPlex
   - 장점
      ˚오픈소스(drbd)를 기반을 둔 상용 클러스터 제품
      ˚운영 테스트 완료된 제품
      ˚유지 관리를 쉽게 할 수 있도록 GUI 모니터링 툴 제공
      ˚제조사 전문 유지관리 인력이 존재함(유지보수 감소)

   - 단점
      ˚Active <-> Standby 구조만 사용할 수 있어 부하분산(LB)에 부적합
      ˚Failover 감지후 Standby -> Active 전환시 30초~60초이상 Downtime 발생 이슈(503 Service Unavailable 확인됨)
      ˚상당한 비용발생 


 ** OpenSource HA
   - 장점
      ˚부하분산(LB)에 적합함
      ˚Failover시 실시간 무정지 서비스가 가능함
      ˚오픈소스이고 프리 라이센스여서 비용이 발생하지 않음

   - 단점
      ˚운영 관리가 상대적으로 힘들 수 있음
      ˚전문 유지관리 업체 부재(유지보수 증가)
      ˚운영 테스트 부족(내부 운영자)

 

 

Split Brain 이란?
  시스템의 두 부분 이상이 독립적으로 진행되어 시스템이 일관되지 않게 동작하는 것을 말한다.
  분산 시스템에서 마스터-슬레이브 상태에서 네트워크 이상으로 인해 슬레이브는 마스터가 이상이 있다고 판단한다. 
  때로는 맞을 수도 있고 때로는 오탐일 수도 있다. 만약 잘못된 판단임에도 슬레이브 중 하나가 마스터로 선출이 되면
  두 개의 마스터가 존재하게 된다.  이런 경우를 Split Brain 스플릿 브레인이라고 부른다.

  Cluster내에 2개의 노드(node1, node2) 만 남아 있는 상황
  node1-2 사이에 네트워크 장애 발생, 2개의 노드에서 동일하게 데이터베이스가 정상작동하지 않음
  (접속은 되나 use, select 등 기본 동작 불가)
  Cluster 내의 Master 노드 정족수가 부족(과반수를 초과해야 하나, quorom=1/2)하게 되기 때문
  (이러한 한계를 무시하는 설정도 있고, 노드를 흉내내 주는 대안적 방법으로 garbd(Galera Arbiter로 2개 노드일 때   
   quorom 값을 +1 증가시켜 줌)  를 쓰는 방법도 있으나, 좋은 방법은 아님.

저작자표시
블로그 이미지

유효하지않음

,

Tomcat 구동 시 /dev/urandom 블로킹 이슈(지연시작 문제)

WebService/Tomcat 2019. 6. 28. 17:48

톰켓 구동 시 멈춤(지연 10분 이상) 현상이 발생하여 찾아보던중 

 

블로킹 이슈문제가 있네요.

 

해결방법 #1 (O/S별 환경변수 설정)

 ** Linux
    # vi /etc/profile.d/java.sh 또는 vi /etc/bashrc
 
      JAVA_OPTS="$JAVA_OPTS -Djava.security.egd=file:/dev/./urandom"


 ** Windows
      내컴퓨터 > 고급 시스템 설정 > 고급 > 환경 변수(N).. > 시스템 변수(S) > 새로 만들기(W).. 
 
      변수 이름(N) : JAVA_OPTS
      변수 값(V)   : %JAVA_OPTS% -Djava.security.egd=file:/dev/./urandom
 
 
해결방법 #2 (공통)

 ** java.security 파일 추가 및 수정

   jdk 8 이하 : $JAVA_HOME/jre/lib/security/java.security
   jdk 9 이상 : $JAVA_HOME/conf/security/java.security

   securerandom.source=file:/dev/./urandom

 

자바 버그로 인해 /dev/urandom 을 인식하지 못하고 /dev/./urandom 으로 처리해야 함.

 

 

 

참고 : https://lng1982.tistory.com/261

저작자표시
블로그 이미지

유효하지않음

,

coldfusion8과 apache 2.4 연결문제 처리방법 (mod_jrun22.so 문제)

WebService/ColdFusion 2018. 10. 11. 10:18

coldfusion 8의 경우는 apache 2.2까지만 지원하는 컨넥터를 제공합니다.

현재까지 최신 버전인 apache 2.4와 연결을 위해서는 컨넥터(mod_jrun22.c)의 연결 함수명 변경처리와

mod_jrun22.c를 재컴파일 해야됩니다.



[참조] apache 2.4를 CentOS yum(rpm) 또는 해당 O/S별 패키지 관리자로 설치했다면 아래 링크를 참조

        https://g0blin.co.uk/mod_jrun-on-apache-2-4-ubuntu-14-04-coldfusion-9/



[참조] apache 2.4를 소스 컴파일시 설치 방법


** 설치환경

    - CentOS 7.1804

    - coldfusion 8 : /opt/coldfusion

    - apache 2.4   : /usr/local/apache



** apache lib 추가(추가하지 않아도 컴파일시 문제는 없었음)

    # vi /etc/ld.so.conf.d/apache.conf

        /usr/local/apache/lib

        /usr/local/apache/lib/apr-util-1


    # ldconfig



** mod_jrun22.c --> mod_jrun24.c 변경후 컴파일 

    -- 소스 패키지 파일 압축을 풀기위해 임시 디렉토리 생성 

    # mkdir /opt/wsconfig

 

    -- 소스 패키지 파일 임시 디렉토리에 복사

    # cp /opt/coldfusion8/runtime/lib/wsconfig.jar /opt/wsconfig


    -- 임시 디렉토리 이동

    # cd /opt/wsconfig


    -- 소스 패키지 압축풀기

    # unzip wsconfig.jar


    -- 컨넥터 소스 디렉토리 이동

    # cd connectors/src


    -- apache 2.4 컨넥터 파일명으로 변경처리

    # cp mod_jrun22.c mod_jrun24.c


    -- apache 2.4 펑션명으로 변경처리

    # sed -i 's/remote_addr/client_addr/g' mod_jrun24.c


    -- apxs(APache eXtenSion 도구) 확장모듈을 이용한 컴파일 

    # /usr/local/apache/bin/apxs -ic -n jrun mod_jrun24.c \

        jrun_maptable_impl.c \

        jrun_property.c \

        jrun_session.c \

        platform.c \

        jrun_mutex.c \

        jrun_proxy.c \

        jrun_utils.c


    -- 컴파일 완료시 coldfusion lib 디렉토리로 mod_jrun24.so 이동시킴

    # mv /usr/lib/apache/modules/mod_jrun24.so /opt/coldfusion8/runtime/lib/wsconfig/1/


    -- httpd.conf의 jrun 컨넥터 환경변경 처리

    # find /usr/local/apache/conf/httpd.conf -type f -exec sed -i 's/mod_jrun22/mod_jrun24/g' {} +


    -- hjttpd.conf 추가된 내용 또는 변경된 내용 확인

    # vi /usr/local/apache/conf/httpd.conf

        LoadModule jrun_module /opt/coldfusion8/runtime/lib/wsconfig/1/mod_jrun24.so

        <IfModule mod_jrun24.c>

            JRunConfig Verbose false

            JRunConfig Apialloc false

            JRunConfig Ignoresuffixmap false

            JRunConfig Serverstore /opt/coldfusion8/runtime/lib/wsconfig/1/jrunserver.store

            JRunConfig Bootstrap 127.0.0.1:51800

            AddHandler jrun-handler .jsp .jws .cfm .cfml .cfc .cfr .cfswf

        </IfModule>



저작자표시
블로그 이미지

유효하지않음

,

Jeus 온나라 보고문서/메모보고 인터페이스 관련

WebService/JEUS 2015. 6. 17. 14:18

온나라 연계시 기존 WebLogic서버와는 문제없이 서비스 연동이 되었는데

서버가 Jeus인경우 문제점이 발생하였음.

해서 온나라헬프데스크에 문의했는데 Jeus전용 클라이언트 lib(jar)파일을 사용해야 된다더군요

(잘 모르셔서 하는이야기 겠죠..?!!)


아무튼 Tmax에서 도움을 받았지만 사실 많은 도움되지 않네요~~~.(어차피 유지보수 role은 아니니...)

Jeus쪽 lib를 하나하나 압축을 풀어보면 Apache Axis 1.x를 사용하는걸로 확인 되고....


음..... 점검사항만 간단히 기록 하겠습니다.


1. wsdl을 이용해서 ant로 패키징 완료(문제 없어야 됨)

2. weblogic 의 경우와 다르게 서버가 jeus면 package path 및 class명이 변경됩니다.


3.1 Tomcat lib쪽 등록(Jeus 5 Fix 27 서버가 제우스인 경우)

     jaxb-api.jar

     jaxb-impl.jar

     jaxb-libs.jar

     jeus.jar

     jeusjaxb.jar

     jeusutil.jar

   추가 Lib

     FastInfoset-1.2.9.jar

     mail.jar


  서비스 호출시  : QName qname = new QName("http://hamoni.mogaha.go.kr/bms", "BmsSifComServiceIFPort");

  핸들러 파일 다운로드시 : operElement.getElementQName().getLocalPart().endsWith("getExchangeFileReturn")


3.2  Tomcat lib쪽 또는 WebRoot/WEB-INF/lib쪽 (Weblogic 8.x 서버가 웹로직인 경우)

     weblogic.jar

     webserviceclient.jar

     webservices.jar

  서비스 호출시 : QName qname = new QName("http://hamoni.mogaha.go.kr/bms", "BmsSifComServicePort");

  핸들러 파일 다운로드시 : operElement.getElementName().toString().endsWith("getExchangeFileResponse")


6. 운영 구성은 아래와 같으나 개발PC에서도 문제없이 작도 되었음

  - OS : CentOS(Linux nextBscAP 3.10.0-229.4.2.el7.x86_64 #1 SMP Wed May 13 10:06:09 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux)

  - Java : java version "1.6.0_45"

           Java(TM) SE Runtime Environment (build 1.6.0_45-b06)

           Java HotSpot(TM) 64-Bit Server VM (build 20.45-b01, mixed mode)

  - Was  : Apache Tomcat 6.0.41



위 환경으로 서비스 문제없이 잘 작동하고 있습니다.

  - Tomcat 6.x(Jeus client lib)     -> Jeus, Weblogic(테스트 해보지 않음)

  - Tomcat 6.x(Weblogic client lib) -> Jeus, Weblogic


Qname의 LocalPart명을 제대로 기록하고 해당 lib가 제대로 설치되면 문제가 없는것 같습니다.

저작자표시
블로그 이미지

유효하지않음

,

maven을 통해 Tomcat 다중서버 배포하기

WebService/Tomcat 2013. 8. 20. 19:27
jenkins를 통해 톰켓의 2개의 서버에 배포를 해야되는 경우가 발생함
현재 배포 plugin은 다중 배포를 지원하지 않는것 같네.. 힘드네.. 

## 테스트한 plugin
<groupId>org.apache.tomcat.maven</groupId>
<artifactId>tomcat6-maven-plugin</artifactId>
<version>2.1</version>

추후 테스트예정 plugin 들...
<groupId>org.codehaus.cargo</groupId>
<artifactId>cargo-maven2-plugin</artifactId>
<version>1.2.0</version>

테스트한거랑 같은건가...?? 모르겠네..
<groupId>org.codehaus.mojo</groupId>
<artifactId>tomcat-maven-plugin</artifactId>
<version>1.2-SNAPSHOT</version>


 ## 설정 
a서버는 6.0.35 
b서버는 6.0.37 


* A서버 B서버 같은 설정
#vi $CATALINA_HOME/conf/tomcat-users.xml
	<?xml version='1.0' encoding='utf-8'?>
	<tomcat-users>
		<role rolename="manager-gui"/>
		<role rolename="manager-script"/>
		<user username="tomcat" password="1234" roles="manager-gui, manager-script"/>
	</tomcat-users>

* maven settings.xml 파일에 servers 부분에 추가함 
 #vi $MAVEN_HOME/conf/settings.xml
    <server>
        <id>aTomcat</id>
        <username>tomcat</username>
        <password>1234</password>
    </server>
    <server>
        <id>bTomcat</id>
        <username>tomcat</username>
        <password>1234</password>
    </server>

* maven pom.xml 수정 
버전 6.0.35와 6.0.37 테스트시 url부분 때문에 문제가 발생함(403 Access Denied) 
6.0.35는 /manager/html 
6.0.37은 /manager 까지만... 중요!!! 
    ....

    <profiles>
        <profile>
            <id>aTomcat</id>
            <activation>
                <activeByDefault>true</activeByDefault>
            </activation>
            <properties>
                <tomcat-server>aTomcat</tomcat-server>
                <tomcat-url>http://xxx.xxx.xxx.xxx:9090/manager/html</tomcat-url>
                <tomcat-user>tomcat</tomcat-user>
                <tomcat-password>1234</tomcat-password>
                <tomcat-path>/</tomcat-path>
            </properties>
        </profile>
        <profile>
            <id>bTomcat</id>
            <properties>
                <tomcat-server>bTomcat</tomcat-server>
                <tomcat-url>http://xxx.xxx.xxx.xxx/manager</tomcat-url>
                <tomcat-user>tomcat</tomcat-user>
                <tomcat-password>1234</tomcat-password>
                <tomcat-path>/</tomcat-path>
            </properties>
        </profile>
    </profiles>

    ....

	<build>

		....

        <pluginManagement>
            <plugins>

                 ....

                <!--
                 벤더사별 plugin
                 Tomcat    : http://tomcat.apache.org/maven-plugin-2.0/
                 Jobss     : http://docs.jboss.org/jbossas/7/plugins/maven/7.4.Final/index.html
                 Weblogic  : http://docs.oracle.com/cd/E21764_01/web.1111/e13702/maven_deployer.htm
                 WebSphere : http://www.jroller.com/peter_pilgrim/entry/battling_with_maven_2_integrating
                 -->

                <plugin>
                    <groupId>org.apache.tomcat.maven</groupId>
                    <artifactId>tomcat6-maven-plugin</artifactId>
                    <version>2.1</version>
                    <configuration>
                        <server>${tomcat-server}</server>
                        <url>${tomcat-url}</url>
                        <username>${tomcat-user}</username>
                        <password>${tomcat-password}</password>
                        <path>${tomcat-path}</path>
                        <protocol>HTTP/1.1</protocol>
                        <failOnError>false</failOnError>
                        <charset>${encoding}</charset>
                        <uriEncoding>${encoding}</uriEncoding>
                        <update>true</update>
                        <mode>war</mode>
                    </configuration>
                </plugin>

                ....

            </plugins>
        </pluginManagement>

        ....

        </build>

    ....
* maven 실행시 goals 갯수만큼 실행하던가 쉘스크립트로 만들던가 해야됨 
플러그인 버전업시 지원 될라나..?? 
mvn -P aTomcat clean install tomcat6:stop tomcat6:undeploy tomcat6:deploy tomcat6:start 
mvn -P bTomcat clean install tomcat6:stop tomcat6:undeploy tomcat6:deploy tomcat6:start



# Ant 플러그인을 이용하는 방법 테스트 해보진 않았음 
<plugin>
    
    ....

    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-antrun-plugin</artifactId>
    <version>1.6</version>
    <configuration>
        <target>
            <taskdef name="deploy" classname="org.apache.catalina.ant.DeployTask"/>
            <deploy url="http://xxx.xxx.xxx.xxx/manager" username="tomcat" password="1234"
                path="/" war="file:${project.build.directory}/${project.build.finalName}.${project.packaging}" update="true"/>

            <deploy url="http://xxx.xxx.xxx.xxx/manager" username="tomcat" password="1234"
            path="/" war="file:${project.build.directory}/${project.build.finalName}.${project.packaging}" update="true"/>
        </target>
    </configuration>

   ....
   
</plugin>


저작자표시
블로그 이미지

유효하지않음

,

ProxyAJP를 이용한 Apache2 + Tomcat 연동시 중대한 보안 문제

WebService/Apache 2009. 4. 21. 09:42

[출처] http://theeye.pe.kr/entry/how-to-block-apache-with-proxy-remote-request

저는 단순히 DDOS공격인줄 알았습니다. IP는 정체를 알수 없이 전세계에서 들어오더군요. 사실상 끝나기를 기다리며 내 서버에는 사실상 영리목적의 사이트가 없는데 무엇이 목적일까 고민하게 되었습니다.

우선 쌓이는 로그가 매우 특이한것을 알수 있었습니다. 로그는 대충 다음과 같은 형식이었습니다.

202.109.175.224 - - [17/Apr/2009:21:17:39 +0900] "GET http://www.dfwater.com/Index.asp HTTP/1.1" 503 28 "http://www.dfwater.com/" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 5.1)"

84.16.227.121 - - [17/Apr/2009:21:17:35 +0900] "GET http://www.google.com/ie?q=puts+inurl:?p%3D&hl=en&num=100&start=200&sa=N HTTP/1.0" 302 335 "http://www.google.com/ie?q=puts+inurl:?p%3D&hl=en&num=100&start=200&sa=N" "Mozilla/4.0 (compatible; MSIE 5.0; Windows NT; DigExt)"

64.91.72.166 - - [17/Apr/2009:21:17:39 +0900] "CONNECT 205.188.251.26:443 HTTP/1.0" 200 - "-" "-"
61.160.211.12 - - [17/Apr/2009:21:17:36 +0900] "GET http://www.kiss888mu.cn HTTP/1.1" 500 3847 "http://www.baidu.com" "Mozilla/4.0 (compatible; MSIE 6.0; Windows 5.1)"

118.69.166.3 - - [17/Apr/2009:21:17:39 +0900] "GET http://69.147.112.211/config/isp_verify_user?l=mmg&p=0011 HTTP/1.0" 200 26 "-" "-"

208.70.78.177 - - [17/Apr/2009:21:17:36 +0900] "GET http://www.google.com/ie?as_q=inurl:/guestbook.html+tampa+fl+gay+life+and+dating&num=100&hl=en HTTP/1.0" 302 355 "http://www.google.com/ie?as_q=inurl:/guestbook.html+tampa+fl+gay+life+and+dating&num=100&hl=en" "Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050224 Firefox/1.0+"

78.30.203.105 - - [17/Apr/2009:21:17:39 +0900] "GET http://inmarket73.ru/forum/index.php?s=fb2bade970f814c6d66c67f414a2328b&act=Reg&CODE=image&rc=35f728107e6ae6292a22c4e6f16634ac&p=3 HTTP/1.0" 200 68 "http://inmarket73.ru/forum/index.php?act=Reg&CODE=image&rc=7f430230e31d334872d1b5136a57b9ce&p=1" "Mozilla/4.0 (compatible; MSIE 6.0; AOL 9.0; Windows NT 5.1)"

94.76.199.2 - - [17/Apr/2009:21:17:36 +0900] "GET http://superschurke.de/comments/feed/ HTTP/1.1" 404 809 "-" "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)"


로그가 좀 지저분 합니다만 형식이 다음과 같다는것만 보시면 됩니다. 요청이 GET 메서드 이후에 http로 시작하는 것을 알수 있습니다. 그것도 전혀 쌩뚱 맞은 도메인과 호스트에 요청을 합니다.

이것이 왜 이상하냐면 보통의 브라우저는 요청을 할때 다음과 같이 합니다. theeye.pe.kr/index.html의 요청이 있다면 DNS에 질의 하여 theeye.pe.kr 도메인의 호스트 IP를 알아낸 이후에 그곳에 접속하여 GET /index.html 과 같은 방법으로 요청을 하게 됩니다.

위와 같은 방법은 마치 여의도에 가서 "롯데월드가 어딧나요?" 라고 물어보는 꼴이 되는 것입니다.

왜 저런 요청이 자꾸 들어오는 것인지 궁금하여 서버에 다음과 같이 테스트를 해보았습니다.

telnet theeye.pe.kr 80

GET http://www.naver.com

자, 상식적으로 잘못된 요청이라고 나와야 하지만 정상적으로 페이지가 출력됩니다. 아니 왜 내 서버에서 엉뚱한 사이트의 요청을 처리해 주는 것이지!?

이제 여의도에 가서 "롯데월드가 어딧나요?" 라고 물었더니 상대방이 자기 차에 태워 롯데월드에 데려다 주었습니다.

친절한 사람이군요;;; 근데 문제가, 이걸 악용해서 소문이 나서 세상의 모든 사람이 이 친절한 사람에게 와서 자신이 가고싶은 곳이 어딧는지를 물어본다는 것이 문제가 됩니다.

서버가 엉뚱한 요청을 받아 대리 요청후에 결과를 되돌려 주는 문제는 일전의 Proxy설정의 잘못이었습니다.

ProxyAJP설정을 별다른 보안 절차 없이 설정하게 되면 이 세상 모든 http 요청의 IP세탁 시스템으로 둔갑되어질 수 있습니다.

이문제를 해결하기 위해서는 간단하게 Proxy 요청은 로컬호스트에서만 가능하게 설정하시면 됩니다.

<Proxy *>

Order Deny,Allow

Deny from all

Allow from localhost

</Proxy>

간단하게 해결되었죠? Proxy 설정을 하시고 서버를 운영하시는 분들은 다른 호스트로의 요청을 해보시기 바랍니다.

에러없이 요청이 정상처리 된다면, 이제 표적이 되기전에 설정을 조금 손보시기 바랍니다.

첨언 : 추가로 로그들을 쭉 분석해 봤는데, 위와 같은 방법을 사용하는 이유는 특정 사이트의 검색요청을 계속하여 검색랭킹을 올린다거나, 추천사이트의 어뷰징 혹은 사이트 페이지뷰를 높이는데 사용되어지는 듯 싶습니다.
블로그 이미지

유효하지않음

,

web.xml에 error-page 설정후 적용되지 않을경우

WebService 2009. 4. 15. 10:24
[출처] http://eyecandyzero.tistory.com/tag/404, http://levin01.tistory.com/575

web.xml에 error-page 설정후 적용되지 않을경우


	
	    java.lang.throwable
	    /common/error/error.ng
	
	
		java.lang.NullPointerException
		/common/error/error.ng
	
	
		java.lang.Exception
		/common/error/error.ng
	
	
	    404
	    /common/error/error.ng
	
	
	    400
	    /common/error/error.ng
	
	
	    500
	    /common/error/error.ng



IE 가 http 404 status 를 만나게 되면 대부분 로컬에 저장되어있는 다음 페이지를 강제로 보여주더군요
res://C:\WINNT\system32\shdoclc.dll/http_404.htm 

<%@ page contentType="text/html; charset=MS949" %>
<%
	response.setStatus(HttpServletResponse.SC_OK); //200
	
	/*
	Object exObj = req.getAttribute("javax.servlet.error.exception");
	String uri = "";
	
	if(uriObj != null)
	{
		uri = uriObj.toString();
		
		out.println(uri);
		out.println("
");
	}
	*/
	out.print(request.getAttribute("javax.servlet.error.status_code"));
	out.print("
");
	out.print(request.getAttribute("javax.servlet.error.exception_type"));
	out.print("
");
	out.print(request.getAttribute("javax.servlet.error.message"));
	out.print("
");
	out.print(request.getAttribute("javax.servlet.error.exception"));
	out.print("
");
	out.print(request.getAttribute("javax.servlet.error.request_uri"));
%>

ERROR PAGE에서 활용하는 방법

${requestScope['javax.servlet.error.status_code']}

javax.servlet.error.status_code:
        에러 상태 코드를 말해 주는 정수
javax.servlet.error.exception_type
        에러가 생기게 된 예외 형을 지적해 주는 클래스 인스턴스
javax.servlet.error.message
        예외 메시지를 말해주는 스트링이며, 예외 컨스트럭터로 보내어 진다.
javax.servlet.error.exception
        실제 예외가 없어지면 버릴 수 있는 객체이다.
javax.servlet.error.request_uri
        문제를 일으킨 리소스의 URI를 말해주는 스트링이다.

javax.servlet.error.servlet_name

 

Throwable e = (Throwable)request.getAttribute("javax.servlet.error.exception");
Throwable e1 = (Throwable)request.getAttribute("javax.servlet.jsp.jspException");

 

오류 페이지에서만 쓸 수 있는 객체 : exception

<%@ page isErrorPage="true" %>
${pageContext.exception}


오류 발생 후 오류 페이지로 이동하지 않고 자체 페이지에서 해결하기 : <c:catch>

<c:catch>
   <% int x = 10/0; %>
   // 에러가 발생하면 다음을 실행하지 않고 </c:catch>로 곧장 이동한다.
</c:catch>


exception을 속성으로 만들어 에러 메시지 읽기

<c:catch var="myException">
   ...
</c:catch>
${myException.message}
// 타입이 Throwable이니 message프로퍼티가 있음

블로그 이미지

유효하지않음

,

제우스(JEUS), WebtoB 관리를 위한 주요 명령어 및 alias 요약

WebService/JEUS 2008. 11. 26. 12:05
[출처]  http://kyungseo.pe.kr/blog/trackback/102

JEUS 운영 및 관리

JEUS 5.0을 버전을 기준으로 하고 설치시 입력한 JEUS 관리자의 비밀번호는 jeusadmin이라고 전제한다.

JEUS 구동

주로 jboot, jdown이란 이름으로 스크립트를 작성하여 실행한다. 이 파일들의 실제 명령행은 다음과 같다.

  • jboot: jeus -Uadministrator -Pjeusadmin
  • jdown: jeusadmin -Uadministrator -Pjeusadmin jeusexit

jeusadmin console

jeusadmin 콘솔툴을 이용하여 JEUS 컨테이너기동/종료, 엔진리스트확인 등 JEUS 엔진의 상태를 제어 및 점검한다.

  • 콘솔 실행: jeusadmin 'hostname' -Uadministrator -Pjeusadmin
  • 명령 목록
    • allenglist: jeusadmin의 allenglist 명령은 현재 각 컨테이너의 엔진기동 상태를 보여준다.
    • downcon <container-name>: 지정된 컨테이너를 종료시킨다.
    • startcon <container-name>: 지정된 컨테이너를 기동시킨다.
    • pidlist: JEUS의 엔진 프로세스를 확인한다.

webadmin console

webadmin 콘솔은 JEUS의 컨테이너 내부에 기동된 서블릿 엔진의 상태를 모니터링하기 위한 명령프롬프트이다.

  • 콘솔 실행: webadmin <container-name> -Uadministrator -Pjeusadmin
  • 명령 목록
    • ti: ti는 Thread Information의 약자로 JEUS 서블릿 엔진의 컨텍스트그룹 내부의 Worker Thread의 상태를 체크하기 위한 명령어이다.
    • st -m: 현재 Container의 JVM Memory 사용 현황
    • st -r: 설정한 Context로 들어온 요청 count와 평균처리시간
    • st -s: 현재 유지하고 있는 세션 객체의 수

webadmin 반복 모니터링

webadmin 내의 모니터링 명령어를 주기적으로 자동실행하게 하려면 다음과 같은 형식으로 명령어를 실행한다.

  • <command> -i 주기(초) -k 횟수
  • 예) ti -i 2 -k 10 : ti 명령어를 2초 간격으로 10번 수행

dbpooladmin console

dbpooladmin 콘솔은 컨테이너별로 할당된 Database Pool의 상태를 모니터링하기 위한 명령프롬프트이다.

  • 콘솔 실행: dbpooladmin<container-name> -Uadministrator -Pjeusadmin
  • 명령 목록
    • Info: 해당 컨테이너에서 관리되고 있는 Database Pool의 정보가 표시된다.
    • min, max 값은 JEUSMain.xml에 설정한 Pool의 최소/최대값이며 current는 현재 풀에 보관되고 있는 실제 커넥션의 수, idle의 풀에 보관되고 있는 커넥션중, 사용가능한 개수를 의미한다.

JEUS 웹 관리자

http://hostname:9744/webadmin 로 접속하여 administrator/jeusadmin 계정으로 로그인한다.

 

JEUS 웹 관리자

JEUS 장애 처리

JEUS 프로세스ID (PID) 확인

JEUS의 엔진 프로세스는 다음과 같이 2가지 방법으로 확인할 수 있다.

  • ps -ef | grep java
    • -Xmx512m 이후 부분을 확인하여 JEUS Manager 프로세스임을 확인한다.
    • [-D컨테이너이름]을 이용하여 컨테이너 프로세스임을 확인한다.
  • jeusadmin 콘솔툴을 이용한 PID 확인
    • pidlist: pidlist 명령을 사용하여 PID를 확인한다.

JAVA Dump

  • 덤프 생성: kill -3 [JEUS-PID]
  • 덤프 확인: JEUS JAVA프로세스에서 생성한 덤프는 JeusServerLog에서 확인한다.
    • 예) vi $JEUS_HOME/logs/`hostname`/JeusServer_20070201.log
WebtoB 운영 및 관리

WebtoB 구동

  • wsboot
  • wsdown-I : ps -ef을 이용하여 wsm, hth, htl, html 등의 프로세스가 나타나지 않으면 정상 종료

wsadmin console

WebtoB 시스템을 관리하기 위해서 wsadmin이라는 프로그램이 제공된다. wsadmin 프로그램은 UNIX 환경의 shell과 비슷한 Command Interpreter 이다. 즉, 항상 프롬프트상태로 대기중이다가 입력되는 명령어를 해석하여 이를 실행하게 된다. 여러 Node를 한 Domain으로 사용하는 경우 wsadmin으로 전체를 중앙관리가 가능하며 각 Node 별로 로컬에서만도 관리가 가능하다.

  • wsadmin
  • 명령 목록
    • ci: 요청에 대한 현재 클라이언트 정보를 표시한다. HTH당 접속한 클라이언트의 KeepAlive 되어있는 개수를 보여준다. WebtoB단에 요청을 보내고 HTTP Session의 KeepAliveTimeout 전까지 유지되고 있는 클라이언트의 총 개수 정보이다.
    • ci -s: 현재 클라이언트의 전체 수를 표시한다.
    • si: 웹서버 환경설정 파일에서 *SERVER 절에 선언한 서버들의 수행정보를 보여준다.
    • st -s: 웹서버 환경설정 파일에서 *SERVER, *URI, *EXT 절에 설정한 서비스의 상태가 보인다.
    • st -p: WebtoB 프로세스의 상태를 표시한다. 주로 JEUS-WebtoB간 연동 상태를 확인할 때 사용한다.

wsadmin 명령 연속 보기

ci, st -s, st -p, si 등의 명령어를 다음과 같이 수행하면 주기적으로 WebtoB의 상태를 모니터링할 수 있다.

  • r -i <시간(초)> -k <횟수> <명령>
  • 예) r -i 1 -k 1000 st -s
JEUS alias 설정

.profile 참고

...
export JEUS_HOME=/jeus
...
#### JEUS alias ####
alias ja='jeusadmin `hostname` -Uadministrator -Pjeusadmin'
alias ea='ejbadmin `hostname`_ejb_engine1 -Uadministrator -Pjeusadmin'
alias wa='webadmin `hostname`_container1 -Uadministrator -Pjeusadmin'
alias da='dbpooladmin `hostname`_container1 -Uadministrator -Pjeusadmin'
alias ti='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin ti -i 3 -k 100000'
alias ss='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin st -s -i 3 -k 100000'
alias sd='webadmin `hostname`_servlet_engine1 -Uadministrator -Pjeusadmin st -d -i 3 -k 100000'
alias di='dbpooladmin `hostname`_container1 -Uadministrator -Pjeusadmin info -i 3 -k 100000'

alias jcfg='cd ${JEUS_HOME}/config/`hostname`'
alias jbin='cd ${JEUS_HOME}/bin'
alias scfg='cd ${JEUS_HOME}/config/`hostname`/`hostname`_servlet_engine1'
alias ecfg='cd ${JEUS_HOME}/config/`hostname`/`hostname`_ejb_engine1'

alias jhome='cd ${JEUS_HOME}'
alias lhome='cd ${JEUS_HOME}/logs'

alias jlog='tail -f ${JEUS_HOME}/logs/`hostname`/JeusServer_`date +%Y%m%d`.log'
alias alog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/accesslog/access_`date +%Y%m%d`.log'
alias elog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/errorlog/error_`date +%Y%m%d`.log'
alias ulog='tail -f ${JEUS_HOME}/logs/`hostname`_servlet_engine1/MyGroup/userlog/user_`date +%Y%m%d`.log'

...
 
 
블로그 이미지

유효하지않음

,

JBoss의 간단한 FAQ 입니다.

WebService/JBoss 2008. 11. 6. 16:18
Q. JBoss는 Open Source 입니까?

네. Open Source입니다. 그래서 비용 지불없이 자유롭게 소스코드 및 바이너리를 사용할 수 있으며 소스코드를 수정할 수도 있습니다.


Q. JBoss는 J2SE 및 Java EE 표준을 충실히 따릅니까?

네. JBoss는 표준을 엄격히 따릅니다.


Q. Java EE 5를 지원하는 JBoss의 버전은 무엇입니까?

Java EE 5를 지원하는 공식 JBoss는 5.0이며 2008년도에 릴리즈 될 예정으로 있습니다. 현재 4.2.x 버전은 J2EE 1.4와 Java EE 5의 일부 기능(예; EJB 3.0)을 지원합니다.


Q. JBoss는 어떤 JDK에서 가장 잘 동작합니까?

JBoss또한 Java EE 표준을 따르기 때문에 Java EE 표준에서 정하는 Java SE 버전을 사용해야 합니다. 현재 릴리즈된 JBoss 4.2.3 버전은 JDK 1.6/JDK 1.5를, JBoss 4.2.2.GA는 JDK 1.5를 사용하면 되며, JBoss 5는 Java EE 5 표준에 따른 Application Server이므로 무리없이 가장 잘 동작하려면 JDK1 .5를 쓰는 것이 바람직합니다.


Q. 국내 레퍼런스가 있습니까?

네. SKT HELIO, 로밍포탈, SKT ISF, 통합결제 UI서버, 국세청국세법령유, 도로교통관리공단포탈, KIPA유러닝사업, 행자부G4C장비개선사업, 행자부성과측정관리시스템, 방송작가협회내부시스템, 서울시청상시기록평가시스템, 캠크로스개발서버, 일양택배물류시스템, 한미IT 어플리케이션서버 등에서 공식적으로 사용하는 것으로 알려져 있으며 카페 조사 결과 그외에도 많이 사용하는 것으로 알고 있습니다.


Q. 전문적인 기술지원을 받을 수 있습니까?

네. JBoss가 오픈소스이기는 하나 RedHat에서 인수하고 상용화하여 별도의 subscription에 가입하게 되면 기술지원을 받을 수 있습니다. 현재 다우기술이나 LDS 등등의 회사를 통해서 기술지원을 받을 수 있습니다.


Q. 상용 JBoss의 가격정책은 어떻습니다?

jboss.org에서 다운받을 수 있는 오픈소스 JBoss의 사용은 완전한 무료입니다. 하지만 subscription에 가입하는 경우 비용을 지불해야 하며 이때 전문적인 기술지원을 받을 수 있게 됩니다. 일반적인 가격정책은 4 CPU를 단위로 결정됩니다. 상용 Application Server와 JBoss Subscription의 비교는 http://cafe.naver.com/jbossug/767 또는 http://www.redhat.com/promo/migration/calc.html을 참고하십시오.


Q. 상용과 오픈소스의 제품 차이가 있습니까?

아니오. 전혀 그렇지 않습니다. 상용과 오픈소스는 차이가 없습니다. 상용은 subscription을 구매하시면 되며 릴리즈가 오픈소스와 달리 공식적인 릴리즈 버전을 제공하며 이것에 따라서 hotfix나 patch도 릴리즈 됩니다. 오픈소스 사용자는 이러한 버전을 다운로드할 수 없고 subscription에 가입되어 있는 사용자만 subscription 사이트에서 다운받을  수 있습니다.

버전업은 오픈소스가 일반적으로 더 빠릅니다. 따라서 오픈소스를 사용하시더라도 버그가 패치되고 기능이 향상된 버전이 더 빨리 jboss.org를 통해서 공개되기 때문에 제품 자체에 대한 차이는 없다고 보시면 됩니다. 즉, 상용과 오픈소스의 차이는 기술지원 여부입니다.


Q. JBoss의 현재 시장 점유율은 어떻습니까?

공식적을 RedHat이 발표하지는 않았지만 2005년도 ONJava에서 조사한 것에 따르면 JBoss는 38%, WebSphere 21%, WebLogic 20% 정도입니다. 특히 북미시장은 JBoss를 매우 선호합니다.


Q. JBoss는 Clustering을 지원합니까?

네. JBoss는 Clustering을 지원합니다. JBoss는 클러스터링을 통해서 부하분산, 상태복제, 자동장애복구 등을 구현하고 있습니다. HTTP Session, EJB, JMS, JNDI 등에서 Clustering 기술을 이용할 수 있습니다.


Q. JBoss에서 웹 컨테이너만 사용할 수 있습니까?

네. JBossAS에서 웹 컨테이너만 사용할 수 있으며, 웹 서버로서 기능을 수행하는 JBossWeb을 사용하실 수도 있습니다. 또한 SSL 등의 성능향상을 도와주는 JBoss Web Native Library를 제공합니다. JBossWeb은 웹 컨테이너 이외에는 웹 서버의 기능을 제공하기 때문에 PHP 및 Rewrite 모듈등을 제공합니다. JBossWeb 사이트는 http://labs.jboss.com/jbossweb 입니다.


Q. JBoss 개발도구가 있습니까?

네. 많습니다. Eclipse, IntelliJ IDEA, NetBeans 등이 모두 지원하며 거의 대부분 지원한다고 보시면 됩니다. JBoss에서는 JBossIDE라는 개발도구가 있으며 Exadel의 기여로 현재 JBossTools로 이름이 변경되었습니다. JBossIDE 또는 JBossTools는 Eclipse를 기반으로 하고 있으며 JBoss jBPM, JBoss Seam 과 같은 JBoss Project도 지원합니다. 현재 버전은 2.0입니다.

    * First-class support for JBoss Seam 1.2 and 2.0
    * Visual Page editor for rich editing of (X)HTML, JSP, JSF and Facelets pages
    * Unique JSF and Facelets support
    * JBoss AS server integration
    * Project Archives
    * Hibernate 3 Support

또한 상용버전인 JBoss Developer Studio가 있습니다. 이 제품의 가격은 $99입니다. 이 제품은 JBossIDE와 기능적으로는 유사하지만 다음의 제품이 추가적으로 더 포함되어 있으며 현재 1.0입니다.

  * Hibernate
  * JBoss Seam
  * JBoss Application Server

또한 JBoss Developer Studio는 JBossIDE보다 다음의 기능이 더 추가되어 있습니다.

  * An installer
  * Eclipse and Web Tools preconfigured
  * JBoss EAP with JBoss AS and Seam preconfigured
  * 3rd party plugins bundled and configured
  * Access to RHEL and Red Hat Network
  * Access to the JBoss/Red Hat supported software


Q. JBoss는 사용하기 쉽습니까?

네. JBoss는 사용하기 쉽습니다. WebLogic과 같은 WAS에 익숙해져 있다면 편리한 관리 콘솔을 지원하므로 상대적으로 어려워 보일 수 있습니다. 하지만 가만히 들여다 보면 사용하기 쉬운 WAS입니다. Tomcat 정도의 웹 컨테이너를 사용하신다면 JBoss도 쉽게 접근할 수 있습니다.


Q. JBoss는 웹 콘솔이 있습니까?

네. 있습니다. JBoss 구동후 http://localhost:8080/ 에 접속하시면 웹 페이지 기반 JMX Console과 Applet 기반 JMX Console을 제공합니다. 현재까지는 Console이 가장 JBoss의 취약부분이라 할 수 있습니다. RedHat에서 콘솔에 대한 부분은 지속적으로 개선할 것이라고 합니다.


Q. JBoss를 특정 IP로 바인딩할 수 있습니까?

네. 가능합니다. JBoss 구동시 IP 주소를 인수로 넘겨주면 됩니다. 다음과 같이 할수 있습니다.

#run.sh -b 0.0.0.0  (모든 네트워크의 IP로 바인딩) 또는 #run.sh -b 192.168.1.100 (특정 IP로 바인딩)


Q. JBoss에 Configuration Profile을 이용하여 사용할 수 있습니까?

네. 가능합니다. JBoss는 기본적으로 all, default, minimum의 3 가지 sever configuration을 제공합니다. 예를 들어 Clustering을 사용하려면 반드시 all server configuration으로 구동해야 합니다. 일반적으로는 default server configuration을 사용하면 됩니다. minimum을 사용하면 최소 기능이 동작하게 되며 EJB, 클러스터링과 같은 기능은 활용할 수 없게 됩니다.

또한 server configuration을 별도로 구성할 수도 있습니다. 이렇게 하여 경량의 JBoss 또는 나만의 JBoss를 구성할 수도 있습니다. 이러한 server configuration은 <JBOSS_HOME>/server 디렉토리에 configuration 별로 디렉토리가 구성되며 직접 구성할 수도 있습니다.

JBoss 구동시 configuration을 적용하려면 다음과 같이 구동하시면 됩니다.

#run.sh -c all 또는 #run.sh -c default


Q. JBoss 한글 관리자 가이드를 구할 수 있습니까?

현재 JBoss 4.x 버전은 없지만 JBoss 3.x 버전은 국내 엔지니어가 번역한 문서가 있습니다. 기본적인 내용은 거의 비슷하므로 도움이 되실 것입니다. JBoss 관리자 개발 가이드는 http://openframework.or.kr/framework_reference/jbossAdmin/ 을 참고하십시오.

 


Q. 타 WAS로 개발한 웹 애플리케이션을 JBoss로 이식(포팅)할 수 있습니까?

네 가능합니다. 표준대로 애플리케이션을 구현했다면 다른 WAS(예; WebLogic)에서 충분히 포팅할 수 있습니다. 다른 WAS에서 작성했더라도 표준에서 지원하는 부분은 동일하며 WAS에 특정 정보를 가지고 있는 배포 디스크립터를 JBoss용 디스크립터로 변환해 주시면 됩니다. 예를 들면 JBoss의 경우에는 jboss-web.xml 파일들이 있으며 WebLogic에는 weblogic.xml 파일들이 있습니다.
Q. JBoss가 WebLogic과 같은 상용보다 성능이 느리지 않을까요?

그렇지는 않습니다. 오히려 성능시험을 해보면 상용보다 빠른경우가 많습니다. 즉, 오픈소스라서 성능이 느리다는 생각은 하지 않으셔도 됩니다(성능 측정 결과는 1차 모임 발표자료를 참고하세요). 오히려 많은 엔지니어를 통해 검증받기 때문에 더 좋습니다. JBoss가 오픈소스이기 때문에 특정 도메인에서 성능이 느리다고 생각하시면 WAS 구매 비용으로 장비를 추가하시는 것도 좋은 방법입니다.


Q. JBoss로 운영시 적은 비용으로 모니터링할 수 있는 방법이 있습니까?

JBoss는 JMX를 지원하므로 JMX를 기반으로 모니터링 기능을 제공하는 APM 제품에서 모두 사용이 가능합니다. 하지만 APM은 비용이 많이 발생하므로 적은 비용으로 모니터링할 수 있는 방법을 찾아야 합니다. 가장 적합한 제품이 AdventNet ManagedEngine Applications Manager(http://manageengine.adventnet.com/products/applications_manager/index.html)입니다. 이 제품은 OS, DB, WAS, JVM, Web Transaction, WebServices, JMX 등등을 한번에 모니터링하여 운영시 JBoss 모니터링 제품으로써 적은 비용으로 사용할 수 있습니다.

 이 비용마저 줄이고자 한다면 JMX를 기반으로 모니터링 애플리케이션을 구성하시면 됩니다.


Q. JBoss.ORG에는 어떤 프로젝트들이 있습니까?



Apache_JBoss_Configuration.pdf
블로그 이미지

유효하지않음

,

클라이언트 요청이 오류 초과 또는 시간 제한으로 중단되었습니다.

WebService/IIS 2008. 11. 6. 16:16

업데이트됨: 2005년 08월 22일

IIS 6.0의 경우 설정값이 최대로 보안을 유지하는 기본값으로 설정되어 이전 버전의 시간 제한 및 제약으로 인한 공격을 최소화합니다. IIS는 연결 수준에서 다음 시간 제한을 강제 적용합니다.

•

응답 버퍼링 제약: AspBufferingLimit 메타베이스 속성 의 기본값은 4MB입니다. ASP 스크립트 버퍼가 이보다 많아지면 오류가 초과됩니다. IIS 6.0 이전에는 버퍼링에 제약이 없었습니다.

•

전송할 때의 제약: AspMaxRequestEntityAllowed 메타베이스 속성 은 최대 ASP 전송 크기를 204,800바이트(각 필드는 100KB)로 제한합니다. IIS 6.0 이전에는 전송에 제약이 없었습니다.

•

ServerListenTimeout 메타베이스 속성은 IIS 6.0의 WWW 서비스에서는 사용되지 않지만 FTP와 SMTP, NNTP 등의 서비스에서는 계속 사용할 수 있습니다. WWW 서비스에서 ServerListenTimeout은 다음 메타베이스 속성으로 대체되었습니다.

•

ConnectionTimeout 메타베이스 속성 : 이 속성은 서버가 비활성화된 연결을 해제할 때까지의 대기 시간(초)을 설정합니다.

•

MinFileBytesPerSec 메타베이스 속성 : IIS가 클라이언트 요청에 응답하면 MinFileBytesPerSec 속성이 클라이언트가 전체 응답을 수신해야 하는 시간 길이를 결정합니다. 만일 클라이언트 시스템이 전체 응답을 너무 오래 수신하고 있으면 커널 모드 드라이버인 HTTP.sys가 시간 제한 값에 따라 연결을 종료합니다.

•

HeaderWaitTimeout 메타베이스 속성 : 클라이언트에 웹 서버가 연결하면 클라이언트 컴퓨터에 요청의 모든 헤더를 전송할 시간 제한(마지막에 \r\n으로 표시)이 제공됩니다. 요청의 완전한 헤더 세트가 HeaderWaitTimeout에 표시된 시간 기간 내에 수신되지 않으면 HTTP.sys가 연결을 다시 설정합니다. HeaderWaitTimeout의 값을 구성할 수 있습니다.

•

헤더 크기 제한: 기본값으로 HTTP.sys는 요청 헤더가 16KB보다 적은 요청만 승인합니다. 즉, HTTP.sys가 16KB 내에 종료 <CRLF><CRLF> 시퀀스를 수신하지 못하면 HTTP.sys는 악의 있는 요청으로 간주하고 연결을 종료합니다. MaxRequestBytes 레지스트리 키의 값을 조정하여 헤더 크기 제한을 변경할 수 있습니다.

블로그 이미지

유효하지않음

,

IIS 6 Troubleshotting

WebService/IIS 2008. 11. 6. 16:09

Windows Server 2003 Resource Kit Tools

http://www.microsoft.com/downloads/details.aspx?displaylang=en&familyid=9D467A69-57FF-4AE7-96EE-B18C4790CFFD
 

  

Process Explorer for Windows v10.21


Log Parser 2.2


FileMon for Windows v7.04


Internet Information Services (IIS) 6.0 Resource Kit Tools

 

 

IIS Metabase Properties

http://msdn.microsoft.com/en-us/library/ms525644.aspx

http://technet.microsoft.com/en-us/library/cc778146.aspx

 

16_IIS6Troubleshotting.doc

블로그 이미지

유효하지않음

,

[Window + Apache2.2 + Coldfusion 6.1] mod_jrun20.so cannot load

WebService/ColdFusion 2008. 11. 6. 16:00

 문제)

Coldfusion 6.1 에서 Apache 서버와 configuration을 하는 경우 아래와 같은 에러가 발생.

httpd.exe: Syntax error on line 486 of c:/Program Files/Apache Software Foundation/Apache2.2/conf/httpd.conf: Cannot load c:/JRUN4/lib/wsconfig/1/mod_jrun20.so into server: The specified procedure could not be found.

 

 

해결책)

I notice that you are using apache 2.2. You will need to use the mod_jrun22.so

1. Download this hotfix: http://www.adobe.com/support/coldfusion/ts/documents/8001e97/wsconfig.zip
2. Extract the jar and open it with winrar or similar.
3. Copy wsconfig.jar\connectors\apache\intel-win\prebuilt\mod_jrun22.so to your machine {path to mod_jrun}

 

***  cf_root/runtime/lib/wsconfig.jar 파일을 다운로드 받은 파일로 변경한다. 

블로그 이미지

유효하지않음

,

HTTP Status Code(HTTP 1.1 : RFC 2616)

WebService 2008. 9. 16. 14:43

HTTP Status Code(HTTP 1.1 : RFC 2616)

상태코드는 서버가 요구 메시지를 수신하여 처리한 결과를 알려주는 세 자리의 정수로 된 처리 결과 번호입니다.
첫 번째 자리 숫자는 응답의 종류에 대한 분류 기호이며, 나머지 두 자리 숫자는 일련번호입니다. 현재 첫 번째 자리 숫자에 대해 다섯 가지로 분류하여 쓰고 있습니다.

Informational 1xx

참고 정보로 클라이언트의 요청이 접수되었고 현재 처리하고 있다는 의미입니다.
클라이언트에서 첨부문서(attatched document)를 보내기 전에 요청을 보낼때 Expect헤더에 설정해서 보냅니다. 잠적적인 응답을 표시하며 Status-Line과 선택적인 헤더로 구성되어 있습니다. 이 클래스는 빈 라인으로 종료되고 HTTP/1.0은 어떠한 1xx 상태 코드로 정의하지 않기 때문에 실험적인 상황 이외에 서버는 1xx 응답을 HTTP/1.0 클라이언트에 발송해서는 안됩니다.

100 Continue (계속)
요청된 초기 부분은 접수되었고 클라이언트는 계속해서 요청할 수 있다는 것입니다.
이 잠정적인 응답은 클라이언트에게 응답의 시초 부분이 수신되었으며 서버가 아직 거부하지 않았음을 알리는 데 사용합니다. 클라이언트는 요구의 나머지 부분을 발송하여야 하며 요구가 완료 되었으면 이 응답을 무시해야 합니다. 서버는 요구가 완료된 다음 마지막 응답을 발송합니다.

101 Switching Protocols (프로토콜 변환)
서버는 Upgrade 헤더 필드에 명시된 프로토콜로 교환하기 위한 클라이언트 요청에 따르고 있다는 것을 말합니다.
서버가 이해하였으며 기꺼이 Upgrade 메시지 헤더 필드를 통하여 접속에 사용되고 있는 애플리케이션 규약 변경에 관한 클라이언트의 요구에 따릅니다. 서버는 101 응답을 종료하는 빈 라인 바로 다음 응답 메시지의 Upgrade 헤더 필드가 정의한 규약으로 전환할 것입니다.

규약은 전환하는 것이 유리한 경우에만 전환됩니다. 예를 들어 새로운 버전의 HTTP로 전환하는 것이 이전 버전을 사용하는 것보다 유리하며 해당 기능을 사용하는 자원을 배달할 때 실시간, 동시 규약으로 전환하는 것이 유리합니다.


Success 2xx

요청 받은 것이 성공적으로 처리되었음을 나타냅니다.
이 상태 코드 클래스는 클라이언트의 요구가 성공적으로 수신, 해석 및 접수되었음을 표시합니다.

200 OK
클라이언트의 요청이 성공적이었으며, 서버는 요청한 데이터를 포함하여 응답합니다.
응답과 함께 리턴 되는 정보는 요구에 사용된 method에 달려 있습니다.

    예를 들면:
    GET 요구한 자원에 상응하는 엔터티는 응답에 포함되어 발송됩니다.
    HEAD 요구한 자원에 상응하는 Entity-Header 필드는 Message-Body 없이 응답에 포함되어 발송됩니다.
    POST 처리 결과를 설명 또는 포함하는 엔터티.
    TRACE 수신 서버가 수신한 요구 메시지를 포함하고 있는 엔터티.

201 Created (생성 되었음)
새로운 URI가 만들어질 때마다 사용되며 결과 코드와 함께 새로운 데이터가 위치한 곳을 지정하기 위해 Location 헤더가 서버에 의해 주어집니다.
원서버는 201 상태 코드를 리턴하기 전에 반드시 자원을 생성해야 합니다. 처리가 즉각적으로 수행될 수 없을 때에 서버는 202(Accepted) 응답으로 대신 응해야 합니다.

202 Accepted (접수 되었음)
클라이언트이 요청을 받아들이기만 했을 뿐 아직 완료되지 않은 상태를 나타냅니다.
처리를 위해 응답을 접수하였으나 처리는 완료되지 않았다는 의미로 요구는 엔터티의 처리 과정에서 허용되지 않을 수도 있기 때문에 궁극적으로 처리될 수도 있고 처리되지 않을 수도 있습니다. 이와 같은 동시 작업에서 상태 코드를 재발송하는 설비는 없습니다.

202 응답은 의도적으로 작업을 수행하지 않습니다. 이 응답의 목적은 서버가 사용자 에이전트가 프로세스가 완료될 때까지 서버에 지속적으로 연결되지 않고도 다른 프로세스에 대한 요구(하루에 한 번만 실행되는 배치 지향적인 프로세스일 수도 있습니.)를 접수할 수 있도록 하는 데 있습니다. 이 응답을 리턴하는 엔터티는 상태 점검자(monitor)에 대한 지시자 또는 사용자가 언제 요구가 완료될 수 있는지에 대한 예상 및 요구의 현재 상태에 대한 표시를 포함해야 합니다.

203 Non-Authoritative Information(비 인증 정보)
Entity-Header의 리턴 된 메타 정보는 서버에서 사용할 수 있는 정의 세트가 아니고 지역 또는 제 3 자의 복사본에서 수집한 것입니다.
제시된 세트는 원래 버전의 하부 세트 또는 상위 세트일 수 있습니다. 예를 들어 자원에 대한 지역적 주해 정보를 포함하면 원서버가 알고 있는 메타 정보에 대한 상위 세트를 만들어 낼 수도 있습니다. 이 응답 코드를 사용하는 것은 의무사항이 아니며 응답이203이 아니면 200 (OK)일때만 적합합니다.

204 No Content(내용이 없음)
응답할때 주어지는 헤더이나 응답된 실제 내용이 없다는 뜻입니다.
새로운 문서가 없어서 브라우저에게 이전 문서를 계속 표시하라고 알려주는 것으로 서버가 요구를 완전히 처리 했으나 반송할 새로운 정보가 없다는 것으로 클라이언트가 사용자 에이전트이면 요구를 발송하도록 한 문서 내용을 변경해서는 안 됩니다.

이런 응답을 받는 이유는 웹브라우저가 문서를 보기위해 갱신을 하지 않았기 때문입니다. 이미지맵에서 클라이언트가 이미지의 영역중 사용하지 않거나 공백인 부분을 클릭했을 때를 처리할 때 유용합니다.

205 Reset Content(내용을 지움)
새로운 문서가 없더라도 브라우저에서 창을 초기화하고, 문서를 새로 표시한다는 것입니다.
서버가 요구를 완전히 처리하였으며 사용자 에이전트는 요구를 발송하도록 한 문서의 내용을 지워야합니다. 이 응답은 주로 사용자 입력을 통하여 처리를 위한 입력이 발생하도록 하기 위해 사용합니다. 이 응답 뒤에 입력을 수행한 폼을 지워 사용자가 다른 입력 요구를 쉽게 시작할 수 있게 합니다. 이 응답은 엔터티를 포함해서는 안 됩니다.

웹브라우저가 추가적인 입력을 위해 사용된 트랜잭션을 지우는 것으로 CGI 애플리케이션에서 데이터를 입력받을때 적합합니다.

206 Partial Content(부분적 내용)
서버가 요청된 크기의 데이터를 반환하고 있다는 것입니다.
Range 헤더 지정 요청에 응답하는데 이용됩니다. 이 요구는 반드시 원하는 영역을 표시하는 Range 헤더 필드를 포함해야 합니다. 응답은 이 응답에 포함된 영역을 표시하는 Content-Range 헤더 필드나 각 파트의 Content-Range 필드를 포함하는 multipart/byteranges Content-Type을 포함해야 합니다. multipart/byteranges를 사용하지 않았으면 응답의Content-Length 헤더 필드는 Message-Body로 전송된 OCTET의 실제 숫자와 정확하게 일치해야 합니다.

Range 및 Content-Range 헤더를 지원하지 않는 캐시는 206(Partial Content) 응답을 캐시해서는 안됩니다.


Redirection 3xx

파일들이 이동되었을 때 쓰이며, 이동하는 위치를 나타내는 Location 헤더가 응답에 포함됩니다.
이 상태 코드 클래스는 사용자 에이전트가 요구를 완전히 처리하기 위해서는 추가적인 처리가 필요하다는 것을 표시합니다. 요구되는 처리는 두 번째 요구에 사용된 method가 GET 또는 HEAD일 경우에만 사용자와의 상호작용 없이도 수행될 수 있습니다. 사용자 에이전트는 이러한 방향 재설정이 무한 루프를 표시하는 것이기 때문에 다섯 번 이상 자동적으로 요구 방향 재설정을 해서는 안 됩니다.

300 Multiple Choices (복수 선택)
요청된 문서가 여러곳에 있을때 어떤 문서를 원하는지를 묻는 것입니다.
요구된 자원이 각자 자신 특유의 위치를 가지고 있는 표현 세트 중의 하나와 대응되며 사용자(또는 사용자 에이전트)가 선호하는 표현 방식을 선택하고 요구를 해당 위치로 재설정할 수 있도록 에이전트가 주도하는(agent-driven) 협상 정보가 제공됩니다.

HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함합니다. 엔터티 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시됩니다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있습니다. 그러나 이 규격은 이러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않습니다.

서버가 선호하는 표시 방법을 가지고 있으면 Location 필드에 해당 표시 방법에 대한 상세한 URL을 포함해야 합니다. 사용자 에이전트는 Location 필드 값을 이용하여 자동으로 방향을 재설정할 수 있습니다. 이 응답은 별도의 표시가 없는 한 캐시할 수 있습니다.

301 Moved Permanently (영구 이동)
요청된 문서의 위치가 영구적으로 변했음을 나타내는 것입니다.
요구된 자원에 새로운 영구 URI가 할당되었으며 향후 이 자원에 대한 참조는 리턴 된 URI 중 하나를 이용하여 이루어질 수 있습니다. 링크를 편집할 수 있는 능력이 있는 클라이언트는 가능하다면 Request-URI 에 대한 참조를 서버가 리턴한 하나 또는 그 이상의 새로운 참고처로 자동적으로 재링크시켜야 합니다. 다르게 표시되어 있지 않으면 이 응답은 캐시할 수 있습니다.

이 새로운 URL은 응답 메시지의 Location 필드로부터 전달된 것이어야 하는데, HEAD 요구의 경우가 아니라면 응답의 Entity-Body는 새로운 URL에 대한 하이퍼링크를 가진 짤막한 설명문을 갖고 있어야 합니다.

만약 POST 요구에 대한 응답으로 301 상태코드가 수신되면 사용자 에이전트는 사용자로부터 확인을 받지 않은 상태에서 요구 메시지를 자동 방향전환 시켜서는 안 됩니다. 왜냐하면 이것이 요구 메시지를 발생시킨 상황 조건에 대한 변화를 줄 수 있기 때문입니다.

[주] 301 상태코드를 수신한 후에 POST 요구를 자동 방향전환시키면 현재의 어떤 사용자 에이전트는 GET 요구로 바꾸어버리는 오류상황을 만들기도 합니다.

302 Found
요청된 URI는 일시적으로 새로운 URI를 가집니다.
Location 헤더는 새로운 장소를 가리킨다. 만일 이것이 GET 이나 HEAD 메소드에 대한 응답이라면 클라이이언트는 응답을 받자마자 요청을 해결하기 위해 새로운 URI를 사용해야 합니다.

303 See Other(다른 것을 참조)
요구된 자원이 별도의 URI(Location 헤더에 명시한)에 임시로 보관되어 있으며 해당 자원에서 GET method를 사용하여 조회해야 합니다.
이 method는 주로 POST가 활성화한 스크립트의 산출물을 사용자 에이전트가 선택된 자원으로 방향을 재설정할 수 있도록 하기 위해 사용됩니다. 새로운 URI는 처음 요구된 자원에 대한 대체 참고처가 아닙니다. 303 응답은 캐시할 수 없으나 두 번째(재설정된) 요구에 대한 응답은 캐시할 수 있습니다.

GET 또는 HEAD 이외의 요구에 대한 응답에 301 상태 코드가 접수되면 사용자 에이전트는 사용자가 확인하지 않는 한 요구를 발행한 조건을 변경할 수도 있기 때문에 자동적으로 요구의 방향을 재설정해서는 안 됩니다.

304 Not Modified(변경되지 않았음)
브라우저의 캐시에 들어있는 문서가 최신 문서이니 그것을 그대로 사용하라는것을 나타냅니다.
클라이언트가 조건적 GET 요구를 실행했고 접근할 수 있으나 문서가 변경되지 않았으면 서버는 이 상태코드로 응답해야 합니다. 이 응답은 Message-Body를 포함해서는 안 됩니다.

응답은 다음의 헤더 필드를 포함하고 있어야 합니다.

    ? 날짜
    ? ETag 및/또는 Content-Location, 동일한 요구에 대한 200 응답 속에 헤더가 발송되었을 경우
    ? Expires, Cache-Control, 및/또는 Vary, 동일한 변이에 대한 이전 응답 속에 발송된 field-value가 상이할 경우
조건적 GET이 강한 캐시 검증자를 사용했다면 응답은 다른 Entity-Header를 포함해서는 안 됩니다. 그렇지 않으면(조건적 GET이 약한 캐시 검증자를 사용할 때) 응답은 Entity-Header을 포함해서는 안 됩니다. 이렇게 하여 캐시 된 Entity-Body과 갱신된 헤더 사이의 불일치를 방지할 수 있습니다.
304 응답이 현재 캐시 되지 않은 엔터티를 표시할 때 캐시는 이 응답을 무시하고 조건 없이 요구를 반복해야 합니다.
캐시가 수신한 304 응답을 캐시 엔트리의 갱신에 사용한다면 캐시는 응답이 가지고 있는 새로운 필드 값을 반영하기 위해 엔트리를 반드시 갱신해야 한다.
304 응답은 Message-Body를 포함해서는 안되므로 항상 헤더 필드 다음의 첫 공백 라인으로 종료되어야 합니다.

305 Use Proxy(프락시를 사용할 것)
요청된 문서를 프록시를 통해서만 전송 받으라는 것을 나타냅니다.
요구된 자원을 Location 필드에 명시된 프락시를 통하여 접근해야만 합니다. Location 필드가 프락시의URL을 제공합니다. 수신측은 프락시를 통한 요구를 반복할 것으로 기대됩니다.

307 Temporary Redirect(임시 이동)
요청된 URI가 일시적으로 옮겨졌다는 뜻입니다.
Location 헤더가 새로운 장소를 가르킵니다. 이 상태 코드를 받는 즉시, 클라이언트는 요청을 해결하기 위해 새로운 URI를 사용해야 하지만 앞으로 모든 요청들은 이전의 URI를 사용할 것입니다.


Client Error 4xx

클라이언트의 요청이 불안전하며, 클라이언트 요청을 성공시키려면 다른 정보가 필요하다는 것을 말합니다.
상태 코드의 4xx 클래스는 클라이언트가 에러를 발생한 것처럼 보일 경우에 사용됩니다. HEAD 요구에 응답하는 경우를 제외하고는 서버는 임시적이건 영구적이건 에러 상황에 대한 설명을 포함한 엔터티를 포함해야 합니다. 이러한 상태 코드는 모든 요구 method에 적용할 수 있습니다. 사용자 에이전트는 사용자에게 포함된 엔터티를 표시해야 합니다.

[주] 클라이언트가 데이터를 발송한다면 TCP를 사용하는 서버 구현 방식은 서버가 입력 접속을 종료하기 전에 응답을 포함하고 있는 패킷 접수를 확인할 수 있도록 주의해야 합니다. 클라이언트가 접속이 종료된 후에도 계속해서 데이터를 전송한다면 서버의 TCP 스택은 리셋 패킷을 클라이언트에게 발송할 것입니다.
이 리셋 패킷은 HTTP 애플리케이션이 읽거나 해석하기 전에 클라이언트가 확인한 입력 버퍼를 지웁니다.

400 Bad Request(잘못된 요구)
클라이언트의 요청에 문법적인 오류가 있다는 것을 서버가 알아냈다는 것을 의미합니다.
잘못된 형식 때문에 서버가 요구를 이해할 수 없습니다. 클라이언트는 변경 없이 요구를 반복해서는 안 됩니다.

401 Unauthorized (인증되지 않았음)
클라이언트가 잘못된 인증정보를 Authorization 헤더에 넣었음을 나타냅니다.
응답이 사용자 인증을 요구합니다. 이 응답은 요구된 자원에 적용할 수 있는 설명 요구(challenge)를 포함하고 있는 WWW-Authenticate 헤더 필드를 포함하고 있어야 합니다. 클라이언트는 적절한 Authorization 헤더 필드를 가지고 요구를 반복할 수 있습니다. 요구가 벌써 Authorization 증명서를 포함하고 있다면 401 응답은 해당 증명서에 대한 인증이 거절되었음을 표시합니다. 401 응답이 이전 응답과 동일한 설명 요구를 포함하고 있고 사용자 에이전트가 한 번 이상 인증 획득을 시도했다면 해당 엔터티가 관련된 진단 정보를 포함하고 있기 때문에 사용자에게 응답에 표시된 엔터티를 표시해주야 합니다.

402 Payment Required
이 코드는 아직 HTTP로 구현되지 않았습니다. 하지만 언젠가는 서버의 문서를 받아보기 위해 지불이 필요하다는 것을 나타냅니다.

403 Forbidden(금지되었음)
클라이언트의 인증정보에 상관없이 페이지에 대한 접근을 거부한다는 것을 나타냅니다.
서버가 요구를 이해했으나 완료하는 것을 거절하고 있다는 의미로 인증은 적용되지 않으며 요구를 반복될 수 없습니다. 요구 method가 HEAD가 아니고 서버가 왜 요구가 완료되었는지 알리고 싶다면 엔터티 안에 거절한 이유를 기록해야 합니다. 이 상태 코드는 서버가 요구가 거부 사유를 밝히기 원하지 않을 때나 다른 응답을 적용할 수 없을 때 일반적으로 사용됩니다.

404 Not Found(찾을 수 없음)
클라이언트가 요청한 자원에 서버에 없다는 것을 나타냅니다.
서버가 Request-URI와 일치하는 것을 아무것도 발견하지 못했다는 의미로 이러한 상태가 잠정적인지 영구적인지 관한 아무런 표시도 주어지지 않은 경우입니다.

서버가 이 정보를 클라이언트에게 알리고 싶지 않을 경우 상태 코드 403(Forbidden)을 대신 사용할 수 있습니다. 내부적으로 환경을 설정할 수 있는 메커니즘을 통하여 이전의 자원을 영구적으로 사용할 수 없으며 전송 주소가 없다는 것을 알 수 있으면 410(Gone) 상태 코드를 사용합니다.

405 Method Not Allowed(Method를 사용할 수 없음)
Allow 헤더와 함께 클라이언트가 사용한 메소드가 이 URI에 대해 지원되지 않는다는 의미입니다.
Request-Line에 명시된 method를 Request-URI로 확인할 수 있는 자원에서 사용할 수 없습니다.
응답은 요구된 자원에 사용할 수 있는 method의 목록을 포함한 Allow 헤더를 포함해야 합니다.

406 Not Acceptable(접수할 수 없음)
클라이언트가 지정한 URI는 존재하지만 클라이언트가 원하는 형식이 아닙니다.
코드와 함께 서버는 Content-Language, Content-Encoding, Content-Type 헤더를 제공합니다. HEAD 요구가 아닌 이상 응답은 사용자 또는 사용자 에이전트가 가장 적합한 것을 선택할 수 있는 자원 특징 및 위의 목록을 포함한 엔터티를 포함합니다. 엔터티 포맷은 Content-Type 헤더 필드가 설정한 media type에 의해 명시됩니다. 사용자 에이전트의 포맷 및 성능에 따라 가장 적합한 선택을 결정하는 것은 자동으로 수행될 수 있습니다. 그러나 이 규격은 그러한 자동 선택의 표준에 대하여 아무런 규정도 하지 않습니다.

[주] HTTP/1.1 서버는 요구 메시지와 함께 발송된 Accept 헤더에 의해서 접수할 수 없는 응답을 리턴할 수 있게 합니다. 어떤 경우엔 이것이 406 응답을 발송하는 것보다 좋을 수도 있습니다. 사용자 에이전트는 도착하는 응답의 헤더를 검사하여 그것의 접수 여부를 결정하도록 추천합니다. 응답을 접수할 수 없을 때 사용자 에이전트는 잠정적으로 더 이상의 데이터를 수신하지 말아야 하며 추가 행동을 취할 것인지 사용자에게 질의합니다.

407 Proxy Authentication Required(프락시 인증 필요)
이 코드는 401(Unauthorized)과 유사하지만 클라이언트는 먼저 프락시에서 자기 자신을 인증해야 한다는 것을 표시 하는 것으로 proxy 서버로 로그온 한 후에 다시 시도해 봐야 합니다.
프락시는 요구된 자원의 프락시에 적용할 수 있는 설명 요구를 포함하는 Proxy-Authenticate 헤더 필드를 리턴해야 합니다. 클라이언트는 적절한 Proxy-Authorization 헤더 필드와 함께 요구를 반복해야 합니다.

408 Request Timeout(요구 시간 초과)
클라이언트의 모든 요청이 지정한 시간(일반적으로 서버를 구성할때 명시한다) 동안 처리되지 않았음을 의미합니다.
서버는 네트워크를 끊습니다. 클라이언트가 서버가 기다리도록 준비한 시간 내에 요구를 만들어 낼 수 없는 경우며 클라이언트는 나중에 변경 없이 요구를 반복할 수 있습니다.

409 Conflict(충돌)
다른 요청이나 서버의 구성과 충돌이 있음을 나타냅니다.
충돌에 대한 정보는 응답되는 데이터의 일부로 반환됩니다. 이 코드는 사용자가 충돌을 해결하고 요구를 재전송할 수 있을 것으로 기대할 수 있는 상황에서만 사용할 수 있습니다. 응답 본문은 사용자가 충돌의 원인을 인지할 수 있도록 충분한 정보를 포함해야 합니다. 이상적으로는 응답 엔터티가 사용자 또는 사용자 에이전트가 문제를 해결할 수 있을 정도의 충분한 정보를 포함할 수 있을 것입니다. 그러나 가능하지 않을 수도 있으며 필수 사항은 아닙니다.

충돌은 PUT 요구에 대한 응답으로 발생할 가능성이 높습니다. 버전 관리를 사용하고 있고 PUT 요구를 하는 엔터티가 이전 요구(제 3 자)가 작성한 요구와 충돌되는 자원에 대한 변경 사항을 포함하고 있다면 서버는 409 응답을 사용하여 요구를 완료할 수 없음을 표시해야 합니다. 이 경우 응답 엔터티는 응답 Content-Type이 규정한 형식으로 두 버전 사이의 차이점 목록을 포함해야 합니다.

410 Gone (내용물이 사라졌음)
요청된 문서가 사라지고, 새로운 주소는 알 수 없다는 것을 나타냅니다.
요구된 자원이 서버에 더 이상 존재하지 않으며 전송 주소를 알 수 없는 경우입니다. 이 조건은 영구적인 것으로 간주해야 합니다. 링크를 편집할 기능이 있는 클라이언트는 사용자 인증 후의 Request-URI에 대한 참고는 삭제해야 합니다. 서버가 그 조건이 영구적인지 여부를 알 수 없거나 결정할 시설이 없으면 상태 코드 401(Unauthorized)을 대신 사용해야 합니다. 다르게 표시되지 않는 한 이 응답은 캐시할 수 있습니다.

410 응답은 주로 수신측에게 자원을 의도적으로 사용할 수 없게 하였고 서버의 소유주가 해당 자원에 대한 원격 링크를 제거하고자 한다는 것을 알림으로써 웹 유지 작업을 지원하기 위해 사용됩니다. 이러한 일은 제한된 시간, 선전용 서비스 및 서버의 사이트에서 더 이상 일하지 않는 개인에게 소속된 자원에서 공통적으로 발생할 수 있습니다. 영구적으로 사용할 수 없는 모든 자원을 "사라진" 것으로 표시하거나 특정 시간 동안 표시를 유지할 필요는 없습니다.

411 Length Required(길이가 필요함)
서버가 규정된 Content-Length 없는 요구 접수를 거부하였다는 의미로 요구 메시지 내의 Message-Body의 길이를 포함하는 유효한 Content-Length 헤더 필드를 추가한다면 클라이언트는 요구를 반복할 수 있습니다.

412 Precondition Failed(사전 조건 충족 실패)
하나 또는 그 이상의 Request-Header에 명시된 조건에 의해 요청을 평가하여 false값을 가지는 경우입니다. 이 응답 코드는 클라이언트가 현재 자원의 메타 정보에 사전 조건을 부여할 수 있게 하여 의도하지 않는 자원에 요구 method를 적용하는 것을 방지합니다.

413 Request Entity Too Large(요구 엔터티가 너무 큼)
서버는 실제 본문이 너무 커서 요청을 처리할 수 없다는 것을 의미합니다.
요구 엔터티가 서버가 처리할 수 있거나 처리하려는 것보다 크기 때문에 서버가 요구 처리를 거부하는 경우로 서버는 클라이언트가 계속적으로 요구하는 것을 방지하기 위하여 연결을 종료합니다.

조건이 잠정적이면 서버는 Retry-After 헤더 필드를 포함하여 조건이 잠정적이며 얼마 후에 클라이언트가 재시도할 것인지를 표시합니다.

414 Request-URI Too Long(Request -URI가 너무 김)
서버는 요청된 URI가 너무 커서 요청을 처리할 수 없다는 것을 의미합니다.
Request-URI가 서버가 해석할 수 있는 것보다 크기 때문에 서버가 요구 처리를 거부하는 경우로 이처럼 드문 조건은 클라이언트가 부적절하게 질의 정보가 긴 POST 요구를 GET 요구로 변환했을때, 클라이언트가 방향 재설정의 URL "블랙 홀"로 빠졌을 때(방향이 재설정된 URL 접두사가 자신의 접미사를 지칭할 때), Request-URI를 읽거나 조작하는 고정-길이 버퍼를 사용하는 몇몇 서버에 존재하는 보안의 허점을 이용하려는 클라이언트로부터 서버가 공격을 받을 때만 발생하는 것 같습니다.

415 Unsupported Media Type(지원되지 않는 media type)
서버는 실제 본문이 지원되지 않는 형식이라 처리할 수 없다는 의미입니다.
요구의 엔터티가 요구 받은 method의 자원이 지원하지 않는 포맷으로 구성되어 있기 때문에 요구처리를 거부하였다는 의미입니다.

416 Requested range not satisfiable
서버는 어떤 유효한 값도 포함하지 않은 Range 헤더를 찾아냈습니다.
추가로 If-Range헤더는 없어졌습니다.

417 Expectation Failed
Exept헤더에서 명시된 조건은 만족될 수 없습니다.


Server Error 5xx

서버가 에러를 발생시켰으며 요구를 처리할 능력이 없음을 인지한 경우를 표시합니다. HEAD 요구에 응답하는 때를 제외하고는 서버는 에러 상황에 대한 설명및 에러가 잠정적인지 영구적인지에 관한 상황 설명을 포함하는 엔터티를 포함해야 합니다. 사용자 에이전트는 포함된 모든 엔터티를 사용자에게 표시하여야 한다. 이러한 응답 코드는 모든 요구 method에 적용할 수 있습니다.

500 Internal Server Error(서버 내부 에러)
서버의 일부(예를 들어 CGI 프로그램)가 멈추었거나 설정에서 오류(잘못된 결과나 적절하지 않은 헤더를 생성시키는 경우)가 나타났음을 의미합니다.

501 Not Implemented(구현되지 않았음)
클라이언트의 요청된 행위가 서버에서 수행할 수 없음을 의미합니다.
이것은 서버가 요구 method를 인지할 수 없고 어떠한 자원을 사용해도 지원할 수 없을 때 적절한 응답입니다.

502 Bad Gateway(불량 게이트웨이)
서버(또는 프락시)가 다른 서버(또는 프록시)로 부터의 응답이 적절하지 않음을 의미합니다.
게이트웨이나 프락시 역할을 수행하는 서버가 요구를 완료하려는 시도에서 접근한 업스트림(upstream) 서버로부터 유효하지 않은 응답을 수신했을 경우입니다.

503 Service Unavailable(서비스를 사용할 수 없음)
서비스를 일시적으로 제공할 수 없으나, 앞으로 복구된다는 의미입니다.
서버가 현재 잠정적인 오버로딩(overloading)이나 서버의 유지 작업 때문에 요구를 처리할 수 없다는 것으로 이것이 잠정적인 상황이며 얼마 후에는 완화될 수 있다는 것입니다. 알 수 있다면 지연 시간 길이를 Retry-After 헤더에 표시할 수 있습니다. 아무런 Retry-After 정보가 없으면 클라이언트는 500 응답을 처리하는 것처럼 응답을 처리해야 합니다.

[주] 503 상태 코드가 있다는 것이 서버가 오버로드 되었을 때 이것을 반드시 사용해야 된다는것을 의미하지 않습니다. 어떤 서버는 단순히 접속을 거부하고자 합니다.

504 Gateway Timeout(게이트웨이 시간 초과)
게이트웨이나 프락시 역할을 수행하는 서버가 시간 내에 요구를 완료하려는 시도에서 접근한 업스트림(upstream) 서버로부터 응답을 수신하지 못했을 경우입니다.

게이트웨이나 프락시의 시간이 경과했다는 것만 빼고는 408(Request time-out)과 같습니다.

505 HTTP Version Not Supported(지원되지 않는 HTTP 버전)
서버가 요구 메시지에서 사용된 HTTP 규약 버전을 지원하지 않거나 지원하기를 거부했다는 의미입니다.
서버는이 에러 메시지 이외에는 클라이언트가 사용하는 동일한 주요 버전을 사용하여 요구를 완료할 의사나 능력이 없음을 표시합니다. 응답은 왜 해당 버전이 지원되지 않으며 서버가 어떤 규약을 지원하는가를 설명하는 엔터티를 포함해야 합니다.


블로그 이미지

유효하지않음

,

공지사항

태그목록

글 보관함

달력

«   2024/04   »
일 월 화 수 목 금 토
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30

티스토리툴바