CGI(Common Gateway Interface) [22]를 사용하면 HTTP [1], [4] 서버 및 CGI 스크립트가 클라이언트 요청에 응답하는 책임을 공유할 수 있습니다. 클라이언트 요청은 URI(Uniform Resource Identifier) [11], 요청 방법 및 전송 프로토콜이 제공하는 요청에 대한 다양한 보조 정보로 구성됩니다.

CGI는 클라이언트의 요청을 설명하는 메타 변수라고 알려진 추상 매개 변수를 정의합니다. 구체적인 프로그래머 인터페이스와 함께 이것은 스크립트와 HTTP 서버 사이의 플랫폼 독립적인 인터페이스를 지정한다.

서버는 클라이언트 요청과 관련된 연결, 데이터 전송, 전송 및 네트워크 문제를 관리하는 반면 CGI 스크립트는 데이터 액세스 및 문서 처리와 같은 응용 프로그램 문제를 처리합니다.

1.2 요구 사항

구현은 구현되는 프로토콜에 대한 하나 이상의 '필수' 요구사항을 충족하지 못하면 준수되지 않는다. 특징에 대한 모든 '필수' 요건과 모든 '필수' 요건을 충족하는 구현을 '무조건 준수'라고 하며, 모든 '필수' 요건을 충족하지만 그것의 특징에 대한 모든 '필수' 요건을 충족시키지 못하는 것을 '조건 준수'라고 한다.

1.3 명세서

CGI의 모든 기능 및 기능이 에 정의되어 있는 것은 아닙니다.

본 명세서의 주요 부분 다음 문구는 다음에 사용됩니다.

지정되지 않은 기능에 대해 설명합니다.

system-defined

이 기능은 시스템마다 다를 수 있지만 동일한 시스템을 사용하는 여러 구현에서 동일해야 합니다. 시스템은 일반적으로 운영 체제의 클래스를 식별합니다. 일부 시스템은 본 문서의 섹션 7에 정의되어 있습니다. 새로운 시스템은 본 문서의 개정 없이 새로운 사양으로 정의될 수 있습니다.

implementation-defined

기능의 동작은 구현마다 다를 수 있습니다. 특정 구현은 해당 동작을 문서화해야 합니다.

1.4 술어

이 규격은 HTTP/1.1 규격[4]에 정의된 많은 용어를 사용하지만, 다음 용어는 해당 문서의 정의 또는 공통의 의미와 일치하지 않을 수 있는 의미로 여기에 사용된다.

‘메타변수’

서버에서 스크립트로 정보를 전달하는 명명된 매개 변수입니다. 그것이 가장 일반적인 구현이지만 반드시 운영 체제 환경의 변수일 필요는 없다.

'스크립트'

이 인터페이스에 따라 서버에서 호출되는 소프트웨어입니다. 독립형 프로그램일 필요는 없지만 동적으로 로드되거나 공유되는 라이브러리일 수도 있고 서버의 서브루틴일 수도 있다. 이것은 '스크립트'라는 용어가 자주 이해되기 때문에 실행 시 해석되는 진술의 집합일 수 있지만, 그것은 요건이 아니며 이 명세서의 맥락에서 용어는 더 넓은 정의가 명시되어 있다.

'서버'

클라이언트의 요청을 처리하기 위해 스크립트를 호출하는 응용 프로그램입니다

2. 표기법 및 일반 문법

2.1 BNF

이 문서에 명시한 모든 메커니즘은 RFC 822에서 사용한 것과 유사한 산문과 증강 BNF으로 설명된다[13]. 달리 명시되지 않는 한, 요소는 대소문자를 구분합니다. 이 증강된 BNF는 다음과 같은 구성을 포함합니다.

이름 = 정의

규칙의 이름과 정의는 등호 문자('=')로 구분됩니다. 공백은 정의의 연속선이 들여쓰기된다는 점에서만 중요합니다.

"literal"

이중 따옴표(")는 리터럴 텍스트를 둘러싸지만, 리터럴 따옴표('<' 및 '>')는 리터럴 따옴표(단, 리터럴 따옴표는 제외).

rule1 | rule2

대체 규칙은 세로 막대('|')로 구분됩니다.

(rule1 rule2 rule3)

괄호로 묶인 요소는 단일 요소로 처리됩니다.

*rule

별표('*') 앞에 오는 규칙에는 0개 이상의 항목이 있을 수 있습니다. 전체 형식은 'n*m rule'로 최소 n개 및 최대 m개의 규칙 발생을 나타냅니다. n과 m은 각각 기본값 0과 무한대의 선택적 소수 값입니다.

[rule]

대괄호('[' 및 ']')로 둘러싸인 요소는 선택 사항이며 '*1 규칙'과 동일합니다.

N 규칙

십진수 앞에 오는 규칙은 정확히 N개의 규칙 발생을 나타냅니다. 이것은 'N*N 규칙'과 같다.

2.2 기본 규칙

이 규격은 문자의 관점에서 정의된 BNF와 유사한 문법을 사용한다. 프로토콜에 의해 허용되는 바이트를 정의하는 많은 사양과는 달리, 여기서 문법의 각 리터럴은 그것이 나타내는 문자에 대응한다. 이러한 문자가 시스템 내에서 비트 및 바이트 단위로 표현되는 방법은 시스템 정의되거나 특정 컨텍스트에서 지정됩니다. 단 하나의 예외는 아래에 정의된 규칙 'OCTET'입니다.

본 명세서에서 기본적인 구문 분석 구조를 설명하기 위해 사용되는 규칙은 다음과 같다.

줄 바꿈(NL)은 single control char 가 아니라 sequence of control char 일 수 있습니다. 시스템은 텍스트를 <CTL을 제외하고 LWSP를 포함하는 임의의 문자 집합보다 더 큰 문자 집합으로 정의할 수 있다.

2.3 URL 인코딩

여기서 사용되는 일부 변수와 구조는 'URL 인코딩'으로 설명된다. 이 인코딩은 RFC 2396 [2]의 섹션 2에 설명되어 있습니다. URL 인코딩 문자열에서 이스케이프 시퀀스는 백분율 문자("%")와 두 개의 16진수 자리(여기서 두 개의 16진수 자리)로 구성됩니다. 이스케이프 시퀀스는 US-ASCII [9] 코드화된 문자 집합(있는 경우) 내의 코드로 옥텟이 있는 그래픽 문자를 나타냅니다. 현재 URI 구문에는 ASCII가 아닌 문자 집합을 식별할 수 있는 조항이 없습니다. 코드는 이를 나타내므로 CGI는 이 문제를 임시방편으로 처리한다.

일부 안전하지 않은(예약된) 문자는 인코딩될 때 다른 의미를 가질 수 있습니다. 안전하지 않은 문자의 정의는 상황에 따라 달라진다. 권위 있는 취급에 대해서는 RFC 2732[7]에 의해 업데이트된 RFC 2396[2]의 섹션 2를 참조한다. 이러한 예약된 문자는 일반적으로 문자열에 구문 구조를 제공하는 데 사용됩니다(예: 필드 구분 기호). 모든 경우에, 문자열은 먼저 존재하는 예약된 문자와 관련하여 처리된 다음, "%" 이스케이프 시퀀스를 문자 값으로 대체하여 결과 데이터를 URL 디코딩할 수 있다.

문자열을 인코딩하기 위해 예약된 모든 문자 및 금지된 문자가 해당 "%" 이스케이프 시퀀스로 대체됩니다. 이 문자열은 URI를 조립하는 데 사용될 수 있다. 예약된 문자는 컨텍스트에 따라 다르지만 항상 다음 집합에서 그립니다.

마지막 두 문자는 RFC 2732 [7]에 의해 추가되었다. 특정 컨텍스트에서 이러한 문자의 하위 집합은 예약됩니다. 이 집합의 다른 문자는 문자열이 해당 컨텍스트에서 URL 인코딩될 때 인코딩되지 않아야 합니다. URI 구문을 설명하는 데 사용되는 다른 기본 규칙은 다음과 같습니다.

3. 스크립트 호출

3.1 서버 책임

서버는 응용 프로그램 게이트웨이 역할을 합니다. 클라이언트로부터 요청을 수신하고, 요청을 처리할 CGI 스크립트를 선택하고, 클라이언트 요청을 CGI 요청으로 변환하고, 스크립트를 실행하고 CGI 응답을 클라이언트에 대한 응답으로 변환합니다. 클라이언트 요청을 처리할 때 프로토콜 또는 전송 수준 인증 및 보안을 구현할 책임이 있습니다. 서버는 또한 미디어 유형 변환 또는 프로토콜 감소와 같은 일부 추가 서비스를 제공하기 위해 요청 또는 응답을 수정하는 'non-transparent' 방식으로 작동할 수 있습니다.

서버는 이 사양에 필요한 클라이언트 요청 데이터에 대해 변환 및 프로토콜 변환을 수행해야 합니다.더욱이, 서버는 CGI 스크립트가 이 규격을 준수하지 못하더라도 관련 네트워크 프로토콜을 준수하도록 클라이언트에 대한 책임을 유지한다.

서버가 요청에 인증을 적용하는 경우, 요청이 정의된 모든 접근 제어를 통과하지 않는 한 스크립트를 실행해서는 안 됩니다.

3.2 스크립트 선택

서버는 클라이언트가 제공한 제네릭 양식 URI를 기반으로 실행할 CGI를 결정합니다. 이 URI에는 "/"로 구분된 구성 요소가 있는 계층 경로가 포함됩니다. 특정 요청의 경우, 서버는 이 경로의 전부 또는 선행 부분을 개별 스크립트로 식별하여 경로 계층의 특정 지점에 스크립트를 배치합니다. 경로의 나머지(있는 경우)는 스크립트에서 해석할 리소스 또는 하위 리소스 식별자입니다.

이 경로 분할에 대한 정보는 아래에 설명된 메타 변수의 스크립트에서 사용할 수 있습니다. 비계층적 URI 체계에 대한 지원은 본 명세서의 범위를 벗어난다.

3.3 스크립트 URI

클라이언트 요청 URI에서 스크립트 선택으로의 매핑은 특정 서버 구현 및 구성에 의해 정의됩니다. 서버는 스크립트를 여러 개의 다른 URI 경로 계층 집합으로 식별하도록 허용하므로 메타 변수를 처리하고 생성하는 동안 이 집합의 다른 멤버에 의해 URI를 대체할 수 있다.

서버는

1. 특정 클라이언트 요청에 URI를 보존할 수 있습니다. 또는

2. 각 스크립트에 대해 가능한 값 집합에서 표준 URI를 선택할 수 있습니다. 또는

3. 세트에서 URI의 다른 선택을 구현할 수 있다.

이렇게 생성된 메타 변수로부터 URI, 즉 'Script-URI'를 구성할 수 있다. 클라이언트가 대신 이 URI에 액세스했다면 스크립트가 SCRIPT_NAME, PATH_INFO 및 QUERY_STRING 메타 변수에 대해 동일한 값으로 실행되었을 것이라는 속성이 있어야 합니다. Script-URI는 RFC 2396[2]의 섹션 3에 정의된 일반 URI의 구조를 가지고 있다. 스크립트-URI의 다양한 구성 요소는 일부 메타 변수에 의해 정의됩니다(아래 참조).

여기서 sheme from SERVER_PROTOCOL, <server-name>, <server-port> 및 <query-string>은 각 메타 변수의 값입니다. ";", "=" 및 "?"로 URL 인코딩된 SCRIPT_NAME 및 PATH_INFO 값은 예약됨으로, <script-path> 및 <path-path>를 지정합니다.

PATH_INFO 메타 변수에 대한 자세한 내용은 섹션 4.1.5를 참조하십시오.

스키마와 프로토콜은 스키마가 애플리케이션 프로토콜 외에 액세스 방법을 식별하기 때문에 동일하지 않다. 예를 들어, 전송 계층 보안(TLS)을 사용하여 액세스된 리소스[14]는 HTTP 프로토콜을 사용할 때 https 체계가 있는 요청 URI를 가집니다 [19]. CGI/1.1은 스크립트가 이를 재구성하는 일반적인 방법을 제공하지 않으므로 정의된 대로 Script-URI에는 사용되는 기본 프로토콜이 포함됩니다. 그러나 스크립트는 URI 체계를 더 잘 추론하기 위해 체계별 메타 변수를 사용할 수 있다.

또한 이 정의는 적절한 구성 요소를 수정하여 path-info 또는 query-string에 대해 허용된 값으로 스크립트를 호출하는 URI를 구성할 수 있습니다.

3.4 실행

스크립트는 시스템 정의 방식으로 호출됩니다. 달리 지정하지 않으면 스크립트가 포함된 파일이 실행 프로그램으로 호출됩니다. 서버는 섹션 4에 설명된 대로 CGI 요청을 준비합니다. 이것은 요청 메타 변수(실행 시 스크립트에 즉시 사용 가능)와 요청 메시지 데이터로 구성됩니다. 스크립트에서 요청 데이터를 즉시 사용할 필요는 없습니다. 스크립트는 서버에서 클라이언트로부터 모든 데이터를 수신하기 전에 실행할 수 있습니다. 섹션 5 및 6에 설명된 대로 스크립트의 응답이 서버로 반환됩니다.

오류 조건이 발생할 경우 서버는 언제든지 경고 없이 스크립트 실행을 중단하거나 종료할 수 있습니다. 예를 들어 서버와 클라이언트 간의 전송 오류가 발생할 경우 이러한 문제가 발생할 수 있으므로 스크립트는 비정상적인 종료를 처리할 수 있도록 준비해야 합니다.

4. CGI request

요청에 대한 정보는 요청 메타 변수와 관련된 메시지 본문의 두 가지 소스로부터 나옵니다.

4.1 Request 메타 변수

메타 변수는 서버에서 스크립트로 전달된 요청에 대한 데이터를 포함하며, 시스템 정의 방식으로 스크립트에 의해 액세스됩니다. 메타 변수는 대/소문자를 구분하지 않는 이름으로 식별됩니다. 대/소문자를 구분하지 않는 이름을 가진 두 개의 다른 변수는 있을 수 없습니다. 여기에서는 대문자 및 밑줄("_")의 정규 표현을 사용하여 보여준다. 특정 시스템은 다른 표현을 정의할 수 있다.

구성표와 이름이 같은 메타 변수, 프로토콜 또는 구성표의 이름으로 시작하는 이름(예: HTTP_ACCEPT)도 정의됩니다. 이러한 변수의 수와 의미는 본 명세서와 독립적으로 변경될 수 있다. (섹션 4.1.18도 참조).

서버는 추가 구현 정의 확장 메타 변수를 설정할 수 있으며, 메타 변수의 이름은 "X_"로 접두사가 붙어야 합니다.

이 규격에서는 0 길이(NULL) 값과 결측값을 구분하지 않습니다. 예를 들어 스크립트는 두 요청 http://host/script와 http://host/script?를 구분할 수 없습니다. 두 경우 모두 QUERY_STRING 메타 변수가 NULL이 되기 때문입니다.

meta-meta-value = " | 1*<값의 TEXT, CHAR 또는 토큰>

선택적 메타 변수는 값이 NULL인 경우 생략(설정되지 않은 상태로)될 수 있습니다. 메타 변수 값은 별도의 언급이 없는 한 대소문자를 구분하는 것으로 간주해야 합니다. 메타 변수에 있는 문자의 표현은 시스템 정의이며, 서버는 값을 해당 표현으로 변환해야 합니다.

4.1.1 AUTH_TYPE

AUTH_TYPE 변수는 서버가 사용자를 인증하는 데 사용하는 메커니즘을 식별합니다. 클라이언트 프로토콜 또는 서버 구현에 의해 정의된 대소문자를 구분하지 않는 값을 포함합니다.

HTTP의 경우, 클라이언트가 외부 액세스를 위해 인증을 요구하는 경우, 서버는 요청 권한 부여 헤더 필드의 'auth-scheme' 토큰에서 이 변수의 값을 설정해야 합니다.

HTTP 액세스 인증 체계는 RFC 2617[5]에 설명되어 있습니다.

4.1.2 CONTENT_LENGTH

CONTENT_LENGTH 변수에는 요청에 첨부된 메시지 본문의 크기가 10진수 옥텟으로 포함됩니다. 연결된 데이터가 없으면 NULL(또는 unset)을 클릭합니다.

서버는 요청이 메시지 본문 엔티티에 수반되는 경우에만 이 메타 변수를 설정해야 합니다. CONTENT_LENGTH 값은 서버가 transfer-codings or content-codings을 제거한 후 메시지 본문의 길이를 반영해야 합니다.

4.1.3 CONTENT_TYPE

요청에 메시지 본문이 포함된 경우 CONTENT_TYPE 변수는 메시지 본문의 인터넷 미디어 유형[6]으로 설정됩니다.

유형, 하위 유형 및 매개 변수 특성 이름은 대소문자를 구분하지 않습니다. 매개 변수 값은 대소문자를 구분할 수 있습니다. 미디어 유형과 HTTP에서의 미디어 사용은 HTTP/1.1 규격의 섹션 3.7에 설명되어 있습니다 [4].

이 변수에는 기본값이 없습니다. 설정 해제된 경우에만 스크립트가 수신된 데이터에서 미디어 유형을 확인할 수 있습니다. 유형이 알려지지 않은 경우 스크립트는 응용 프로그램/옥텟 스트림 유형을 가정하거나 오류와 함께 요청을 거부할 수 있습니다(섹션 6.3.3 참조).

각 미디어 유형은 선택적 매개 변수 및 필수 매개 변수 집합을 정의합니다. 여기에는 메시지 본문에 대한 코드화된 문자 집합을 정의하는 대소문자를 구분하지 않는 값을 갖는 문자 집합 매개변수가 포함될 수 있다. charset 매개 변수가 생략된 경우 기본값을 가장 먼저 적용할 다음 규칙 중 하나에 따라 파생해야 합니다.

1. 일부 미디어 유형에는 시스템 정의 기본 문자 집합이 있을 수 있습니다.

2. "텍스트" 유형의 미디어 유형의 기본값은 ISO-8859-1 [4]입니다.

3. 미디어 유형 규격에 정의된 기본값입니다.

4. 기본값은 US-ASCII입니다.

HTTP Content-Type 필드가 클라이언트 요청 헤더에 있는 경우 서버는 이 메타 변수를 설정해야 합니다. 서버가 첨부된 엔티티가 있지만 내용 유형 머리글 필드가 없는 요청을 수신하는 경우, 올바른 내용 유형을 확인할 수 있으며, 그렇지 않은 경우 이 메타 변수를 생략해야 합니다.

4.1.4 GATEWAY_INTERFACE

Gateway_Interface 변수는 서버가 스크립트와 통신하기 위해 사용하는 CGI의 방언으로 설정해야 합니다.

주수와 부수는 별도의 정수로 처리되므로 각각 한 자리 수보다 더 높게 증가할 수 있습니다. 따라서 CGI/2.4는 CGI/2.13보다 낮은 버전이다. 선행 0은 스크립트에서 무시해야 하며 서버에서 생성해서는 안 됩니다.

이 문서는 CGI 인터페이스의 1.1 버전을 정의합니다.

4.1.5 PATH_INFO

PATH_INFO 변수는 CGI 스크립트에서 해석할 경로를 지정합니다. CGI 스크립트가 반환할 리소스 또는 하위 리소스를 식별하고 스크립트 자체를 식별하는 부분 뒤에 이어지는 URI 경로 계층에서 파생됩니다. URI 경로와 달리 PATH_INFO는 URL 인코딩이 아니므로 경로 세그먼트 매개 변수를 포함할 수 없습니다. "/"의 PATH_INFO는 단일 보이드 경로 세그먼트를 나타냅니다.

이 값은 대소문자를 구분하는 것으로 간주되며 서버는 요청 URI에 표시된 경로의 대소문자를 보존해야 합니다. 서버는 PATH_INFO에 대해 허용하는 값에 제한 및 제한을 가할 수 있으며, 부적합한 값이 발견되면 오류와 함께 요청을 거부할 수 있습니다. 인코딩된 "/"가 PATH_INFO로 디코딩되는 모든 요청을 포함할 수 있는데, 이는 스크립트에 대한 정보 손실을 나타낼 수 있기 때문이다. 마찬가지로 경로에서 US-ASCII가 아닌 문자에 대한 처리도 시스템 정의됩니다.

URL 인코딩된 PATH_INFO 문자열은 해당 경로의 SCRIPT_NAME 부분을 따르는 Script-URI의 추가 경로 구성 요소(섹션 3.3 참조)를 형성합니다.

4.1.6 PATH_TRANSLATED

4.1.7 QUERY_STRING

4.1.8 REMOTE_ADDR

4.1.9 REMOTE_HOST

4.1.10 REMOTE_IDENT

4.1.11 REMOTE_USER

4.1.12 REQUEST_METHOD

REQUEST_METHOD 메타 변수는 섹션 4.3에서 설명한 대로 스크립트가 요청을 처리하는 데 사용할 메서드로 설정해야 합니다.

이 메서드는 대소문자를 구분합니다. HTTP 방법은 HTTP/1.0 규격[1]의 섹션 5.1.1과 HTTP/1.1 규격[4]의 섹션 5.1.1에 설명되어 있습니다.

4.1.13 SCRIPT_NAME

4.1.14 SERVER_NAME

4.1.15 SERVER_PORT

4.1.16 SERVER_PROTOCOL

SERVER_PROTOCOL 변수는 이 CGI 요청에 사용 되는 응용 프로그램 프로토콜의 이름과 버전으로 설정해야 합니다. 이것은 서버가 클라이언트와의 통신에서 사용하는 프로토콜 버전과 다를 수 있습니다.

여기서 'protocol'은 서버와 스크립트('protocol-specific' 기능) 사이에 전달되는 일부 정보의 구문을 정의합니다. 대/소문자를 구분하지 않으며 일반적으로 대/소문자를 구분합니다. 프로토콜은 클라이언트가 서버와 통신하기 위해 사용하는 전체 액세스 메커니즘을 정의하는 스크립트 URI의 구성표 부분과 동일하지 않습니다. 예를 들어, "HTTP" 프로토콜로 스크립트에 도달하는 요청은 "https" 체계를 사용했을 수 있습니다.

서버가 사용할 수 있는 SERVER_Protocol의 잘 알려진 값은 "포함됨"이며, 이는 현재 문서가 클라이언트 요청의 직접적인 대상이 아닌 복합 문서의 일부로 포함됨을 나타냅니다. 스크립트는 이 요청을 HTTP/1.0 요청으로 처리해야 합니다.

4.1.17 SERVER_SOFTWARE

4.1.18 Protocol-Specific Meta-Variable

서버는 요청에 대한 프로토콜 및 구성표와 관련된 메타 변수를 설정해야 합니다. 프로토콜별 변수의 해석은 SERVER_PROTOCOL의 프로토콜 버전에 따라 달라집니다. 구성표가 프로토콜과 동일하지 않은 경우, 서버는 구성표 이름을 가진 메타 변수를 NULL이 아닌 값으로 설정할 수 있습니다. 이러한 변수의 존재는 요청에 의해 사용되는 체계를 스크립트에 나타냅니다.

이름이 "HTTP_"로 시작하는 메타 변수에는 사용된 프로토콜이 HTTP인 경우 클라이언트 요청 헤더 필드에서 읽은 값이 포함됩니다. HTTP 헤더 필드 이름은 대문자로 변환되고 "-"가 모두 "_"로 대체되며 메타 변수 이름을 부여하기 위해 "HTTP_"가 앞에 추가됩니다. 헤더 데이터는 클라이언트에 의해 전송된 대로 제시되거나 의미론을 변경하지 않는 방식으로 다시 작성될 수 있습니다. 동일한 필드 이름을 가진 여러 헤더 필드가 수신된 경우, 서버는 동일한 의미를 가진 단일 값으로 다시 작성해야 합니다. 마찬가지로 여러 줄에 걸쳐 있는 헤더 필드는 한 줄에 병합되어야 합니다. 필요한 경우 서버는 CGI 메타 변수에 적합하도록 데이터의 표현(예: 문자 집합)을 변경해야 합니다.

서버가 수신하는 모든 헤더 필드에 대해 메타 변수를 작성할 필요는 없습니다. 특히 인증 정보를 전달하는 헤더 필드(예: 'Authorization') 또는 'Content-Length' 및 'Content-Type'과 같은 다른 변수의 스크립트에서 사용할 수 있는 헤더 필드는 모두 제거해야 합니다. 서버는 '연결'과 같은 클라이언트 측 통신 문제와만 관련된 헤더 필드를 제거할 수 있습니다.

4.2 Request Message-Body

요청 데이터는 시스템 정의 방식으로 스크립트에 액세스됩니다. 달리 정의되지 않은 한 '표준 입력' 파일 설명자나 파일 핸들을 읽어야 합니다.

CONTENT_LENGTH가 NULL이 아닌 경우 요청 본문이 요청과 함께 제공됩니다. 서버는 스크립트가 읽을 수 있는 바이트 수 이상을 제공해야 합니다. 서버는 CONTENT_LENGTH 바이트를 읽은 후 파일 종료 조건을 신호로 표시하거나 확장자 데이터를 제공할 수 있습니다. 따라서 스크립트는 더 많은 데이터를 사용할 수 있더라도 CONTENT_LENGTH 바이트 이상을 읽으려고 시도해서는 안 됩니다. 그러나 데이터를 읽을 의무는 없습니다.

NPH(Non-parsed Header) 스크립트(섹션 5)의 경우 서버는 스크립트에 제공된 데이터가 클라이언트가 제공한 대로 정확하게 서버에 의해 변경되지 않도록 시도해야 합니다.

전송 인코딩은 요청 본문에서 지원되지 않으므로 서버는 메시지 본문에서 이러한 인코딩을 제거하고 content_length를 다시 계산해야 합니다. 이 작업이 가능하지 않으면(예: 버퍼링이 크기 때문에) 서버는 클라이언트 요청을 거부해야 합니다. 또한 메시지 본문에서 내용 코딩을 제거할 수 있습니다.

4.3 Request Method

REQUEST_METHOD 메타 변수에 제공된 Request Method는 응답을 생성할 때 스크립트가 적용할 처리 방법을 식별합니다. 스크립트 작성자는 특정 응용프로그램에 가장 적합한 방법을 구현할 수 있습니다. 스크립트가 메서드가 지원되지 않는 요청을 수신하는 경우 오류와 함께 요청을 거부해야 합니다(섹션 6.3.3 참조).

4.3.1 GET

GET 메서드는 스크립트가 메타 변수 값을 기반으로 문서를 생성해야 함을 나타냅니다. 관례에 따라 GET 방법은 '안전'하고 '동등성'이며 문서 생성 이외의 조치를 취해서는 안 된다.

GET 방법의 의미는 프로토콜별 메타 변수에 의해 수정 및 정제될 수 있다.

4.3.2 POST

POST 메서드는 스크립트를 요청하여 처리를 수행하고 요청 메시지 본문의 데이터를 기반으로 문서를 생성하는 데 사용됩니다. 일반적인 용도는 HTML [18]의 양식 제출이며, 데이터베이스의 변경과 같은 영구적인 영향을 미치는 스크립트에 의한 처리를 시작하려는 의도이다.

스크립트는 첨부된 메시지 본문을 읽기 전에 content_LENGTH 변수 값을 확인하고 content_TYPE 값을 확인한 후 처리해야 합니다.

4.3.3 HEAD

4.3.4 Protocol-Specific Methods

스크립트는 HTTP/1.1 PUT 및 Delete와 같은 프로토콜별 메서드를 구현할 수 있습니다.

서버는 일부 메서드가 스크립트에 적합하지 않거나 허용되지 않는다고 판단하여 메서드 자체를 처리하거나 오류를 클라이언트에 반환할 수 있습니다.

The server MAY decide that some methods are not appropriate or permitted for a script, and may handle the methods itself or return an error to the client.

4.4 The Script Command Line

일부 시스템은 CGI 스크립트에 문자열 배열을 제공하는 방법을 지원합니다.

이것은 인코딩되지 않은 "=" 문자를 포함하지 않는 URI 쿼리 문자열과 함께 'GET' 또는 'HEAD' 요청으로 식별되는 인덱싱된 HTTP 쿼리의 경우에만 사용됩니다.

이러한 요청의 경우 서버는 쿼리 문자열을 검색 문자열로 처리하고 이래의 규칙을 사용하여 단어로 구문 분석해야 합니다.

파싱 후 각 검색어는 URL로 디코딩되고 선택적으로 시스템 정의 방식으로 인코딩된 다음 명령행 인수 목록에 추가됩니다.

서버가 인수 목록의 일부를 작성할 수 없는 경우, 서버는 command line info를 생성하지 않아야 합니다. 예를 들어, 인수의 수가 운영 체제 또는 서버 제한보다 크거나 단어 중 하나가 인수로 표현되지 않을 수 있습니다.

스크립트는 쿼리_STRING 값에 인코딩되지 않은 "=" 문자가 포함되어 있는지 확인해야 하며 인코딩되지 않은 경우 명령줄 인수를 사용하면 안 됩니다.

5. NPH Scripts ← 이부분은 안해도 될것같…?

5.1 정의

서버는 NPH(Non-Parsed Header) 스크립트를 지원할 수 있습니다. 이 스크립트는 서버가 응답 처리에 대한 모든 책임을 떠넘기는 스크립트입니다.

이 규격은 출력 데이터만을 기준으로 NPH 스크립트를 식별할 수 있는 메커니즘을 제공하지 않는다. 따라서 관례상 어떤 스크립트도 오직 한 가지 유형(NPH 또는 CGI)의 출력만 제공할 수 있으므로 스크립트 자체는 'NPH 스크립트'로 설명된다. NPH를 지원하는 서버는 스크립트 이름이나 위치에 따라 NPH 스크립트를 식별하기 위한 구현 정의 메커니즘을 제공해야 합니다.

5.2 NPH Response

스크립트에는 서버 또는 클라이언트로 데이터를 다시 보내는 시스템 정의 방법이 있어야 하며, 스크립트는 항상 일부 데이터를 반환해야 합니다. 달리 정의되지 않는 한 이는 기존의 CGI 스크립트와 동일합니다.

현재 NPH 스크립트는 HTTP 클라이언트 요청에 대해서만 정의됩니다. (HTTP) NPH 스크립트는 HTTP 사양 [1], [4]의 섹션 6에 설명된 전체 HTTP 응답 메시지를 반환해야 합니다. 스크립트는 SERVER_PROTOCOL 변수를 사용하여 응답의 적절한 형식을 결정해야 합니다. 또한 특정 프로토콜 명세서에 의해 요구될 수 있는 일반적인 또는 프로토콜 고유의 메타 변수를 반드시 고려해야 한다.

서버는 스크립트 출력이 수정되지 않은 상태로 클라이언트에 전송되도록 해야 합니다. 이 경우 스크립트가 헤더 필드에 올바른 문자 집합(HTTP의 경우 US-ASCII [9] 및 ISO 8859-1 [10])을 사용해야 합니다. 서버는 최소한의 내부 버퍼링과 전송 가시적 버퍼링 없이 스크립트 출력이 클라이언트로 직접 전송되도록 시도해야 합니다.

구현에서 달리 정의되지 않는 한 스크립트는 클라이언트가 동일한 연결을 통해 추가 요청을 보낼 수 있음을 응답에 나타내지 않아야 합니다.

6. CGI Response

6.1 Response Handling

스크립트는 항상 비어 있지 않은 응답을 제공해야 하므로 이 데이터를 서버로 다시 보내는 시스템 정의 방법이 있습니다. 달리 정의되지 않는 한, 이는 '표준 출력' 파일 디스크립터를 통해 이루어집니다.

스크립트는 요청을 처리하고 해당 응답을 준비할 때 REQUEST_Method 변수를 확인해야 합니다.

서버는 스크립트로부터 데이터를 수신해야 하는 timeout 기간을 구현할 수 있다. 서버 구현이 timeout를 정의하고 timeout 기간 내에 스크립트로부터 데이터를 수신하지 않는 경우, 서버는 스크립트 프로세스를 종료할 수 있습니다.

6.2 Response Type

응답은 메시지 헤더와 메시지 본문으로 구성되며, 빈 줄로 구분됩니다. 메시지 머리글에 하나 이상의 머리글 필드가 있습니다. 본문이 NULL일 수 있습니다.

스크립트는 문서 응답, 로컬 리디렉션 응답 또는 클라이언트 리디렉션(선택사항 문서 포함) 응답 중 하나를 반환해야 합니다. 아래의 응답 정의에서 응답의 헤더 필드 순서는 중요하지 않다(BNF에서 나타나지만). 헤더 필드는 섹션 6.3에 정의되어 있습니다.

6.2.1 Document Response

CGI 스크립트는 응답의 성공 상태를 나타내는 선택적 오류 코드와 함께 문서 응답으로 사용자에게 문서를 반환할 수 있습니다.

스크립트는 Content-Type 헤더 필드를 반환해야 합니다. 상태 헤더 필드는 선택 사항이며, 생략된 경우 status 200 'OK'으로 간주됩니다. 서버는 클라이언트에 대한 응답이 응답 프로토콜 버전을 준수하는지 확인하기 위해 스크립트의 출력을 적절하게 수정해야 합니다.

6.2.2 Local Redirect Response

CGI 스크립트는 위치 헤더 필드의 로컬 리소스에 대한 URI 경로 및 쿼리 문자열('local-pathquery')을 반환할 수 있습니다. 지정된 경로를 사용하여 요청을 재처리해야 함을 서버에 알립니다.

local-redir-response = local-Location NL

스크립트는 다른 헤더 필드나 메시지 본문을 반환해서는 안 되며, 서버는 URL이 포함된 요청에 대한 응답으로 생성한 응답을 생성해야 합니다.

scheme "://" server-name ":" server-port local-pathquery

6.2.3 Client Redirect Response

CGI 스크립트는 Location 헤더 필드에 절대 URI 경로를 반환하여 지정된 URI를 사용하여 요청을 재처리해야 함을 클라이언트에 알릴 수 있습니다.

client-redir-response = client-Location *extension-field NL

스크립트는 서버 정의 CGI 확장 필드를 제외하고 다른 헤더 필드를 제공해서는 안 됩니다. HTTP 클라이언트 요청의 경우, 서버는 302 'Found' HTTP 응답 메시지를 생성해야 합니다.

6.2.4 Client Redirect Response with Document

CGI 스크립트는 첨부된 문서와 함께 위치 헤더 필드에 절대 URI 경로를 반환하여 지정된 URI를 사용하여 요청을 재처리해야 함을 클라이언트에 알릴 수 있습니다.

상태 헤더 필드는 반드시 제공되어야 하며 상태 값 302 'Found'를 포함해야 합니다. 그렇지 않으면 확장 코드, 즉 클라이언트 리디렉션을 의미하는 다른 유효한 상태 코드를 포함할 수 있습니다. 서버는 클라이언트에 대한 응답이 응답 프로토콜 버전을 준수하는지 확인하기 위해 스크립트의 출력을 적절하게 수정해야 합니다.

6.3 Response Header Fields

응답 헤더 필드는 서버가 해석할 CGI 또는 확장 헤더 필드이거나 클라이언트에 반환되는 응답에 포함될 프로토콜별 헤더 필드입니다. 하나 이상의 CGI 필드를 제공해야 합니다. 각 CGI 필드는 응답에 두 번 이상 나타나지 않아야 합니다. 응답 헤더 필드에는 다음과 같은 구문이 있습니다.

필드 이름은 대소문자를 구분하지 않습니다. NULL 필드 값은 전송되지 않는 필드와 동일합니다. CGI-Response의 각 헤더 필드는 한 줄에 지정해야 합니다. CGI/1.1은 연속 라인을 지원하지 않습니다. 공백은 ":"와 필드 값 사이(필드 이름과 ":" 사이는 아님)와 필드 값의 토큰 사이에서도 허용됩니다.

6.3.1 Content-Type

내용 유형 응답 필드는 엔티티 본문의 인터넷 미디어 유형 [6]을 설정합니다.

엔티티 본문이 반환되는 경우 스크립트는 응답에 내용 유형 필드를 제공해야 합니다. 그렇지 않은 경우, 서버는 올바른 내용 유형을 결정하려고 시도하지 않아야 합니다. 값은 charset 매개 변수가 변경된 경우를 제외하고 수정되지 않은 상태로 클라이언트에 전송되어야 합니다.

다른 방식으로 정의되지 않는 한 클라이언트가 텍스트 미디어 유형에 대해 가정한 기본 문자 집합은 프로토콜이 HTTP이고 다른 방식으로 US-ASCII인 경우 ISO-8859-1입니다. 따라서 스크립트에는 문자 집합 매개 변수가 포함되어야 합니다. 이 문제에 대한 설명은 HTTP/1.1 규격[4]의 섹션 3.4.1을 참조하십시오.

6.3.2 Location

Location 헤더 필드는 스크립트가 실제 문서가 아닌 문서에 대한 참조(reference)를 반환하도록 서버에 지정하는 데 사용됩니다(섹션 6.2.3 및 6.2.4 참조). 클라이언트가 참조된 문서를 가져오는 것을 나타내는 절대 URI(선택적으로 조각 식별자가 있는 URI) 또는 서버가 참조된 문서를 가져와 클라이언트에 응답으로 반환하는 것을 나타내는 로컬 URI 경로(선택적으로 쿼리 문자열이 있는 URI)이다.

절대어의 구문URI는 RFC 2396[2] 및 RFC 2732[7]에 지정된 문서에서 이 문서에 통합됩니다. 유효한 절대값URI는 항상 구성표 이름 뒤에 ":"로 시작하고 구성표 이름은 영숫자 "+", "-" 또는 ""로 계속됩니다. 로컬 URI 경로 및 쿼리는 상대 경로 또는 NULL이 아닌 절대 경로여야 하므로 "/"로 시작해야 합니다.

요청에 첨부된 메시지 본문(예: POST 요청)은 리디렉션 대상인 리소스에서 사용할 수 없습니다.

6.3.3 Status

Status 헤더 필드에는 요청을 처리하는 스크립트의 성공 수준을 나타내는 3자리 정수 결과 코드가 포함되어 있습니다.

상태 코드 200 'OK'은 성공을 나타내며, 문서 응답에 대해 가정된 기본값입니다. 상태 코드 302 'Found'는 위치 헤더 필드 및 응답 메시지 본문과 함께 사용됩니다. CONTENT_TYPE 누락과 같은 알 수 없는 요청 형식에 상태 코드 400 'Bad Request'를 사용할 수 있습니다. 지원되지 않는 REQUEST_Method를 수신하는 경우 스크립트에서 상태 코드 501 'Not Implemented'를 반환할 수 있습니다.

다른 유효한 상태 코드는 HTTP 사양 [1], [4]의 섹션 6.1.1에 나열되어 있으며, IANA HTTP 상태 코드 레지스트리 [8] 및 MAY를 위에 나열된 코드와 함께 사용하거나 대신 사용할 수 있습니다. 스크립트는 HTTP/1.1 상태 코드를 사용하기 전에 SERVER_Protocol의 값을 확인해야 합니다. 스크립트가 지원하지 않는 방법을 사용하여 만든 오류 405 'Method Not Allowed' HTTP/1.1 요청을 거부할 수 있습니다.

오류 상태 코드를 반환하는 것은 스크립트 자체의 오류 상태를 의미할 필요는 없습니다. 예를 들어 서버에 의해 오류 처리기로 호출되는 스크립트는 서버의 오류 조건에 적합한 코드를 반환해야 합니다.

reason-phrase은 인간이 사용하기 위해 클라이언트에 반환되는 오류에 대한 텍스트 설명입니다.

6.3.4 Protocol-Specific Header Fields

이 스크립트는 SERVER_PROTOCOL(HTTP/1.0 [1] 또는 HTTP/1.1 [4]) 사양에서 정의된 응답 메시지와 관련된 다른 헤더 필드를 반환할 수 있습니다. 서버는 CGI 헤더 구문의 헤더 데이터를 HTTP 헤더 구문으로 변환해야 합니다. 예를 들어, CGI 스크립트에 사용되는 줄 바꿈의 문자 순서(유닉스의 US-ASCII LF 등)는 HTTP(US-ASCII CR 뒤에 LF)에서 사용되는 문자 순서와 다를 수 있습니다.이 스크립트는 클라이언트 측 통신 문제와 관련된 헤더 필드를 반환하지 않아야 하며 클라이언트에 응답을 보내는 서버의 기능에 영향을 줄 수 있습니다. 서버는 클라이언트가 반환한 헤더 필드를 제거할 수 있다. 스크립트에서 반환된 헤더 필드와 그렇지 않으면 자체 전송될 헤더 필드 간의 충돌을 해결해야 합니다.

6.3.5 Extension Header Fields

추가 구현 정의 CGI 헤더 필드가 있을 수 있으며 필드 이름은 "X-CGI-"로 시작해야 합니다. 서버는 스크립트로부터 수신된 "X-CGI-"로 시작하는 이름을 가진 인식되지 않는 헤더 필드를 무시하거나 삭제할 수 있습니다.

6.4 Response Message-Body

응답 메시지 본문은 서버가 클라이언트에 반환할 첨부 document입니다. 서버는 스크립트가 파일 종료 조건을 통해 메시지 본문의 끝을 알릴 때까지 스크립트가 제공하는 모든 데이터를 읽어야 합니다. 메시지 본문은 HEAD 요청이나 필요한 전송 코딩, 콘텐츠 코딩 또는 문자 집합 변환을 제외하고 수정 없이 클라이언트로 전송되어야 합니다.

7. 시스템 사양

8. 구현

9. 보안 고려사항

9.6 데이터 길이 및 버퍼링 고려 사항

이 규격은 스크립트에 표시되는 메시지 본문의 길이에 제한을 두지 않습니다. 스크립트는 모든 크기의 정적으로 할당된 버퍼가 한 번에 전체 제출을 포함하기에 충분하다고 가정해서는 안 됩니다. 신중한 오버플로 검사 없이 고정 길이 버퍼를 사용하면 공격자가 운영 체제의 '스택 스매싱' 또는 '스택 오버플로' 취약성을 이용할 수 있습니다. 이 스크립트는 디스크 또는 기타 버퍼링 미디어에 대량 제출을 스풀할 수 있지만 대량 제출이 빠르게 연속되면 서비스 거부 상태가 발생할 수 있습니다. 메시지 본문의 CONTENT_LENGTH가 리소스 고려사항보다 클 경우 스크립트는 프로토콜 버전에 적합한 오류 상태로 응답해야 합니다. 잠재적으로 적용 가능한 상태 코드에는 503 'Service Unavailable'(HTTP/1.0 및 HTTP/1.1), 413 'Request Entity Too Large'(HTTP/1.1) 및 414 'Request-URI Too Large'(HTTP/1.1)가 포함됩니다.

스크립트에서 CGI 응답을 처리하는 서버에도 비슷한 고려 사항이 적용됩니다. 스크립트에 의해 반환되는 헤더 또는 메시지 본문의 길이에 제한이 없으며, 서버는 모든 크기의 정적으로 할당된 버퍼가 전체 응답을 포함하기에 충분하다고 가정해서는 안 됩니다.