메소드 관리
메소드 관리
[템플릿관리] > [메소드]
메소드 정책 설정에서 사용할 메소드를 관리합니다.
메소드 룰이 적용되는 정책의 목록은 아래와 같습니다.
| 템플릿 | 보안정책 탭 | 세부 정책 |
|---|---|---|
| 메소드 | 도메인 보안정책 | 메소드정책 |
메소드 추가
[템플릿관리] > [메소드] > [추가]
메소드 정책을 적용할 메소드를 추가합니다. [추가]를 클릭하여 추가될 메소드 정보를 입력한 후 [확인]을 클릭합니다. 메소드 보안정책은 메소드 별로 설정 가능합니다. 메소드가 추가되면 추가에 대한 감사로그가 생성됩니다.
| 항목 | 설명 |
|---|---|
| 이름 | 메소드 이름을 입력합니다. 최대 50자까지 입력 가능합니다. |
| 타입 | 메소드를 검사할 타입을 선택합니다. Allow Request, WebDAV가 있습니다. 기본값(Allow Request) |
| 설명 | 메소드에 대한 설명을 입력합니다. |
메소드 수정
[템플릿관리] > [메소드] > (메소드 선택) > [수정]
메소드를 수정합니다. 수정할 메소드를 선택한 후 [수정]을 클릭하여 변경할 정보를 입력한 후 [확인]을 클릭합니다. 메소드가 수정되면 수정에 대한 감사로그가 생성됩니다.
메소드 삭제
[템플릿관리] > [메소드관리] > (메소드 선택) > [삭제]
메소드를 삭제합니다. 삭제할 메소드를 선택한 후 [삭제]를 클릭합니다. 메소드에 정책이 설정되어 있을 경우 메소드 삭제가 되지 않으므로 메소드를 삭제하기 전에 해당 보안 정책을 먼저 삭제하시기 바랍니다. 메소드가 삭제되면 삭제에 대한 감사로그가 생성됩니다.
메소드 설명
| 항목 | 설명 |
|---|---|
| GET | Request-URI가 식별하는 모든 정보(엔터티의 형태로)를 조회한다는 것을 의미합니다. Request-URI가 데이터를 생성하는 프로세스를 참조한다면 텍스트가 우연히 프로세스의 산출물이 아닌 이상 엔터티로서 리턴 되는 것은 프로세스의 소스 텍스트가 아니라 생성된 데이터입니다. 이 메소드의 의미는 요구 메시지가 If-Modified-Since, If-Unmodified-Since, If-Match, If-None-Match 또는 If-Range 헤더 필드를 포함하고 있으면 "조건적인 GET"으로 변화합니다. 조건적인 GET method는 엔터티가 조건 헤더 필드가 명시한 조건 하에서만 전송되도록 요청하는 것입니다. 조건적 GET method는 복수의 요구나 클라이언트가 이미 보유하고 있는 데이터를 전송하지 않고도 캐시 된 엔터티를 갱신할 수 있도록 함으로서 불필요한 네트워크 사용을 감소시키기 위해 사용합니다. GET method의 의미는 요구 메시지가 Range 헤더 필드를 포함하고 있으면 "부분적인 GET"으로 변화합니다. 부분적 GET method는 클라이언트가 이미 보유하고 있는 데이터를 전송하지 않고도 부분적으로 조회한 엔터티가 완성될 수 있도록 함으로써 불필요한 네트워크 사용을 감소시키기 위해 사용합니다. |
| HEAD | 서버가 응답 메시지에 Message-Body를 반드시 리턴해야 한다는 것 이외에는 GET과 동일합니다. 이 method는 Entity-Body 자체를 전송하지 않고도 요구가 내포하는 엔터티에 대한 메타 정보를 얻는 데 사용할 수 있습니다. 이 method는 종종 하이퍼텍스트 링크의 유효성, 접근성 및 최근의 변경 사항을 테스트하기 위해 사용되기도 합니다. |
| POST | 서버에게 Request-Line의 Request-URI가 식별하는 자원의 새로운 부속물로서 요구에 포함된 엔터티를 접수할 것을 요구하는 데 사용합니다. POST는 다음의 기능을 수행하는 일관된 method를 사용할 수 있도록 디자인 되었습니다. 1. 기존 자원의 주해 2. 게시판, 뉴스그룹, 편지 발송 목록 또는 유사한 기사 그룹으로 메시지를 송부 3. 폼을 제출한 결과로 발생한 데이터 블록을 데이터 처리 프로세스에 제공 4. 추가 작업을 통한 데이터 베이스의 확장 POST method가 실제적으로 수행하는 기능은 서버가 결정하며 보통 Request-URI에 달려 있습니다. 발송된 엔터티는 파일이 파일을 포함하고 있는 디렉토리에 종속되고, 뉴스 기사가 발송한 뉴스그룹에 종속되며 레코드가 데이터 베이스에 종속되듯이 해당 URI에 종속됩니다. POST method가 수행하는 작업이 URI로 식별할 수 있는 자원을 생성하지 않을 수도 있습니다. 이러한 경우 응답이 결과를 설명하는 엔터티를 포함하고 있는가 여부에 따라 200(OK)이나 204(No Content)가 적절한 응답 상태가 됩니다. |
| DELETE | 이 메소드는 Request-URI가 식별하는 자원을 삭제하도록 웹 서버에 요구합니다. 이 method는 웹 서버에서 사용자의 개입(또는 다른 방법)에 의하여 무시될 수 있습니다. 클라이언트는 비록 웹 서버에서 발송한 상태 코드가 해당 작업이 성공적으로 완수되었다는 표시를 하여도 실제로 작업이 완료되었다는 보장을 받을 수 없습니다. 그러나 서버는 요구를 접수한 시점에서 자원을 삭제하거나 접근할 수 없는 위치로 이동할 의사가 없는 한 성공을 표시해서는 안 됩니다. 성공적인 응답은 응답이 상태를 설명하는 엔터티를 포함한다면 200 (OK)를, 처리가 시작되지 않았으면 202 (Accepted)를, 응답은 OK이나 엔터티를 포함하지 않고 있으면 204 (No Content)를 부려줍니다. |
| OPTIONS | Request-URI에 의하여 식별되는 Request/Response chain에서 사용할 수 있는 통신 선택 사항에 관한 정보 요구를 표시합니다. 이 메소드는 클라이언트가 자원 처리를 시도하거나 자원 조회를 시작하지 않고도 선택 사항 및/또는 자원과 관련된 필요 조건, 서버의 처리 능력을 결정할 수 있게 합니다. Request-URI 가 별표("*")이면 OPTIONS 요구는 전체를 서버에 적용하려는 것입니다. |
| PROPFIND | 리소스를 위한 속성을 검색합니다. 즉, 웹의 파일 목록과 속성을 검색합니다. |
| PUT | 동봉된 엔터티를 제공된 Request-URI에 저장하도록 요구합니다. Request-URI가 이미 존재하는 자원을 지칭할 경우 동봉된 엔터티는 웹 서버에 있는 엔터티의 변경된 버전으로 간주해야 합니다. Request-URI가 기존 자원을 지칭하지 않고 URI가 요구하는 사용자 에이전트가 새로운 자원으로 규정할 수 있다면 웹 서버는 해당 URI로 자원을 생성할 수 있습니다. 만약 새로운 자원이 생성되었으면 웹 서버는 사용자 에이전트에게 201(Created) 응답을 알려야 합니다. 기존 자원이 변경되었다면 200(OK)이나 204 (No Content) 응답 코드를 발송하여 요구를 성공적으로 완료하였음을 표시하여야 합니다. |
| TRACE | TRACE method는 요구 메시지의 원격지, 애플리케이션-계층 루프백(loop back)을 호출하는 데 사용합니다. 응답의 최종 수신측은 클라이언트에게 되돌려 진 메시지를 200(OK) 응답의 Entity-Body로 수신해야 합니다. 마지막 수신측은 메시지의 Max-Forwards 제로 값을 수신하는 웹 서버, 첫 프락시 또는 게이트웨이입니다. TRACE는 클라이언트가 Request chain의 다른 끝 쪽에 무엇이 수신되는가를 알 수 있게 하며 그 데이터를 시험 또는 진단 정보로 사용한다. Via 헤더 필드의 값은 Request chain의 추적 역할을 수행하기 때문에 특히 주목할 만합니다. Max-Forwards 헤더 필드를 사용하면 클라이언트가 Request chain의 길이를 제한할 수 있으며 이는 무한 루프에서 메시지를 전달하는 프락시 고리를 테스트하는 데 유용합니다. |
| TRACK | 디버깅 목적을 위해서 사용합니다. 하지만 일반적인 웹서비스 환경에서는 흔히 사용하지 않습니다. |