RFC3875 日本語訳
3875 The Common Gateway Interface (CGI) Version 1.1. D. Robinson, K.Coar. October 2004. (Format: TXT=80728, PDF=121026 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Robinson
Request for Comments: 3875 K. Coar
Category: Informational The Apache Software Foundation
October 2004
コメントを求めるワーキンググループD.ロビンソンの要求をネットワークでつないでください: 3875年のK.Coarカテゴリ: アパッチソフトウェア財団2004年10月に、情報です。
The Common Gateway Interface (CGI) Version 1.1
共通ゲートウェイインターフェイス(CGI)バージョン1.1
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(C)インターネット協会(2004)。
IESG Note
IESG注意
This document is not a candidate for any level of Internet Standard. The IETF disclaims any knowledge of the fitness of this document for any purpose, and in particular notes that it has not had IETF review for such things as security, congestion control or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment.
このドキュメントはインターネットStandardのどんなレベルの候補ではありません。 IETFはそれには配備されたプロトコルとのセキュリティのようなもの、輻輳制御または不適当な相互作用のためのIETFレビューがないというどんな目的、および特定の注意のこのドキュメントのフィットネスに関するどんな知識も放棄します。 RFC Editorは、自己判断でこのドキュメントを発表するのを選びました。 このドキュメントの読者は実現と展開のために値を評価する際に警戒するべきです。
Abstract
要約
The Common Gateway Interface (CGI) is a simple interface for running external programs, software or gateways under an information server in a platform-independent manner. Currently, the supported information servers are HTTP servers.
共通ゲートウェイインターフェイス(CGI)は、情報サーバの下でプラットホームから独立している方法で外部プログラム、ソフトウェアまたはゲートウェイを動かすための簡単なインタフェースです。 現在、支持された情報サーバはHTTPサーバです。
The interface has been in use by the World-Wide Web (WWW) since 1993. This specification defines the 'current practice' parameters of the 'CGI/1.1' interface developed and documented at the U.S. National Centre for Supercomputing Applications. This document also defines the use of the CGI/1.1 interface on UNIX(R) and other, similar systems.
1993年以来インタフェースはWWW(WWW)で使用中です。 この仕様はSupercomputing Applicationsのために米国National Centreに開発されて、記録された'CGI/1.1'インタフェースの'現在の習慣'パラメタを定義します。 また、このドキュメントはUNIX(R)、および他の、そして、同様のシステムにおけるCGI/1.1インタフェースの使用を定義します。
Robinson & Coar Informational [Page 1] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[1ページ]情報のRFC3875CGIバージョン2004年10月1.1日
Table of Contents
目次
1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Requirements . . . . . . . . . . . . . . . . . . . . . . 4
1.3. Specifications . . . . . . . . . . . . . . . . . . . . . 4
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 5
1. 序論。 . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. 目的. . . . . . . . . . . . . . . . . . . . . . . . 4 1.2。 要件. . . . . . . . . . . . . . . . . . . . . . 4 1.3。 仕様. . . . . . . . . . . . . . . . . . . . . 4 1.4。 用語. . . . . . . . . . . . . . . . . . . . . . 5
2. Notational Conventions and Generic Grammar. . . . . . . . . . 5
2.1. Augmented BNF . . . . . . . . . . . . . . . . . . . . . 5
2.2. Basic Rules . . . . . . . . . . . . . . . . . . . . . . 6
2.3. URL Encoding . . . . . . . . . . . . . . . . . . . . . . 7
2. 記号法のコンベンションと一般的な文法… 5 2.1。 BNF. . . . . . . . . . . . . . . . . . . . . 5 2.2を増大させました。 基本的なルール. . . . . . . . . . . . . . . . . . . . . . 6 2.3。 URLコード化. . . . . . . . . . . . . . . . . . . . . . 7
3. Invoking the Script . . . . . . . . . . . . . . . . . . . . . 8
3.1. Server Responsibilities . . . . . . . . . . . . . . . . 8
3.2. Script Selection . . . . . . . . . . . . . . . . . . . . 9
3.3. The Script-URI . . . . . . . . . . . . . . . . . . . . . 9
3.4. Execution . . . . . . . . . . . . . . . . . . . . . . . 10
3. スクリプト. . . . . . . . . . . . . . . . . . . . . 8 3.1を呼び出します。 サーバ責任. . . . . . . . . . . . . . . . 8 3.2。 スクリプト選択. . . . . . . . . . . . . . . . . . . . 9 3.3。 スクリプトURI.93.4。 実行. . . . . . . . . . . . . . . . . . . . . . . 10
4. The CGI Request . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. Request Meta-Variables . . . . . . . . . . . . . . . . . 10
4.1.1. AUTH_TYPE. . . . . . . . . . . . . . . . . . . . 11
4.1.2. CONTENT_LENGTH . . . . . . . . . . . . . . . . . 12
4.1.3. CONTENT_TYPE . . . . . . . . . . . . . . . . . . 12
4.1.4. GATEWAY_INTERFACE. . . . . . . . . . . . . . . . 13
4.1.5. PATH_INFO. . . . . . . . . . . . . . . . . . . . 13
4.1.6. PATH_TRANSLATED. . . . . . . . . . . . . . . . . 14
4.1.7. QUERY_STRING . . . . . . . . . . . . . . . . . . 15
4.1.8. REMOTE_ADDR. . . . . . . . . . . . . . . . . . . 15
4.1.9. REMOTE_HOST. . . . . . . . . . . . . . . . . . . 16
4.1.10. REMOTE_IDENT . . . . . . . . . . . . . . . . . . 16
4.1.11. REMOTE_USER. . . . . . . . . . . . . . . . . . . 16
4.1.12. REQUEST_METHOD . . . . . . . . . . . . . . . . . 17
4.1.13. SCRIPT_NAME. . . . . . . . . . . . . . . . . . . 17
4.1.14. SERVER_NAME. . . . . . . . . . . . . . . . . . . 17
4.1.15. SERVER_PORT. . . . . . . . . . . . . . . . . . . 18
4.1.16. SERVER_PROTOCOL. . . . . . . . . . . . . . . . . 18
4.1.17. SERVER_SOFTWARE. . . . . . . . . . . . . . . . . 19
4.1.18. Protocol-Specific Meta-Variables . . . . . . . . 19
4.2. Request Message-Body . . . . . . . . . . . . . . . . . . 20
4.3. Request Methods . . . . . . . . . . . . . . . . . . . . 20
4.3.1. GET. . . . . . . . . . . . . . . . . . . . . . . 20
4.3.2. POST . . . . . . . . . . . . . . . . . . . . . . 21
4.3.3. HEAD . . . . . . . . . . . . . . . . . . . . . . 21
4.3.4. Protocol-Specific Methods. . . . . . . . . . . . 21
4.4. The Script Command Line. . . . . . . . . . . . . . . . . 21
4. CGI要求. . . . . . . . . . . . . . . . . . . . . . . 10 4.1。 要求メタ変数. . . . . . . . . . . . . . . . . 10 4.1.1。 AUTH_タイプ。 . . . . . . . . . . . . . . . . . . . 11 4.1.2. 内容_長さ. . . . . . . . . . . . . . . . . 12 4.1の.3。 内容_タイプ. . . . . . . . . . . . . . . . . . 12 4.1.4。 ゲートウェイ_は連結します。 . . . . . . . . . . . . . . . 13 4.1.5. 経路_インフォメーション。 . . . . . . . . . . . . . . . . . . . 13 4.1.6. 経路_は翻訳しました。 . . . . . . . . . . . . . . . . 14 4.1.7. _ストリング. . . . . . . . . . . . . . . . . . 15 4.1.8について質問してください。 リモート_ADDR… 15 4.1 .9。 リモート_ホスト………………16 4.1 .10。 リモート_IDENT. . . . . . . . . . . . . . . . . . 16 4.1.11。 リモート_ユーザ。 . . . . . . . . . . . . . . . . . . 16 4.1.12. _方法. . . . . . . . . . . . . . . . . 17 4.1.13を要求してください。 スクリプト_名前。 . . . . . . . . . . . . . . . . . . 17 4.1.14. サーバ_名前。 . . . . . . . . . . . . . . . . . . 17 4.1.15. サーバ_ポート。 . . . . . . . . . . . . . . . . . . 18 4.1.16. サーバ_は議定書を作ります。 . . . . . . . . . . . . . . . . 18 4.1.17. サーバ_ソフトウェア。 . . . . . . . . . . . . . . . . 19 4.1.18. プロトコル特有のメタ変数.194.2。 メッセージ本体.204.3を要求してください。 方法. . . . . . . . . . . . . . . . . . . . 20 4.3.1を要求してください。 得ます。 . . . . . . . . . . . . . . . . . . . . . . 20 4.3.2. ポスト. . . . . . . . . . . . . . . . . . . . . . 21 4.3.3。 ヘッド. . . . . . . . . . . . . . . . . . . . . . 21 4.3.4。 プロトコル特有の方法。 . . . . . . . . . . . 21 4.4. スクリプトコマンドライン。 . . . . . . . . . . . . . . . . 21
Robinson & Coar Informational [Page 2] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[2ページ]情報のRFC3875CGIバージョン2004年10月1.1日
5. NPH Scripts . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Identification . . . . . . . . . . . . . . . . . . . . . 22
5.2. NPH Response . . . . . . . . . . . . . . . . . . . . . . 22
5. NPHは.225.1に原稿を書きます。 識別. . . . . . . . . . . . . . . . . . . . . 22 5.2。 NPH応答. . . . . . . . . . . . . . . . . . . . . . 22
6. CGI Response. . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Response Handling. . . . . . . . . . . . . . . . . . . . 23
6.2. Response Types . . . . . . . . . . . . . . . . . . . . . 23
6.2.1. Document Response. . . . . . . . . . . . . . . . 23
6.2.2. Local Redirect Response. . . . . . . . . . . . . 24
6.2.3. Client Redirect Response . . . . . . . . . . . . 24
6.2.4. Client Redirect Response with Document . . . . . 24
6.3. Response Header Fields . . . . . . . . . . . . . . . . . 25
6.3.1. Content-Type . . . . . . . . . . . . . . . . . . 25
6.3.2. Location . . . . . . . . . . . . . . . . . . . . 26
6.3.3. Status . . . . . . . . . . . . . . . . . . . . . 26
6.3.4. Protocol-Specific Header Fields. . . . . . . . . 27
6.3.5. Extension Header Fields. . . . . . . . . . . . . 27
6.4. Response Message-Body. . . . . . . . . . . . . . . . . . 28
6. CGI応答。 . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. 応答取り扱い。 . . . . . . . . . . . . . . . . . . . 23 6.2. 応答は.1に.236.2をタイプします。 応答を記録してください。 . . . . . . . . . . . . . . . 23 6.2.2. 地方の再直接の応答。 . . . . . . . . . . . . 24 6.2.3. クライアントの再直接の応答. . . . . . . . . . . . 24 6.2.4。 ドキュメント. . . . . 24 6.3とのクライアントの再直接の応答。 応答ヘッダーフィールド. . . . . . . . . . . . . . . . . 25 6.3.1。 コンテントタイプ. . . . . . . . . . . . . . . . . . 25 6.3.2。 位置. . . . . . . . . . . . . . . . . . . . 26 6.3の.3。 状態. . . . . . . . . . . . . . . . . . . . . 26 6.3.4。 プロトコル特有のヘッダーフィールド。 . . . . . . . . 27 6.3.5. 拡張ヘッダー分野。 . . . . . . . . . . . . 27 6.4. 応答メッセージ本体。 . . . . . . . . . . . . . . . . . 28
7. System Specifications . . . . . . . . . . . . . . . . . . . . 28
7.1. AmigaDOS . . . . . . . . . . . . . . . . . . . . . . . . 28
7.2. UNIX . . . . . . . . . . . . . . . . . . . . . . . . . . 28
7.3. EBCDIC/POSIX . . . . . . . . . . . . . . . . . . . . . . 29
7. システム仕様. . . . . . . . . . . . . . . . . . . . 28 7.1。 AmigaDOS. . . . . . . . . . . . . . . . . . . . . . . . 28 7.2。 UNIX. . . . . . . . . . . . . . . . . . . . . . . . . . 28 7.3。 EBCDIC/POSIX. . . . . . . . . . . . . . . . . . . . . . 29
8. Implementation. . . . . . . . . . . . . . . . . . . . . . . . 29
8.1. Recommendations for Servers. . . . . . . . . . . . . . . 29
8.2. Recommendations for Scripts. . . . . . . . . . . . . . . 30
8. 実現。 . . . . . . . . . . . . . . . . . . . . . . . 29 8.1. サーバのための推薦。 . . . . . . . . . . . . . . 29 8.2. スクリプトのための推薦。 . . . . . . . . . . . . . . 30
9. Security Considerations . . . . . . . . . . . . . . . . . . . 30
9.1. Safe Methods . . . . . . . . . . . . . . . . . . . . . . 30
9.2. Header Fields Containing Sensitive Information . . . . . 31
9.3. Data Privacy . . . . . . . . . . . . . . . . . . . . . . 31
9.4. Information Security Model . . . . . . . . . . . . . . . 31
9.5. Script Interference with the Server. . . . . . . . . . . 31
9.6. Data Length and Buffering Considerations . . . . . . . . 32
9.7. Stateless Processing . . . . . . . . . . . . . . . . . . 32
9.8. Relative Paths . . . . . . . . . . . . . . . . . . . . . 33
9.9. Non-parsed Header Output . . . . . . . . . . . . . . . . 33
9. セキュリティ問題. . . . . . . . . . . . . . . . . . . 30 9.1。 確実な方法. . . . . . . . . . . . . . . . . . . . . . 30 9.2。 機密情報. . . . . 31 9.3を含むヘッダーフィールド。 データプライバシー. . . . . . . . . . . . . . . . . . . . . . 31 9.4。 情報セキュリティは.319.5をモデル化します。 サーバのスクリプト干渉… 31 9.6。 データの長さと問題. . . . . . . . 32 9.7をバッファリングすること。 国がない処理. . . . . . . . . . . . . . . . . . 32 9.8。 相対パス. . . . . . . . . . . . . . . . . . . . . 33 9.9。 非分析されたヘッダー出力. . . . . . . . . . . . . . . . 33
10. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 33
10. 承認。 . . . . . . . . . . . . . . . . . . . . . . 33
11. References. . . . . . . . . . . . . . . . . . . . . . . . . . 33
11.1. Normative References. . . . . . . . . . . . . . . . . . 33
11.2. Informative References. . . . . . . . . . . . . . . . . 34
11. 参照。 . . . . . . . . . . . . . . . . . . . . . . . . . 33 11.1. 引用規格。 . . . . . . . . . . . . . . . . . 33 11.2. 有益な参照。 . . . . . . . . . . . . . . . . 34
12. Authors' Addresses. . . . . . . . . . . . . . . . . . . . . . 35
12. 作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . 35
13. Full Copyright Statement. . . . . . . . . . . . . . . . . . . 36
13. 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . 36
Robinson & Coar Informational [Page 3] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[3ページ]情報のRFC3875CGIバージョン2004年10月1.1日
1. Introduction
1. 序論
1.1. Purpose
1.1. 目的
The Common Gateway Interface (CGI) [22] allows an HTTP [1], [4] server and a CGI script to share responsibility for responding to client requests. The client request comprises a Uniform Resource Identifier (URI) [11], a request method and various ancillary information about the request provided by the transport protocol.
共通ゲートウェイインターフェイス(CGI)[22]で、HTTP[1]、[4]サーバ、およびCGIスクリプトはクライアント要求に応じることへの責任を共有できます。 クライアント要求はUniform Resource Identifier(URI)[11]を包括します、と要求に関する要求方法と様々な補助的情報はトランスポート・プロトコルで前提としました。
The CGI defines the abstract parameters, known as meta-variables, which describe a client's request. Together with a concrete programmer interface this specifies a platform-independent interface between the script and the HTTP server.
CGIはクライアントの要求について説明するメタ変数として知られている抽象的なパラメタを定義します。 具体的なプログラマインタフェースと共に、これはスクリプトとHTTPサーバとのプラットホームインディペンデント・インタフェースを指定します。
The server is responsible for managing connection, data transfer, transport and network issues related to the client request, whereas the CGI script handles the application issues, such as data access and document processing.
サーバはクライアント要求に関連する接続、データ転送、輸送、およびネットワーク問題を管理するのに原因となりますが、CGIスクリプトはアプリケーション問題を扱います、データ・アクセスや文書処理のように。
1.2. Requirements
1.2. 要件
The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 'MAY' and 'OPTIONAL' in this document are to be interpreted as described in BCP 14, RFC 2119 [3].
'キーワード'MUST'、BCP14(RFC2119[3])で説明されるように本書ではNOTと、'''REQUIRED'、'SHALL'、'SHALL NOT'、'SHOULD'、'SHOULD NOT'、'RECOMMENDED'、'5月'、およびOPTIONAL'を解釈することになっていなければなりません。
An implementation is not compliant if it fails to satisfy one or more of the 'must' requirements for the protocols it implements. An implementation that satisfies all of the 'must' and all of the 'should' requirements for its features is said to be 'unconditionally compliant'; one that satisfies all of the 'must' requirements but not all of the 'should' requirements for its features is said to be 'conditionally compliant'.
それが実行するプロトコルのための'must'要件の1つ以上を満たさないなら、実現は対応しません。 'must'のすべてと特徴のための'should'要件のすべてを満たす実現は'無条件に言いなりになる'と言われています。 特徴のための'should'要件のすべてではなく、'must'要件のすべてを満たすものは'条件付きに言いなりになる'と言われています。
1.3. Specifications
1.3. 仕様
Not all of the functions and features of the CGI are defined in the main part of this specification. The following phrases are used to describe the features that are not specified:
機能のすべてとCGIのどんな特徴もこの仕様の主部で定義されません。 以下の句は指定されない特徴について説明するのに使用されます:
'system-defined'
The feature may differ between systems, but must be the same for
different implementations using the same system. A system will
usually identify a class of operating systems. Some systems are
defined in section 7 of this document. New systems may be defined
by new specifications without revision of this document.
同じシステムを使用するのにおいて異なった実現に同じでなければならないのを除いて、特徴がそうする'システムで定義されること'はシステムの間で異なります。 通常、システムはオペレーティングシステムのクラスを特定するでしょう。いくつかのシステムがこのドキュメントのセクション7で定義されます。 新しいシステムはこのドキュメントの改正なしで新しい仕様で定義されるかもしれません。
Robinson & Coar Informational [Page 4] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[4ページ]情報のRFC3875CGIバージョン2004年10月1.1日
'implementation-defined'
The behaviour of the feature may vary from implementation to
implementation; a particular implementation must document its
behaviour.
'実現で定義される'実現によって特徴のふるまいが変えるかもしれない。 特定の実現はふるまいを記録しなければなりません。
1.4. Terminology
1.4. 用語
This specification uses many terms defined in the HTTP/1.1 specification [4]; however, the following terms are used here in a sense which may not accord with their definitions in that document, or with their common meaning.
この仕様はHTTP/1.1仕様[4]に基づき定義された多くの用語を使用します。 しかしながら、そのドキュメント、またはそれらの一般的な意味がある彼らの定義と一致しないかもしれない次の用語がある意味でここで使用されます。
'meta-variable'
A named parameter which carries information from the server to the
script. It is not necessarily a variable in the operating
system's environment, although that is the most common
implementation.
'メタ可変な'Aはサーバからスクリプトまで情報を運ぶパラメタを命名しました。 それは最も一般的な実現ですが、それは必ずオペレーティングシステムの環境で変数であるというわけではありません。
'script'
The software that is invoked by the server according to this
interface. It need not be a standalone program, but could be a
dynamically-loaded or shared library, or even a subroutine in the
server. It might be a set of statements interpreted at run-time,
as the term 'script' is frequently understood, but that is not a
requirement and within the context of this specification the term
has the broader definition stated.
''このインタフェースに従ってサーバによって呼び出されるソフトウェアに原稿を書いてください。 それは、スタンドアロンプログラムである必要はありませんが、サーバのダイナミックに満載の、または、共有ライブラリの、または、同等のaサブルーチンであるかもしれません。'スクリプト'という用語が頻繁に理解されていますが、それが要件でなく、用語がこの仕様の文脈の中に述べられたより広い定義を持っているのでランタイムのときに解釈された1セットの声明であるかもしれません。
'server'
The application program that invokes the script in order to
service requests from the client.
'サーバ、'クライアントからの要求を修理するためにスクリプトを呼び出すアプリケーション・プログラム。
2. Notational Conventions and Generic Grammar
2. 記号法のコンベンションと一般的な文法
2.1. Augmented BNF
2.1. 増大しているBNF
All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) similar to that used by RFC 822 [13]. Unless stated otherwise, the elements are case-sensitive. This augmented BNF contains the following constructs:
本書では指定されたメカニズムのすべてが散文とRFC822[13]によって使用されるそれと同様の増大しているバッカス記法(BNF)の両方で説明されます。 別の方法で述べられない場合、要素は大文字と小文字を区別しています。 この増大しているBNFは以下の構造物を含んでいます:
name = definition
The name of a rule and its definition are separated by the equals
character ('='). Whitespace is only significant in that
continuation lines of a definition are indented.
=定義を規則の名前と命名してください。そうすれば、定義は同輩キャラクタ('=')によって切り離されます。 定義の継続行が入り込まれるので、空白は重要であるだけです。
Robinson & Coar Informational [Page 5] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[5ページ]情報のRFC3875CGIバージョン2004年10月1.1日
"literal"
Double quotation marks (") surround literal text, except for a
literal quotation mark, which is surrounded by angle-brackets ('<'
and '>').
「文字通り」のDouble引用符、(「)、文字通りの引用符以外の文字通りのテキストを囲んでください、」。角ブラケット('<'と'>')によって引用符は囲まれます。
rule1 | rule2
Alternative rules are separated by a vertical bar ('|').
rule1| rule2 Alternative規則が縦棒によって切り離される、('|'、)
(rule1 rule2 rule3)
Elements enclosed in parentheses are treated as a single element.
括弧に同封された(rule1 rule2 rule3)要素はただ一つの要素として扱われます。
*rule
A rule preceded by an asterisk ('*') may have zero or more
occurrences. The full form is 'n*m rule' indicating at least n
and at most m occurrences of the rule. n and m are optional
decimal values with default values of 0 and infinity respectively.
*アスタリスク('*')が先行した規則A規則はゼロか、より多くの発生を持っているかもしれません。 '完全形がそうであり、*m規則'表示は、規則の少なくともnと高々m発生です。nとmはそれぞれ0と無限のデフォルト値がある任意のデシマル値です。
[rule]
An element enclosed in square brackets ('[' and ']') is optional,
and is equivalent to '*1 rule'.
'[統治します]要素は正方形で括弧を同封しました。('['']')が任意である、'*1規則'と同等物はそうです。
N rule
A rule preceded by a decimal number represents exactly N
occurrences of the rule. It is equivalent to 'N*N rule'.
10進数が先行したN規則A規則はまさに規則のN発生を表します。 'それは相当していて、*Nは統治します'
2.2. Basic Rules
2.2. 基本的なルール
This specification uses a BNF-like grammar defined in terms of characters. Unlike many specifications which define the bytes allowed by a protocol, here each literal in the grammar corresponds to the character it represents. How these characters are represented in terms of bits and bytes within a system are either system-defined or specified in the particular context. The single exception is the rule 'OCTET', defined below.
この仕様はキャラクタで定義されたBNFのような文法を使用します。 プロトコルによって許容されたバイトを定義する多くの仕様と異なって、それぞれの文字通りのコネ単位で、ここで、文法はそれが代理をするキャラクタに文通されます。 これらのキャラクタがシステムの中でビットとバイトでどう代理をされるかは、特定の文脈でシステムで定義されるか指定されています。 ただ一つの例外は以下で定義された規則'OCTET'です。
The following rules are used throughout this specification to describe basic parsing constructs.
以下の規則は、基本的な構文解析構造物について説明するのにこの仕様中で使用されます。
alpha = lowalpha | hialpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" |
"i" | "j" | "k" | "l" | "m" | "n" | "o" | "p" |
"q" | "r" | "s" | "t" | "u" | "v" | "w" | "x" |
"y" | "z"
hialpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" |
"I" | "J" | "K" | "L" | "M" | "N" | "O" | "P" |
"Q" | "R" | "S" | "T" | "U" | "V" | "W" | "X" |
"Y" | "Z"
アルファ=lowalpha| hialpha lowalphaは“a"と等しいです。| 「b」| 「c」| 「d」| 「e」| 「f」| 「g」| 「h」| 「i」| 「j」| 「k」| 「l」| 「m」| 「n」| 「o」| 「p」| 「q」| 「r」| 「s」| 「t」| 「u」| 「v」| 「w」| 「x」| 「y」| 「z」hialphaは「A」と等しいです。| 「B」| 「C」| 「D」| 「E」| 「F」| 「G」| 「H」| 「私」| 「J」| 「K」| 「L」| 「M」| 「N」| 「○」| 「P」| 「Q」| 「R」| 「S」| 「T」| 「U」| 「V」| 「W」| 「X」| 「Y」| 「Z」
Robinson & Coar Informational [Page 6] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[6ページ]情報のRFC3875CGIバージョン2004年10月1.1日
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
alphanum = alpha | digit
OCTET = <any 8-bit byte>
CHAR = alpha | digit | separator | "!" | "#" | "$" |
"%" | "&" | "'" | "*" | "+" | "-" | "." | "`" |
"^" | "_" | "{" | "|" | "}" | "~" | CTL
CTL = <any control character>
SP = <space character>
HT = <horizontal tab character>
NL = <newline>
LWSP = SP | HT | NL
separator = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" |
"\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" |
"}" | SP | HT
token = 1*<any CHAR except CTLs or separators>
quoted-string = <"> *qdtext <">
qdtext = <any CHAR except <"> and CTLs but including LWSP>
TEXT = <any printable character>
ケタ=「0インチ」| "1" | "2" | "3" | "4" | "5" | "6" | "7" | "8" | 「9インチのalphanumはアルファと等しいです」| ケタOCTET=<はあらゆる8ビットのバイト>CHAR=アルファです。| ケタ| 分離符| "!" | "#" | "$" | "%" | "&" | "'" | "*" | "+" | "-" | "." | "`" | "^" | "_" | "{" | "|" | "}" | "~" | CTL CTL=<はどんな制御文字>SP=<間隔文字<>HT=水平タブ<ニューライン>LWSPキャラクタ>NL==SPです。| HT| NL分離符=、「(「|」、)、」| "<"| ">"| "@" | "," | ";" | ":" | "\" | <">"| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP| HT象徴=1*<、CTLs以外のどんなCHARか分離符>引用文字列=<、も「>*qdtext<、「>qdtextがどんなCHARも除く<と等しい、<、「>、CTLsにもかかわらず、LWSP>TEXTを含みであっている=<がどんな印刷可能なキャラクタ>もそうする、」
Note that newline (NL) need not be a single control character, but can be a sequence of control characters. A system MAY define TEXT to be a larger set of characters than <any CHAR excluding CTLs but including LWSP>.
ニューライン(NL)が単一管理キャラクタである必要はありませんが、制御文字の系列であるかもしれないことに注意してください。 5月が<より大きいキャラクタがCTLsを除きますが、LWSP>を含むあらゆるCHARであったならTEXTを定義するシステム。
2.3. URL Encoding
2.3. URLコード化
Some variables and constructs used here are described as being
'URL-encoded'. This encoding is described in section 2 of RFC 2396
[2]. In a URL-encoded string an escape sequence consists of a
percent character ("%") followed by two hexadecimal digits, where the
two hexadecimal digits form an octet. An escape sequence represents
the graphic character that has the octet as its code within the
US-ASCII [9] coded character set, if it exists. Currently there is
no provision within the URI syntax to identify which character set
non-ASCII codes represent, so CGI handles this issue on an ad-hoc
basis.
ここで使用されたいくつかの変数と構造物が'URLで、コード化されている'として記述されています。 このコード化はRFC2396[2]のセクション2で説明されます。 URLでコード化されたストリングでは、エスケープシーケンスは2つの16進数字があとに続いたパーセントキャラクタ(「%」)から成ります。そこで、2つの16進数字が八重奏を形成します。 エスケープシーケンスはコードとして米国-ASCII[9]コード化文字集合の中に八重奏を持っている図形文字を表します、存在しているなら。 現在、非ASCIIのコードがどの文字の組を表すかを特定するためにURI構文の中に支給が全くないので、CGIは臨時ベースでこの問題を扱います。
Note that some unsafe (reserved) characters may have different semantics when encoded. The definition of which characters are unsafe depends on the context; see section 2 of RFC 2396 [2], updated by RFC 2732 [7], for an authoritative treatment. These reserved characters are generally used to provide syntactic structure to the character string, for example as field separators. In all cases, the string is first processed with regard to any reserved characters present, and then the resulting data can be URL-decoded by replacing "%" escape sequences by their character values.
コード化されると何人かの危険な(予約される)キャラクタには異なった意味論があるかもしれないことに注意してください。 キャラクタが危険である定義は文脈によります。 正式の処理に関してRFC2732[7]によってアップデートされたRFC2396[2]のセクション2を見てください。 一般に、これらの控え目なキャラクタは、統語構造を文字列に提供するのに例えば、フィールド分離として使用されます。 すべての場合では、ストリングは最初に出席しているどんな控え目なキャラクタに関しても処理されます、そして、そして、結果として起こるデータはそれらの文字値によるURLで「%」を取り替えることによって解読されたエスケープシーケンスであるかもしれません。
Robinson & Coar Informational [Page 7] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[7ページ]情報のRFC3875CGIバージョン2004年10月1.1日
To encode a character string, all reserved and forbidden characters are replaced by the corresponding "%" escape sequences. The string can then be used in assembling a URI. The reserved characters will vary from context to context, but will always be drawn from this set:
文字列をコード化するために、予約されて、キャラクタに禁じられたすべてを対応する「%」エスケープシーケンスに取り替えます。 そして、URIを組み立てる際にストリングを使用できます。 控え目なキャラクタを文脈によって異なりますが、このセットからいつも得るでしょう:
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" |
"," | "[" | "]"
「予約された=」;、」 | "/" | "?" | ":" | "@" | "&" | "=" | "+" | "$" | "," | "[" | "]"
The last two characters were added by RFC 2732 [7]. In any particular context, a sub-set of these characters will be reserved; the other characters from this set MUST NOT be encoded when a string is URL-encoded in that context. Other basic rules used to describe URI syntax are:
最後の2つのキャラクタがRFC2732[7]によって加えられました。 どんな特定の文脈でも、これらのキャラクタの部分集合は予約されるでしょう。 ストリングがその文脈でURLによってコード化されているとき、このセットからの他のキャラクタをコード化してはいけません。 URI構文について説明するのに使用される他の基本的なルールは以下の通りです。
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" | "a" | "b"
| "c" | "d" | "e" | "f"
escaped = "%" hex hex
unreserved = alpha | digit | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
十六進法=ケタ| 「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| =「%」十六進法十六進法無遠慮な状態で逃げられた「f」はアルファと等しいです。| ケタ| マークマーク=「-」| "_" | "." | "!" | "~" | "*" | "'" | "(" | ")"
3. Invoking the Script
3. スクリプトを呼び出します。
3.1. Server Responsibilities
3.1. サーバ責任
The server acts as an application gateway. It receives the request from the client, selects a CGI script to handle the request, converts the client request to a CGI request, executes the script and converts the CGI response into a response for the client. When processing the client request, it is responsible for implementing any protocol or transport level authentication and security. The server MAY also function in a 'non-transparent' manner, modifying the request or response in order to provide some additional service, such as media type transformation or protocol reduction.
サーバはアプリケーションゲートウェイとして機能します。 それは、クライアントのためにクライアントから要求を受け取って、要求を扱うためにCGIスクリプトを選択して、クライアント要求をCGI要求に変換して、スクリプトを作成して、CGI応答を応答に変換します。 クライアントを処理するときにはそれはどんなプロトコルも実行するのに責任があるよう要求するか、または平らな認証とセキュリティを輸送してください。 また、サーバは'非透過'の方法で機能するかもしれません、何らかの追加サービスを提供するように要求か応答を変更して、メディアが変化かプロトコル減少をタイプするようなもの。
The server MUST perform translations and protocol conversions on the client request data required by this specification. Furthermore, the server retains its responsibility to the client to conform to the relevant network protocol even if the CGI script fails to conform to this specification.
サーバは翻訳を実行しなければなりません、そして、クライアントにおけるプロトコル変換はデータがこの仕様が必要であるよう要求します。 その上、CGIスクリプトがこの仕様に従わないでも、サーバは、関連ネットワーク・プロトコルに従うためにクライアントに責任を保有します。
If the server is applying authentication to the request, then it MUST NOT execute the script unless the request passes all defined access controls.
サーバが認証を要求に適用していて、要求パスがすべて、アクセス管理を定義しなかったなら、それはスクリプトを作成してはいけません。
Robinson & Coar Informational [Page 8] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[8ページ]情報のRFC3875CGIバージョン2004年10月1.1日
3.2. Script Selection
3.2. スクリプト選択
The server determines which CGI is script to be executed based on a generic-form URI supplied by the client. This URI includes a hierarchical path with components separated by "/". For any particular request, the server will identify all or a leading part of this path with an individual script, thus placing the script at a particular point in the path hierarchy. The remainder of the path, if any, is a resource or sub-resource identifier to be interpreted by the script.
サーバは、クライアントによって供給された一般的なフォームURIに基づいて実行されるためにどのCGIがスクリプトであるかを決定します。 「このURIはコンポーネントが」 /によって切り離されている階層的な経路を含んでいます。」 どんな特定の要求のためにも、サーバは独特のスクリプトですべてかこの経路の主役を特定するでしょう、その結果、経路階層構造で特定のポイントにスクリプトをみなします。 もしあれば経路の残りはスクリプトで解釈されるべきリソースかサブリソース識別子です。
Information about this split of the path is available to the script in the meta-variables, described below. Support for non-hierarchical URI schemes is outside the scope of this specification.
経路のこの分裂に関する情報は以下で説明されたメタ変数におけるスクリプトに利用可能です。 この仕様の範囲の外に非階層的なURI計画のサポートがあります。
3.3. The Script-URI
3.3. スクリプトURI
The mapping from client request URI to choice of script is defined by the particular server implementation and its configuration. The server may allow the script to be identified with a set of several different URI path hierarchies, and therefore is permitted to replace the URI by other members of this set during processing and generation of the meta-variables. The server
クライアント要求URIからスクリプトの選択までのマッピングは特定のサーバ実現とその構成によって定義されます。 サーバは、スクリプトがいくつかの異なったURI経路階層構造の1セットと同一視されるのを許容するかもしれなくて、したがって、メタ変数の処理と世代の間、URIをこのセットの他のメンバーに取り替えることが許可されています。 サーバ
1. MAY preserve the URI in the particular client request; or
1. 特定のクライアント要求におけるURIを保存するかもしれません。 または
2. it MAY select a canonical URI from the set of possible values
for each script; or
2. 各スクリプトのために可能な値のセットから正準なURIを選択するかもしれません。 または
3. it can implement any other selection of URI from the set.
3. それはセットからURIのいかなる他の選択も実行できます。
From the meta-variables thus generated, a URI, the 'Script-URI', can be constructed. This MUST have the property that if the client had accessed this URI instead, then the script would have been executed with the same values for the SCRIPT_NAME, PATH_INFO and QUERY_STRING meta-variables. The Script-URI has the structure of a generic URI as defined in section 3 of RFC 2396 [2], with the exception that object parameters and fragment identifiers are not permitted. The various components of the Script-URI are defined by some of the meta-variables (see below);
このようにして発生するメタ変数から、URI('スクリプトURI')を構成できます。 これには、クライアントであるなら代わりにこのURIにアクセスした特性がなければならなくて、次に、スクリプトはSCRIPT_NAME、PATH_INFO、およびQUERY_STRINGメタ変数のために同じ値で作成されたでしょう。 Script-URIには、一般的なURIの構造がRFC2396[2]のセクション3で定義されるようにあります、物のパラメタと断片識別子が受入れられない例外で。 Script-URIの様々なコンポーネントはメタ変数のいくつかによって定義されます(以下を見てください)。
script-URI = <scheme> "://" <server-name> ":" <server-port>
<script-path> <extra-path> "?" <query-string>
「」 」 ://<が>とサーバで命名するスクリプトURI=<計画>」:、」 <サーバポートの><スクリプト経路の>の<の余分な経路の>“?" <質問ストリング>。
where <scheme> is found from SERVER_PROTOCOL, <server-name>, <server-port> and <query-string> are the values of the respective meta-variables. The SCRIPT_NAME and PATH_INFO values, URL-encoded with ";", "=" and "?" reserved, give <script-path> and <extra-path>.
_<計画>がSERVERから見つけられるところでは、プロトコル、<サーバー名>、<サーバポート>、および<質問ストリング>がそれぞれのメタ変数の値です。 「SCRIPT_、NAMEとPATH_INFO値であって、URLでコード化される、」、;、」、「=」と“?"が予約されて、<スクリプト経路>と<の余分な経路の>に与えてください。
Robinson & Coar Informational [Page 9] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[9ページ]情報のRFC3875CGIバージョン2004年10月1.1日
See section 4.1.5 for more information about the PATH_INFO meta-variable.
PATH_INFOに関する詳しい情報のためのセクション4.1.5がメタ可変であることを見てください。
The scheme and the protocol are not identical as the scheme identifies the access method in addition to the application protocol. For example, a resource accessed using Transport Layer Security (TLS) [14] would have a request URI with a scheme of https when using the HTTP protocol [19]. CGI/1.1 provides no generic means for the script to reconstruct this, and therefore the Script-URI as defined includes the base protocol used. However, a script MAY make use of scheme-specific meta-variables to better deduce the URI scheme.
計画がアプリケーション・プロトコルに加えたアクセス法を特定するとき、計画とプロトコルは同じではありません。 HTTPプロトコル[19]を使用するとき、例えば、Transport Layer Security(TLS)[14]を使用することでアクセスされたリソースはhttpsの計画を伴う要求URIを持っているでしょう。 CGI/1.1はスクリプトがこれを再建するどんな一般的な手段も提供しません、そして、したがって、定義されるとしてのScript-URIは使用されるベースプロトコルを含んでいます。 しかしながら、スクリプトは、URI計画をよりよく推論するのに計画特有のメタ変数を利用するかもしれません。
Note that this definition also allows URIs to be constructed which would invoke the script with any permitted values for the path-info or query-string, by modifying the appropriate components.
また、この定義が、URIが構成されるのを許容するといういずれでもスクリプトを呼び出すメモはパスインフォメーションか質問ストリングのために値を可能にしました、適切なコンポーネントを変更することによって。
3.4. Execution
3.4. 実行
The script is invoked in a system-defined manner. Unless specified otherwise, the file containing the script will be invoked as an executable program. The server prepares the CGI request as described in section 4; this comprises the request meta-variables (immediately available to the script on execution) and request message data. The request data need not be immediately available to the script; the script can be executed before all this data has been received by the server from the client. The response from the script is returned to the server as described in sections 5 and 6.
スクリプトはシステムで定義された方法で呼び出されます。 別の方法で指定されないと、スクリプトを含むファイルは実行可能プログラムとして呼び出されるでしょう。 サーバはセクション4で説明されるようにCGI要求を準備します。 これは要求メタ変数(すぐに実行に関するスクリプトに利用可能な)と要求メッセージデータを包括します。 すぐに、要求データをスクリプトに得る必要はないことができます。 サーバでクライアントからこのすべてのデータを受け取る前にスクリプトを作成できます。 セクション5と6で説明されるようにスクリプトからの応答をサーバに返します。
In the event of an error condition, the server can interrupt or terminate script execution at any time and without warning. That could occur, for example, in the event of a transport failure between the server and the client; so the script SHOULD be prepared to handle abnormal termination.
エラー条件の場合、サーバは、いつでも、いきなりスクリプト実行を中断するか、または終えることができます。 例えば、それはサーバとクライアントの間の輸送失敗の場合、起こるかもしれません。 そのように、スクリプトSHOULD。異常終了を扱うように準備されます。
4. The CGI Request
4. CGI要求
Information about a request comes from two different sources; the request meta-variables and any associated message-body.
要求に関する情報は2人のさまざまな原因から来ます。 要求メタ変数といずれもメッセージ本体を関連づけました。
4.1. Request Meta-Variables
4.1. メタ変数を要求してください。
Meta-variables contain data about the request passed from the server
to the script, and are accessed by the script in a system-defined
manner. Meta-variables are identified by case-insensitive names;
there cannot be two different variables whose names differ in case
only. Here they are shown using a canonical representation of
capitals plus underscore ("_"). A particular system can define a
different representation.
メタ変数を、サーバからスクリプトまで合格された要求に関してデータを含んでいて、スクリプトでシステムで定義された方法でアクセスします。 メタ変数は大文字と小文字を区別しない名前によって特定されます。 名前が場合だけにおいて異なる2つの異なった変数があるはずがありません。 ここで、彼らは、首都の正準な表現を使用するのが示されて、("_")の下線を引きます。 特定のシステムは異なった表現を定義できます。
Robinson & Coar Informational [Page 10] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[10ページ]情報のRFC3875CGIバージョン2004年10月1.1日
meta-variable-name = "AUTH_TYPE" | "CONTENT_LENGTH" |
"CONTENT_TYPE" | "GATEWAY_INTERFACE" |
"PATH_INFO" | "PATH_TRANSLATED" |
"QUERY_STRING" | "REMOTE_ADDR" |
"REMOTE_HOST" | "REMOTE_IDENT" |
"REMOTE_USER" | "REQUEST_METHOD" |
"SCRIPT_NAME" | "SERVER_NAME" |
"SERVER_PORT" | "SERVER_PROTOCOL" |
"SERVER_SOFTWARE" | scheme |
protocol-var-name | extension-var-name
protocol-var-name = ( protocol | scheme ) "_" var-name
scheme = alpha *( alpha | digit | "+" | "-" | "." )
var-name = token
extension-var-name = token
メタ変数名=「AUTH_タイプ」| 「内容_長さ」| 「内容_はタイプします」| 「ゲートウェイ_インタフェース」| 「経路_インフォメーション」| 「経路_は翻訳しました」| 「質問_ストリング」| 「リモート_ADDR」| 「リモート_ホスト」| 「リモート_IDENT」| 「リモート_ユーザ」| 「_メソッドを要求してください」| 「スクリプト_名」| 「サーバ_名」| 「サーバ_ポート」| 「サーバ_プロトコル」| 「サーバ_ソフトウェア」| 体系| プロトコルvar名| 「拡大var名のプロトコルvar名の=(議定書を作ってください| 計画する)"_"var-名前体系=アルファ*、(アルファ| ケタ| 「+」 | 「-」|、」、」、)、var-名前=トークン拡大var名=トークン
Meta-variables with the same name as a scheme, and names beginning with the name of a protocol or scheme (e.g., HTTP_ACCEPT) are also defined. The number and meaning of these variables may change independently of this specification. (See also section 4.1.18.)
同じくらいがあるメタ変数が体系、および名前としてプロトコルの名前で始めを命名するか、またはまた、体系(例えば、HTTP_ACCEPT)は定義されます。 これらの変数の数と意味はこの仕様の如何にかかわらず変化するかもしれません。 (また、セクション4.1.18を見てください。)
The server MAY set additional implementation-defined extension meta- variables, whose names SHOULD be prefixed with "X_".
サーバが追加実装で定義された拡大を設定するかもしれない、メタ変数、だれの名前SHOULDは「X_」で前に置かれていますか?
This specification does not distinguish between zero-length (NULL) values and missing values. For example, a script cannot distinguish between the two requests http://host/script and http://host/script? as in both cases the QUERY_STRING meta-variable would be NULL.
この仕様はゼロ・レングス(NULL)値と欠測値を見分けません。 例えば、スクリプトは両方の場合におけるQUERY_STRINGメタ変数としての http://host/script と http://host/script? がNULLであるだろうという2つの要求を見分けることができません。
meta-variable-value = "" | 1*<TEXT, CHAR or tokens of value>
メタの可変値が等しい、「」| 値の>の1*<TEXT、CHARまたはトークン
An optional meta-variable may be omitted (left unset) if its value is NULL. Meta-variable values MUST be considered case-sensitive except as noted otherwise. The representation of the characters in the meta-variables is system-defined; the server MUST convert values to that representation.
任意のメタ変数は値がNULLであるなら省略されるかもしれません(unsetに残されます)。 別の方法で注意されるのを除いて、大文字と小文字を区別しているとメタ可変な値を考えなければなりません。 メタ変数における、キャラクタの表現はシステムによって定義されています。 サーバはその表現に値を変換しなければなりません。
4.1.1. AUTH_TYPE
4.1.1. AUTH_タイプ
The AUTH_TYPE variable identifies any mechanism used by the server to authenticate the user. It contains a case-insensitive value defined by the client protocol or server implementation.
AUTH_TYPE変数はサーバによって使用される、ユーザを認証するどんなメカニズムも特定します。 それはクライアントプロトコルかサーバ実装によって定義された大文字と小文字を区別しない値を含んでいます。
For HTTP, if the client request required authentication for external access, then the server MUST set the value of this variable from the 'auth-scheme' token in the request Authorization header field.
HTTPのために、クライアント要求が外部のアクセスのための認証を必要としたなら、サーバは要求Authorizationヘッダーフィールドにおける'auth-体系'トークンからこの変数の値を設定しなければなりません。
Robinson & Coar Informational [Page 11] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[11ページ]情報のRFC3875CGIバージョン2004年10月1.1日
AUTH_TYPE = "" | auth-scheme
auth-scheme = "Basic" | "Digest" | extension-auth
extension-auth = token
AUTH_タイプが等しい、「」| auth-体系auth-体系=「基本的です」。| 「読みこなしてください」| 拡大-auth拡大-authはトークンと等しいです。
HTTP access authentication schemes are described in RFC 2617 [5].
HTTPアクセス認証体系はRFC2617[5]で説明されます。
4.1.2. CONTENT_LENGTH
4.1.2. 内容_長さ
The CONTENT_LENGTH variable contains the size of the message-body attached to the request, if any, in decimal number of octets. If no data is attached, then NULL (or unset).
CONTENT_LENGTH変数は八重奏の10進数でもしあれば要求に付けられたメッセージ本体のサイズを含んでいます。 どんなデータも添付していないなら、そして、NULLです(または、unset)。
CONTENT_LENGTH = "" | 1*digit
内容_長さが等しい、「」| 1*ケタ
The server MUST set this meta-variable if and only if the request is accompanied by a message-body entity. The CONTENT_LENGTH value must reflect the length of the message-body after the server has removed any transfer-codings or content-codings.
そして、サーバがこのメタ変数を設定しなければならない、要求がメッセージ本体実体によって伴われる場合にだけ。 サーバがどんな転送コーディングや満足しているコーディングも取り除いた後にCONTENT_LENGTH値はメッセージ本体の長さを反映しなければなりません。
4.1.3. CONTENT_TYPE
4.1.3. 内容_はタイプします。
If the request includes a message-body, the CONTENT_TYPE variable is set to the Internet Media Type [6] of the message-body.
要求がメッセージ本体を含んでいるなら、CONTENT_TYPE変数はメッセージ本体のインターネットメディアType[6]に設定されます。
CONTENT_TYPE = "" | media-type
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
parameter = attribute "=" value
attribute = token
value = token | quoted-string
内容_が=をタイプする、「」| 属性「=」値属性=トークントークン「副-タイプ」=トークン」 「メディアタイプメディアタイプはタイプと等しく」/「副-タイプ」*(「;」パラメタ)タイプ=パラメタ=価値はトークンと等しいです。| 引用文字列
The type, subtype and parameter attribute names are not case-sensitive. Parameter values may be case sensitive. Media types and their use in HTTP are described section 3.7 of the HTTP/1.1 specification [4].
タイプ、「副-タイプ」、およびパラメタ属性名は大文字と小文字を区別していません。 パラメタ値は大文字と小文字を区別しているかもしれません。 メディアタイプとHTTPにおける彼らの使用はHTTP/1.1仕様[4]の説明されたセクション3.7です。
There is no default value for this variable. If and only if it is unset, then the script MAY attempt to determine the media type from the data received. If the type remains unknown, then the script MAY choose to assume a type of application/octet-stream or it may reject the request with an error (as described in section 6.3.3).
この変数のためのデフォルト値が全くありません。 そして、それがunsetである場合にだけ、スクリプトは、データからのメディアタイプが受信したことを決定するのを試みるかもしれません。 タイプが未知のままでいるなら、スクリプトは、誤りで要求を拒絶するかもしれない(セクション6.3.3で説明されるように)と仮定するのを選ぶかもしれません。
Each media-type defines a set of optional and mandatory parameters. This may include a charset parameter with a case-insensitive value defining the coded character set for the message-body. If the
それぞれのメディアタイプは1セットの任意の、そして、義務的なパラメタを定義します。 これはメッセージ本体のためにコード化文字集合を定義する大文字と小文字を区別しない値があるcharsetパラメタを含むかもしれません。 the
Robinson & Coar Informational [Page 12] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[12ページ]情報のRFC3875CGIバージョン2004年10月1.1日
charset parameter is omitted, then the default value should be derived according to whichever of the following rules is the first to apply:
charsetパラメタは省略されて、その時は適用する以下の規則の1番目であるデフォルトです値が引き出されるべきである:
1. There MAY be a system-defined default charset for some
media-types.
1. 何人かのメディアタイプのためのシステムで定義されたデフォルトcharsetがあるかもしれません。
2. The default for media-types of type "text" is ISO-8859-1 [4].
2. タイプ「テキスト」のメディアタイプのためのデフォルトはISO-8859-1[4]です。
3. Any default defined in the media-type specification.
3. メディアタイプ仕様に基づき定義されたどんなデフォルト。
4. The default is US-ASCII.
4. デフォルトは米国-ASCIIです。
The server MUST set this meta-variable if an HTTP Content-Type field is present in the client request header. If the server receives a request with an attached entity but no Content-Type header field, it MAY attempt to determine the correct content type, otherwise it should omit this meta-variable.
HTTPコンテントタイプ分野がクライアント要求ヘッダーに存在しているなら、サーバはこのメタ変数を設定しなければなりません。 サーバが付属実体にもかかわらず、どんなコンテントタイプヘッダーフィールドでも要求を受け取らないなら、それは、正しいcontent typeを決定するのを試みるかもしれません。さもなければ、このメタ変数を忘れるべきです。
4.1.4. GATEWAY_INTERFACE
4.1.4. ゲートウェイ_インタフェース
The GATEWAY_INTERFACE variable MUST be set to the dialect of CGI being used by the server to communicate with the script. Syntax:
サーバによって使用される、スクリプトで交信するCGIの方言にゲートウェイ_INTERFACE変数を設定しなければなりません。 構文:
GATEWAY_INTERFACE = "CGI" "/" 1*digit "." 1*digit
「ゲートウェイ_インタフェース=「CGI」」/、」 1*ケタ、」、」 1*ケタ
Note that the major and minor numbers are treated as separate integers and hence each may be incremented higher than a single digit. Thus CGI/2.4 is a lower version than CGI/2.13 which in turn is lower than CGI/12.3. Leading zeros MUST be ignored by the script and MUST NOT be generated by the server.
主要で小さい方の数が別々の整数として扱われて、したがって、それぞれ一桁より高く増加されるかもしれないことに注意してください。 したがって、CGI/2.4は順番に低いCGI/2.13より低いCGI/12.3よりバージョンです。 先行ゼロは、スクリプトで無視しなければならなくて、サーバによって生成されてはいけません。
This document defines the 1.1 version of the CGI interface.
このドキュメントはCGIインタフェースの1.1バージョンを定義します。
4.1.5. PATH_INFO
4.1.5. 経路_インフォメーション
The PATH_INFO variable specifies a path to be interpreted by the CGI script. It identifies the resource or sub-resource to be returned by the CGI script, and is derived from the portion of the URI path hierarchy following the part that identifies the script itself. Unlike a URI path, the PATH_INFO is not URL-encoded, and cannot contain path-segment parameters. A PATH_INFO of "/" represents a single void path segment.
PATH_INFO変数は、CGIスクリプトによって解釈されるために経路を指定します。 それをCGIスクリプトで返すためにリソースかサブリソースを特定して、スクリプト自体を特定する部分に続いて、URI経路階層構造の部分から得ます。 URI経路と異なって、PATH_INFOはURLによってコード化されていなくて、経路セグメントパラメタを含むことができません。 「」 /のPATH_INFO」はただ一つの空の経路セグメントを表します。
PATH_INFO = "" | ( "/" path )
path = lsegment *( "/" lsegment )
lsegment = *lchar
lchar = <any TEXT or CTL except "/">
経路_インフォメーションが等しい、「」| (「/」経路) 「経路=lsegment*(「/」lsegment)lsegment=*lchar lcharはどんなテキストやCTLも除く<と等しく」/">"
Robinson & Coar Informational [Page 13] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[13ページ]情報のRFC3875CGIバージョン2004年10月1.1日
The value is considered case-sensitive and the server MUST preserve the case of the path as presented in the request URI. The server MAY impose restrictions and limitations on what values it permits for PATH_INFO, and MAY reject the request with an error if it encounters any values considered objectionable. That MAY include any requests that would result in an encoded "/" being decoded into PATH_INFO, as this might represent a loss of information to the script. Similarly, treatment of non US-ASCII characters in the path is system-defined.
値は大文字と小文字を区別していると考えられます、そして、サーバは要求URIで提示されるように経路に関するケースを保存しなければなりません。 サーバは、それがPATH_INFOのためにどんな値を可能にするかに制限と制限を課して、何か好ましくないと考えられた値に遭遇するなら、誤りで要求を拒絶するかもしれません。 「それがもたらすどんな要求も含むかもしれない、コード化、」 」 これとして経路_インフォメーションに解読されるのがそうするかもしれない/は情報の損失をスクリプトに表します。 同様に、経路での非米国のASCII文字の処理はシステムによって定義されています。
URL-encoded, the PATH_INFO string forms the extra-path component of the Script-URI (see section 3.3) which follows the SCRIPT_NAME part of that path.
URLによってコード化されています、PATH_INFOストリングはその経路のSCRIPT_NAME地域に続くScript-URI(セクション3.3を見る)の付加的な経路コンポーネントを形成します。
4.1.6. PATH_TRANSLATED
4.1.6. 経路_は翻訳しました。
The PATH_TRANSLATED variable is derived by taking the PATH_INFO value, parsing it as a local URI in its own right, and performing any virtual-to-physical translation appropriate to map it onto the server's document repository structure. The set of characters permitted in the result is system-defined.
PATH_TRANSLATED変数はPATH_INFO値を取ることによって、引き出されます、地方のURIとしてそれ自体でそれを分析して、いずれも実行して仮想の身体検査、サーバの文書収納庫構造にそれを写像するのが適切である翻訳。 結果で受入れられたキャラクタのセットはシステムによって定義されています。
PATH_TRANSLATED = *<any character>
PATH_TRANSLATED=*<はあらゆるキャラクタ>です。
This is the file location that would be accessed by a request for
これは要求でアクセスされるファイルの位置です。
<scheme> "://" <server-name> ":" <server-port> <extra-path>
「」 」 ://<が>とサーバで命名する<体系>」:、」 <サーバポートの>の<の付加的な経路の>。
where <scheme> is the scheme for the original client request and <extra-path> is a URL-encoded version of PATH_INFO, with ";", "=" and "?" reserved. For example, a request such as the following:
「<体系>がオリジナルのクライアント要求と<の付加的な経路の>がどこの体系であるかがPATH_INFOのURLでコード化されたバージョンである、」 ; 」 「=」と“?"予約されています。 例えば、以下などの要求:
http://somehost.com/cgi-bin/somescript/this%2eis%2epath%3binfo
http://somehost.com/cgi-bin/somescript/this%2eis%2epath%3binfo
would result in a PATH_INFO value of
PATH_INFO値となるでしょう。
/this.is.the.path;info
/this.is.the.path; インフォメーション
An internal URI is constructed from the scheme, server location and the URL-encoded PATH_INFO:
内部のURIは体系、サーバ位置、およびURLでコード化されたPATH_INFOから構成されます:
http://somehost.com/this.is.the.path%3binfo
http://somehost.com/this.is.the.path%3binfo
This would then be translated to a location in the server's document repository, perhaps a filesystem path something like this:
次に、これはサーバの文書収納庫の位置、恐らくこのようなファイルシステム経路に翻訳されるでしょう:
/usr/local/www/htdocs/this.is.the.path;info
/usr/local/www/htdocs/this.is.the.path; インフォメーション
The value of PATH_TRANSLATED is the result of the translation.
PATH_TRANSLATEDの値は翻訳の結果です。
Robinson & Coar Informational [Page 14] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[14ページ]情報のRFC3875CGIバージョン2004年10月1.1日
The value is derived in this way irrespective of whether it maps to a valid repository location. The server MUST preserve the case of the extra-path segment unless the underlying repository supports case- insensitive names. If the repository is only case-aware, case- preserving, or case-blind with regard to document names, the server is not required to preserve the case of the original segment through the translation.
有効な倉庫に位置を写像するかどうかの如何にかかわらず値はこのように引き出されます。 基本的な倉庫がケースの神経の鈍い名をサポートしない場合、サーバは付加的な経路セグメントに関するケースを保存しなければなりません。 倉庫がケース意識しているだけのケース保存、またはドキュメントに関するケース盲目の名前であるなら、サーバは、翻訳によるオリジナルのセグメントに関するケースを保存するのに必要ではありません。
The translation algorithm the server uses to derive PATH_TRANSLATED is implementation-defined; CGI scripts which use this variable may suffer limited portability.
サーバがPATH_TRANSLATEDを引き出すのに使用する変換アルゴリズムは実装で定義されています。 この変数を使用するCGIスクリプトは限られた移植性を受けるかもしれません。
The server SHOULD set this meta-variable if the request URI includes a path-info component. If PATH_INFO is NULL, then the PATH_TRANSLATED variable MUST be set to NULL (or unset).
要求URIがパスインフォメーションコンポーネントを含んでいるなら、サーバSHOULDはこのメタ変数を設定します。 PATH_INFOがNULLであるなら、NULL(または、unset)にPATH_TRANSLATED変数を設定しなければなりません。
4.1.7. QUERY_STRING
4.1.7. 質問_ストリング
The QUERY_STRING variable contains a URL-encoded search or parameter string; it provides information to the CGI script to affect or refine the document to be returned by the script.
QUERY_STRING変数はURLでコード化された検索かパラメタストリングを含んでいます。 それは、スクリプトで返されるドキュメントを影響するか、または洗練するために情報をCGIスクリプトに提供します。
The URL syntax for a search string is described in section 3 of RFC 2396 [2]. The QUERY_STRING value is case-sensitive.
検索ストリングのためのURL構文はRFC2396[2]のセクション3で説明されます。 QUERY_STRING値は大文字と小文字を区別しています。
QUERY_STRING = query-string
query-string = *uric
uric = reserved | unreserved | escaped
QUERY_STRINGは尿の尿の=が予約した質問ストリング質問ストリング=*と等しいです。| 無遠慮| 逃げられます。
When parsing and decoding the query string, the details of the parsing, reserved characters and support for non US-ASCII characters depends on the context. For example, form submission from an HTML document [18] uses application/x-www-form-urlencoded encoding, in which the characters "+", "&" and "=" are reserved, and the ISO 8859-1 encoding may be used for non US-ASCII characters.
構文解析と質問ストリング、構文解析の詳細を解読するとキャラクタがいつ、予約されたか、そして、非米国のASCII文字のサポートは文脈によります。 例えば、HTMLドキュメント[18]からのフォーム服従はx-wwwフォームがアプリケーション/urlencodedされたコード化を使用します、そして、ISO8859-1コード化は非米国のASCII文字に使用されるかもしれません。(キャラクタ「+」、“&"、および「=」はそれで予約されています)。
The QUERY_STRING value provides the query-string part of the Script-URI. (See section 3.3).
QUERY_STRING値はScript-URIの質問ストリング部分を提供します。 (セクション3.3を見ます。)
The server MUST set this variable; if the Script-URI does not include
a query component, the QUERY_STRING MUST be defined as an empty
string ("").
サーバはこの変数を設定しなければなりません。 Script-URIが質問コンポーネントを含んでいないなら、QUERY_STRINGを空のストリングと定義しなければならない、(「「)、」
4.1.8. REMOTE_ADDR
4.1.8. リモート_ADDR
The REMOTE_ADDR variable MUST be set to the network address of the client sending the request to the server.
要求をサーバに送るクライアントのネットワーク・アドレスにREMOTE_ADDR変数を設定しなければなりません。
Robinson & Coar Informational [Page 15] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[15ページ]情報のRFC3875CGIバージョン2004年10月1.1日
REMOTE_ADDR = hostnumber
hostnumber = ipv4-address | ipv6-address
ipv4-address = 1*3digit "." 1*3digit "." 1*3digit "." 1*3digit
ipv6-address = hexpart [ ":" ipv4-address ]
hexpart = hexseq | ( [ hexseq ] "::" [ hexseq ] )
hexseq = 1*4hex *( ":" 1*4hex )
REMOTE_ADDR=hostnumber hostnumberはipv4-アドレスと等しいです。| 「ipv6-アドレスipv4-アドレスは1*3digitと等しい」、」 「1*3digit」、」 「1*3digit」、」 hexpart[「:」 ipv4-アドレス]1*3digit ipv6-アドレス=hexpartはhexseqと等しいです。| 「[hexseq]」: : 」 [hexseq) hexseqは1*4hex*と等しいです。(「:」 1*4hex)
The format of an IPv6 address is described in RFC 3513 [15].
IPv6アドレスの形式はRFC3513[15]で説明されます。
4.1.9. REMOTE_HOST
4.1.9. リモート_ホスト
The REMOTE_HOST variable contains the fully qualified domain name of the client sending the request to the server, if available, otherwise NULL. Fully qualified domain names take the form as described in section 3.5 of RFC 1034 [17] and section 2.1 of RFC 1123 [12]. Domain names are not case sensitive.
REMOTE_HOST変数はそうでなければ、利用可能であるなら要求をサーバに送るクライアント、NULLに関する完全修飾ドメイン名を含んでいます。 完全修飾ドメイン名はRFC1034[17]のセクション3.5とRFC1123[12]のセクション2.1で説明されるように形を取ります。 ドメイン名は大文字と小文字を区別していません。
REMOTE_HOST = "" | hostname | hostnumber
hostname = *( domainlabel "." ) toplabel [ "." ]
domainlabel = alphanum [ *alphahypdigit alphanum ]
toplabel = alpha [ *alphahypdigit alphanum ]
alphahypdigit = alphanum | "-"
リモート_ホスト=、「」| ホスト名| 「hostnumberホスト名=*、(domainlabel、」、」、)、toplabel、[「.」、]、domainlabel=alphanum[*alphahypdigit alphanum]toplabel=アルファ[*alphahypdigit alphanum]alphahypdigitはalphanumと等しいです。| "-"
The server SHOULD set this variable. If the hostname is not available for performance reasons or otherwise, the server MAY substitute the REMOTE_ADDR value.
サーバSHOULDはこの変数を設定します。 ホスト名が性能理由に利用可能でもなくて、またそうでなくもないなら、サーバはREMOTE_ADDR値を代入するかもしれません。
4.1.10. REMOTE_IDENT
4.1.10. リモート_IDENT
The REMOTE_IDENT variable MAY be used to provide identity information reported about the connection by an RFC 1413 [20] request to the remote agent, if available. The server may choose not to support this feature, or not to request the data for efficiency reasons, or not to return available identity data.
REMOTE_IDENT変数は、接続に関してリモートエージェントへのRFC1413[20]要求で報告されたアイデンティティ情報を提供するのにおいて中古であって、利用可能であるかもしれません。 サーバは、この特徴をサポートしないか、または効率理由か利用可能なアイデンティティデータを返さないようデータに要求しないのを選ぶかもしれません。
REMOTE_IDENT = *TEXT
リモート_IDENT=*テキスト
The data returned may be used for authentication purposes, but the level of trust reposed in it should be minimal.
返されたデータは使用されて、しかし、認証目的、置かれた信頼のレベルにおいて、それが最小限であるべきであるということであるかもしれません。
4.1.11. REMOTE_USER
4.1.11. リモート_ユーザ
The REMOTE_USER variable provides a user identification string supplied by client as part of user authentication.
REMOTE_USER変数はユーザー認証の一部としてクライアントによって供給されたユーザ登録名ストリングを提供します。
REMOTE_USER = *TEXT
リモート_ユーザ=*テキスト
Robinson & Coar Informational [Page 16] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[16ページ]情報のRFC3875CGIバージョン2004年10月1.1日
If the client request required HTTP Authentication [5] (e.g., the AUTH_TYPE meta-variable is set to "Basic" or "Digest"), then the value of the REMOTE_USER meta-variable MUST be set to the user-ID supplied.
クライアント要求がHTTP Authentication[5]を必要としたなら(例えば、AUTH_TYPEメタ変数は「基本的に」セットするか、または「読みこなす」ことです)、REMOTE_USERメタ変数の値を供給されたユーザIDに設定しなければなりません。
4.1.12. REQUEST_METHOD
4.1.12. _メソッドを要求してください。
The REQUEST_METHOD meta-variable MUST be set to the method which should be used by the script to process the request, as described in section 4.3.
REQUEST_METHODメタ変数を要求を処理するようにスクリプトで使用されるべきであるメソッドに設定しなければなりません、セクション4.3で説明されるように。
REQUEST_METHOD = method
method = "GET" | "POST" | "HEAD" | extension-method
extension-method = "PUT" | "DELETE" | token
メソッドREQUEST_METHOD=メソッドは「得てください」と等しいです。| 「ポスト」| 「向かってください」| =が「置いた」拡大メソッド拡大メソッド| 「削除」| トークン
The method is case sensitive. The HTTP methods are described in section 5.1.1 of the HTTP/1.0 specification [1] and section 5.1.1 of the HTTP/1.1 specification [4].
メソッドは大文字と小文字を区別しています。 HTTPメソッドは.1のセクション5.1HTTP/1.0仕様[1]と.1のセクション5.1HTTP/1.1仕様[4]で説明されます。
4.1.13. SCRIPT_NAME
4.1.13. スクリプト_名
The SCRIPT_NAME variable MUST be set to a URI path (not URL-encoded) which could identify the CGI script (rather than the script's output). The syntax is the same as for PATH_INFO (section 4.1.5)
CGIスクリプト(スクリプトの出力よりむしろ)を特定できたURI経路(URLでコード化されなかった)にSCRIPT_NAME変数を設定しなければなりません。 構文はPATH_INFOのように同じです。(セクション4.1.5)
SCRIPT_NAME = "" | ( "/" path )
スクリプト_が=を命名する、「」| (「/」経路)
The leading "/" is not part of the path. It is optional if the path is NULL; however, the variable MUST still be set in that case.
「主」/、」 経路が部分がありませんか? 経路がNULLであるなら任意です。 しかしながら、その場合まだ変数を設定しなければなりません。
The SCRIPT_NAME string forms some leading part of the path component of the Script-URI derived in some implementation-defined manner. No PATH_INFO segment (see section 4.1.5) is included in the SCRIPT_NAME value.
SCRIPT_NAMEストリングは何らかの実装で定義された方法で引き出されたScript-URIの経路コンポーネントの何らかの主役を形成します。 PATH_INFOセグメント(セクション4.1.5を見る)は全くSCRIPT_NAME値に含まれていません。
4.1.14. SERVER_NAME
4.1.14. サーバ_名
The SERVER_NAME variable MUST be set to the name of the server host to which the client request is directed. It is a case-insensitive hostname or network address. It forms the host part of the Script-URI.
クライアント要求が指示されているサーバー・ホストの名前にSERVER_NAME変数を設定しなければなりません。 それは、大文字と小文字を区別しないホスト名かネットワーク・アドレスです。 それはScript-URIのホスト部分を形成します。
SERVER_NAME = server-name
server-name = hostname | ipv4-address | ( "[" ipv6-address "]" )
サーバー名SERVER_NAME=サーバー名はホスト名と等しいです。| ipv4-アドレス| (「[「ipv6-アドレス」]」)
Robinson & Coar Informational [Page 17] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[17ページ]情報のRFC3875CGIバージョン2004年10月1.1日
A deployed server can have more than one possible value for this variable, where several HTTP virtual hosts share the same IP address. In that case, the server would use the contents of the request's Host header field to select the correct virtual host.
配布しているサーバはこの変数のための1つ以上の可能な値を持つことができます。(そこで、数人のHTTPの事実上のホストが同じIPアドレスを共有します)。 その場合、サーバは、正しい事実上のホストを選ぶのに要求のHostヘッダーフィールドのコンテンツを使用するでしょう。
4.1.15. SERVER_PORT
4.1.15. サーバ_ポート
The SERVER_PORT variable MUST be set to the TCP/IP port number on which this request is received from the client. This value is used in the port part of the Script-URI.
この要求がクライアントから受け取られるTCP/IPポートナンバーにSERVER_PORT変数を設定しなければなりません。 この値はScript-URIのポート部分で使用されます。
SERVER_PORT = server-port
server-port = 1*digit
サーバポートサーバSERVER_PORT=ポートは1*ケタと等しいです。
Note that this variable MUST be set, even if the port is the default port for the scheme and could otherwise be omitted from a URI.
この変数を設定しなければならないことに注意してください、ポートを体系のためのデフォルトポートである、そうでなければ、URIから省略できても。
4.1.16. SERVER_PROTOCOL
4.1.16. サーバ_プロトコル
The SERVER_PROTOCOL variable MUST be set to the name and version of the application protocol used for this CGI request. This MAY differ from the protocol version used by the server in its communication with the client.
SERVER_プロトコル変数は、このCGI要求に使用される名前へのセットとアプリケーション・プロトコルのバージョンであるに違いありません。 これはクライアントとのコミュニケーションでサーバによって使用されるプロトコルバージョンと異なるかもしれません。
SERVER_PROTOCOL = HTTP-Version | "INCLUDED" | extension-version
HTTP-Version = "HTTP" "/" 1*digit "." 1*digit
extension-version = protocol [ "/" 1*digit "." 1*digit ]
protocol = token
サーバ_プロトコル=HTTPバージョン| 「含まれています」。| 「拡大バージョンHTTPバージョンは「HTTP」と等しい」という/、」 1*ケタ、」、」 「1*ケタ拡大バージョン=プロトコル、[「/」1*ケタ、」 . 」 1*ケタ] プロトコル=トークン
Here, 'protocol' defines the syntax of some of the information passing between the server and the script (the 'protocol-specific' features). It is not case sensitive and is usually presented in upper case. The protocol is not the same as the scheme part of the script URI, which defines the overall access mechanism used by the client to communicate with the server. For example, a request that reaches the script with a protocol of "HTTP" may have used an "https" scheme.
ここで、'プロトコル'はサーバとスクリプト('プロトコル特有'の特徴)の間で情報通過のいくつかの構文を定義します。 それは、大文字と小文字を区別していなくて、通常、大文字の中に示されます。 プロトコルはスクリプトURIの体系部分と同じではありません。(URIはサーバとコミュニケートするのにクライアントによって使用された総合的なアクセス機構を定義します)。例えば、「HTTP」のプロトコルでスクリプトに達する要求は"https"体系を使用したかもしれません。
A well-known value for SERVER_PROTOCOL which the server MAY use is "INCLUDED", which signals that the current document is being included as part of a composite document, rather than being the direct target of the client request. The script should treat this as an HTTP/1.0 request.
サーバが使用するかもしれないSERVER_プロトコルのためのよく知られる値は「含まれている」(現在のドキュメントがクライアント要求のダイレクト目標であるより合成ドキュメントの一部としてむしろ含まれていると合図します)。 スクリプトはHTTP/1.0要求としてこれを扱うべきです。
Robinson & Coar Informational [Page 18] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[18ページ]情報のRFC3875CGIバージョン2004年10月1.1日
4.1.17. SERVER_SOFTWARE
4.1.17. サーバ_ソフトウェア
The SERVER_SOFTWARE meta-variable MUST be set to the name and version of the information server software making the CGI request (and running the gateway). It SHOULD be the same as the server description reported to the client, if any.
SERVER_SOFTWAREメタ変数は、CGI要求をする名前へのセットと情報サーバソフトウェアのバージョンであるに違いありません(ゲートウェイを動かして)。 それ、SHOULD、サーバ記述がクライアントに報告したのともしあれば同じにしてください。
SERVER_SOFTWARE = 1*( product | comment )
product = token [ "/" product-version ]
product-version = token
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
そして、1個の*(製品| コメント)製品=トークン[「/」製品バージョン]製品SERVER_SOFTWARE=バージョンがトークンコメント「(「*(ctext| コメント)」)」という=ctext=<と等しい、どんなテキスト除外、も「(「」、)、">"
4.1.18. Protocol-Specific Meta-Variables
4.1.18. プロトコル特有のメタ変数
The server SHOULD set meta-variables specific to the protocol and scheme for the request. Interpretation of protocol-specific variables depends on the protocol version in SERVER_PROTOCOL. The server MAY set a meta-variable with the name of the scheme to a non-NULL value if the scheme is not the same as the protocol. The presence of such a variable indicates to a script which scheme is used by the request.
サーバSHOULDは要求のプロトコルと体系に特定のメタ変数を設定します。 プロトコル特有の変数の解釈はSERVER_プロトコルのプロトコルバージョンによります。 体系がプロトコルと同じでないなら、サーバは体系の名前でメタ非NULLに可変な値を設定するかもしれません。 そのような変数の存在は、どの体系が要求で使用されるかをスクリプトに示します。
Meta-variables with names beginning with "HTTP_" contain values read from the client request header fields, if the protocol used is HTTP. The HTTP header field name is converted to upper case, has all occurrences of "-" replaced with "_" and has "HTTP_" prepended to give the meta-variable name. The header data can be presented as sent by the client, or can be rewritten in ways which do not change its semantics. If multiple header fields with the same field-name are received then the server MUST rewrite them as a single value having the same semantics. Similarly, a header field that spans multiple lines MUST be merged onto a single line. The server MUST, if necessary, change the representation of the data (for example, the character set) to be appropriate for a CGI meta-variable.
名前が「HTTP_」で始まっているメタ変数はクライアント要求ヘッダーフィールドから読まれた値を含んでいます、使用されるプロトコルがHTTPであるなら。 HTTPヘッダフィールド名で、大文字に変換されて、「-」のすべての発生を"_"に取り替えさせて、メタ変数名を与えるために「HTTP_」をprependedします。 ヘッダー・データをクライアントによって送られるように提示できるか、または意味論を変えない方法で書き直すことができます。 同じフィールド名がある複数のヘッダーフィールドが受け取られているなら、サーバは同じ意味論を持っているただ一つの値としてそれらを書き直さなければなりません。 同様に、複数の系列にかかるヘッダーフィールドを単線に合併しなければなりません。 必要なら、サーバは、CGIメタ変数に適切になるようにデータ(例えば、文字集合)の表現を変えなければなりません。
The server is not required to create meta-variables for all the header fields that it receives. In particular, it SHOULD remove any header fields carrying authentication information, such as 'Authorization'; or that are available to the script in other variables, such as 'Content-Length' and 'Content-Type'. The server MAY remove header fields that relate solely to client-side communication issues, such as 'Connection'.
サーバは、それが受けるすべてのヘッダーフィールドのためにメタ変数を作成するのに必要ではありません。 特にそれ、SHOULDは'承認'などの認証情報を運びながら、どんなヘッダーフィールドも取り除きます。 または、それは'満足している長さ'や'コンテントタイプ'などの他の変数におけるスクリプトに利用可能です。 サーバは唯一'接続'などのクライアントサイドコミュニケーション問題に関連するヘッダーフィールドを取り除くかもしれません。
Robinson & Coar Informational [Page 19] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[19ページ]情報のRFC3875CGIバージョン2004年10月1.1日
4.2. Request Message-Body
4.2. メッセージ本体を要求してください。
Request data is accessed by the script in a system-defined method; unless defined otherwise, this will be by reading the 'standard input' file descriptor or file handle.
スクリプトでシステムで定義されたメソッドでデータにアクセスするよう要求してください。 別の方法で定義されないと、これは、'標準の入力'ファイルディスクリプタかファイルハンドルを読むことによって、あるでしょう。
Request-Data = [ request-body ] [ extension-data ]
request-body = <CONTENT_LENGTH>OCTET
extension-data = *OCTET
要求データ=[要求本体][拡大データ]要求本体=<CONTENT_LENGTH>OCTET拡大データは*OCTETと等しいです。
A request-body is supplied with the request if the CONTENT_LENGTH is not NULL. The server MUST make at least that many bytes available for the script to read. The server MAY signal an end-of-file condition after CONTENT_LENGTH bytes have been read or it MAY supply extension data. Therefore, the script MUST NOT attempt to read more than CONTENT_LENGTH bytes, even if more data is available. However, it is not obliged to read any of the data.
CONTENT_LENGTHがNULLでないなら要求本体に要求を供給します。 サーバで、少なくともそんなに多くのバイトがスクリプトが読むように利用可能にならなければなりません。 CONTENT_LENGTHバイトを読んであるか、または拡大データを提供したかもしれない後にサーバはファイル終了条件を示すかもしれません。 したがって、より多くのデータが利用可能であっても、スクリプトは、CONTENT_LENGTHバイトよりもう少し読むのを試みてはいけません。 しかしながら、データのどれかを読むのは強いられません。
For non-parsed header (NPH) scripts (section 5), the server SHOULD attempt to ensure that the data supplied to the script is precisely as supplied by the client and is unaltered by the server.
非分析されたヘッダー(NPH)スクリプト(セクション5)のために、サーバSHOULDは、スクリプトに提供されたデータが正確にクライアントによって供給されるようにであるサーバによって非変更されるのを保証するのを試みます。
As transfer-codings are not supported on the request-body, the server MUST remove any such codings from the message-body, and recalculate the CONTENT_LENGTH. If this is not possible (for example, because of large buffering requirements), the server SHOULD reject the client request. It MAY also remove content-codings from the message-body.
転送コーディングが要求本体の上でサポートされないとき、サーバはメッセージ本体からどんなそのようなコーディングも取り除かなければなりません、そして、recalculateはCONTENT_LENGTHを取り除きます。 これが可能でないなら(例えば大きいバッファリング要件のために)、サーバSHOULDはクライアント要求を拒絶します。 また、それはメッセージ本体から満足しているコーディングを取り除くかもしれません。
4.3. Request Methods
4.3. メソッドを要求してください。
The Request Method, as supplied in the REQUEST_METHOD meta-variable, identifies the processing method to be applied by the script in producing a response. The script author can choose to implement the methods most appropriate for the particular application. If the script receives a request with a method it does not support it SHOULD reject it with an error (see section 6.3.3).
REQUEST_METHODメタ変数で供給するRequest Methodは応答を起こす際にスクリプトで適用されるべき処理メソッドを特定します。 スクリプト作者は、特定用途に、最も適切なメソッドを実装するのを選ぶことができます。 スクリプトがそれがそれをサポートしないメソッドで要求を受け取るなら、SHOULDは誤りでそれを拒絶します(セクション6.3.3を見てください)。
4.3.1. GET
4.3.1. 得てください。
The GET method indicates that the script should produce a document based on the meta-variable values. By convention, the GET method is 'safe' and 'idempotent' and SHOULD NOT have the significance of taking an action other than producing a document.
GETメソッドは、スクリプトがメタ可変な値に基づくドキュメントを製作するべきであるのを示します。 コンベンションで、GETメソッドは'安全です'、そして、'ベキ等元'とSHOULD NOTには、ドキュメントを製作するのを除いて、訴訟を起こす意味があります。
The meaning of the GET method may be modified and refined by protocol-specific meta-variables.
GETメソッドの意味は、プロトコル特有のメタ変数によって変更されて、洗練されるかもしれません。
Robinson & Coar Informational [Page 20] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[20ページ]情報のRFC3875CGIバージョン2004年10月1.1日
4.3.2. POST
4.3.2. ポスト
The POST method is used to request the script perform processing and produce a document based on the data in the request message-body, in addition to meta-variable values. A common use is form submission in HTML [18], intended to initiate processing by the script that has a permanent affect, such a change in a database.
ポストメソッドは要求メッセージ本体でスクリプトが処理を実行するよう要求して、データに基づくドキュメントを製作するのに使用されます、メタ可変な値に加えて。 一般の使用は永久的な感情を持っているスクリプトで処理を開始することを意図するHTML[18]でフォーム服従です、データベースにおけるそのような変化。
The script MUST check the value of the CONTENT_LENGTH variable before reading the attached message-body, and SHOULD check the CONTENT_TYPE value before processing it.
付属メッセージ本体を読む前にスクリプトはCONTENT_LENGTH変数の値をチェックしなければなりません、そして、それを処理する前に、SHOULDはCONTENT_TYPE値をチェックします。
4.3.3. HEAD
4.3.3. ヘッド
The HEAD method requests the script to do sufficient processing to return the response header fields, without providing a response message-body. The script MUST NOT provide a response message-body for a HEAD request. If it does, then the server MUST discard the message-body when reading the response from the script.
HEADメソッドは、応答ヘッダーフィールドを返すことができるくらい処理をするようスクリプトに要求します、応答メッセージ本体を提供しないで。 スクリプトは応答メッセージ本体をHEAD要求に提供してはいけません。 スクリプトから応答を読むとき、そうするなら、サーバはメッセージ本体を捨てなければなりません。
4.3.4. Protocol-Specific Methods
4.3.4. プロトコル特有のメソッド
The script MAY implement any protocol-specific method, such as HTTP/1.1 PUT and DELETE; it SHOULD check the value of SERVER_PROTOCOL when doing so.
スクリプトはHTTP/1.1のPUTやDELETEなどのどんなプロトコル特有のメソッドも実装するかもしれません。 それ、そうするとき、SHOULDはSERVER_プロトコルの値をチェックします。
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
4.4. スクリプトコマンドライン
Some systems support a method for supplying an array of strings to the CGI script. This is only used in the case of an 'indexed' HTTP query, which is identified by a 'GET' or 'HEAD' request with a URI query string that does not contain any unencoded "=" characters. For such a request, the server SHOULD treat the query-string as a search-string and parse it into words, using the rules
いくつかのシステムがストリングの配列をCGIスクリプトに供給するためのメソッドをサポートします。 これが'GET'によって特定される'索引をつけられた'HTTP質問の場合に使用されるだけですか、または'HEAD'は、URI質問ひもでそれが少しの暗号化されていない「=」キャラクタも含まないよう要求します。 そのような要求のために、サーバSHOULDは検索ストリングとして質問ストリングを扱って、単語にそれを分析します、規則を使用して
search-string = search-word *( "+" search-word )
search-word = 1*schar
schar = unreserved | escaped | xreserved
xreserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "," |
"$"
検索ストリング=探索語*(「+」 探索語)探索語は1*schar schar=と無遠慮な状態で等しいです。| 逃げられます。| 「xreserved xreserved=」;、」 | "/" | "?" | ":" | "@" | "&" | "=" | "," | "$"
After parsing, each search-word is URL-decoded, optionally encoded in a system-defined manner and then added to the command line argument list.
次に、構文解析の後に、それぞれの探索語は、URLで解読されて、システムで定義された方法で任意にコード化されていてコマンドラインアーギュメントの並びに追加されています。
Robinson & Coar Informational [Page 21] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[21ページ]情報のRFC3875CGIバージョン2004年10月1.1日
If the server cannot create any part of the argument list, then the server MUST NOT generate any command line information. For example, the number of arguments may be greater than operating system or server limits, or one of the words may not be representable as an argument.
サーバがアーギュメントの並びの少しの部分も作成できないなら、サーバは少しのコマンドライン情報も生成してはいけません。 例えば、引数の数がオペレーティングシステムかサーバ限界より大きいかもしれませんか、または単語の1つは議論として「表-可能」でないかもしれません。
The script SHOULD check to see if the QUERY_STRING value contains an unencoded "=" character, and SHOULD NOT use the command line arguments if it does.
スクリプトSHOULDはQUERY_STRING値が暗号化されていない「=」キャラクタを含むかどうか確認するためにチェックします、そして、使用するなら、コマンドライン議論を使用するべきではありません。
5. NPH Scripts
5. NPHスクリプト
5.1. Identification
5.1. 識別
The server MAY support NPH (Non-Parsed Header) scripts; these are scripts to which the server passes all responsibility for response processing.
サーバはNPH(非分析されたHeader)にスクリプトをサポートするかもしれません。 これらはサーバが応答処理へのすべての責任を通過するスクリプトです。
This specification provides no mechanism for an NPH script to be identified on the basis of its output data alone. By convention, therefore, any particular script can only ever provide output of one type (NPH or CGI) and hence the script itself is described as an 'NPH script'. A server with NPH support MUST provide an implementation- defined mechanism for identifying NPH scripts, perhaps based on the name or location of the script.
この仕様は、NPHスクリプトが出力データに基づいて単独で特定されるためにメカニズムを全く提供しません。 コンベンションで、したがって、どんな特定のスクリプトも1つのタイプ(NPHかCGI)の出力を提供できるだけです、そして、したがって、スクリプト自体は'NPHスクリプト'として記述されています。 NPHサポートがあるサーバは実装の定義されたメカニズムをNPHスクリプトを特定するのに提供しなければなりません、恐らくスクリプトの名前か位置に基づいて。
5.2. NPH Response
5.2. NPH応答
There MUST be a system-defined method for the script to send data back to the server or client; a script MUST always return some data. Unless defined otherwise, this will be the same as for conventional CGI scripts.
スクリプトがサーバかクライアントにデータを送り返すシステムで定義されたメソッドがあるに違いありません。 スクリプトはいつもいくつかのデータを返さなければなりません。 別の方法で定義されないと、これは従来のCGIスクリプトのように同じになるでしょう。
Currently, NPH scripts are only defined for HTTP client requests. An (HTTP) NPH script MUST return a complete HTTP response message, currently described in section 6 of the HTTP specifications [1], [4]. The script MUST use the SERVER_PROTOCOL variable to determine the appropriate format for a response. It MUST also take account of any generic or protocol-specific meta-variables in the request as might be mandated by the particular protocol specification.
現在、NPHスクリプトはHTTPクライアント要求のために定義されるだけです。 (HTTP)NPHスクリプトは現在HTTP仕様[1]のセクション6で説明されている完全なHTTP応答メッセージを返さなければなりません、[4]。 スクリプトは、応答のための適切な形式を決定するのにSERVER_プロトコル変数を使用しなければなりません。 また、それは特定のプロトコル仕様で強制されるかもしれないように要求におけるどんなジェネリックやプロトコル特有のメタ変数も考慮に入れなければなりません。
The server MUST ensure that the script output is sent to the client unmodified. Note that this requires the script to use the correct character set (US-ASCII [9] and ISO 8859-1 [10] for HTTP) in the header fields. The server SHOULD attempt to ensure that the script output is sent directly to the client, with minimal internal and no transport-visible buffering.
サーバは、スクリプト出力がクライアントに変更されていなく送られるのを確実にしなければなりません。 これがヘッダーフィールドに正しい文字集合(HTTPのための米国-ASCII[9]とISO8859-1[10])を使用するためにスクリプトを必要とすることに注意してください。 サーバSHOULDは、スクリプト出力が直接クライアントに送られるのを保証するのを試みます、最小量の内部の、そして、輸送目に見えないバッファリングで。
Robinson & Coar Informational [Page 22] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[22ページ]情報のRFC3875CGIバージョン2004年10月1.1日
Unless the implementation defines otherwise, the script MUST NOT indicate in its response that the client can send further requests over the same connection.
実装はそうでなければスクリプトを定義します。応答でクライアントがさらに同じ接続の上に要求を送ることができるのを示してはいけません。
6. CGI Response
6. CGI応答
6.1. Response Handling
6.1. 応答取り扱い
A script MUST always provide a non-empty response, and so there is a system-defined method for it to send this data back to the server. Unless defined otherwise, this will be via the 'standard output' file descriptor.
そして、スクリプトがいつも非空の応答を提供しなければならないので、このデータをサーバに送り返すシステムで定義されたメソッドがあります。別の方法で定義されないと、これは'標準の出力'ファイルディスクリプタであるでしょう。
The script MUST check the REQUEST_METHOD variable when processing the request and preparing its response.
要求を処理して、応答を準備するとき、スクリプトはREQUEST_METHOD変数をチェックしなければなりません。
The server MAY implement a timeout period within which data must be received from the script. If a server implementation defines such a timeout and receives no data from a script within the timeout period, the server MAY terminate the script process.
サーバはスクリプトからデータを受け取らなければならないタイムアウト時間を実装するかもしれません。 サーバ実装がタイムアウト時間中にそのようなタイムアウトを定義して、スクリプトからデータを全く受け取らないなら、サーバはスクリプトプロセスを終えるかもしれません。
6.2. Response Types
6.2. 応答タイプ
The response comprises a message-header and a message-body, separated by a blank line. The message-header contains one or more header fields. The body may be NULL.
応答はメッセージヘッダーと空白行によって切り離されたメッセージ本体を包括します。 メッセージヘッダーは1つ以上のヘッダーフィールドを含んでいます。 ボディーはNULLであるかもしれません。
generic-response = 1*header-field NL [ response-body ]
ジェネリック応答は1*ヘッダーフィールドNLと等しいです。[応答本体]
The script MUST return one of either a document response, a local redirect response or a client redirect (with optional document) response. In the response definitions below, the order of header fields in a response is not significant (despite appearing so in the BNF). The header fields are defined in section 6.3.
スクリプトはドキュメント応答、地方の再直接の応答またはクライアントの再直接(任意のドキュメントがある)の応答の1つを返さなければなりません。 以下での応答定義では、応答における、ヘッダーフィールドの注文は重要ではありません(したがって、BNFに現れますが)。 ヘッダーフィールドはセクション6.3で定義されます。
CGI-Response = document-response | local-redir-response |
client-redir-response | client-redirdoc-response
CGI応答はドキュメント応答と等しいです。| 地方のredir応答| クライアントredir応答| クライアントredirdoc応答
6.2.1. Document Response
6.2.1. ドキュメント応答
The CGI script can return a document to the user in a document response, with an optional error code indicating the success status of the response.
CGIスクリプトはドキュメント応答でドキュメントをユーザに返すことができます、任意のエラーコードが応答の成功状態を示していて。
document-response = Content-Type [ Status ] *other-field NL
response-body
ドキュメント応答はコンテントタイプ[状態]*他の分野NL応答ボディーと等しいです。
Robinson & Coar Informational [Page 23] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[23ページ]情報のRFC3875CGIバージョン2004年10月1.1日
The script MUST return a Content-Type header field. A Status header field is optional, and status 200 'OK' is assumed if it is omitted. The server MUST make any appropriate modifications to the script's output to ensure that the response to the client complies with the response protocol version.
スクリプトはコンテントタイプヘッダーフィールドを返さなければなりません。 Statusヘッダーフィールドは任意です、そして、それが省略されるなら、状態200'OK'は想定されます。 サーバは、クライアントへの応答が応答プロトコルバージョンに従うのを保証するためにスクリプトの出力へのどんな適切な変更もしなければなりません。
6.2.2. Local Redirect Response
6.2.2. 地方の再直接の応答
The CGI script can return a URI path and query-string
('local-pathquery') for a local resource in a Location header field.
This indicates to the server that it should reprocess the request
using the path specified.
CGIスクリプトはLocationヘッダーフィールドにおけるローカル資源のために、URI経路と質問ストリング('地方のpathquery')を返すことができます。 これが、そうするべきであるのをサーバに示す、「再-プロセス」、経路を使用する要求は指定しました。
local-redir-response = local-Location NL
地方のredir応答は地方の位置のNLと等しいです。
The script MUST NOT return any other header fields or a message-body, and the server MUST generate the response that it would have produced in response to a request containing the URL
スクリプトはいかなる他のヘッダーフィールドかメッセージ本体も返してはいけません、そして、サーバはそれがURLを含む要求に対応して起こした応答を生成しなければなりません。
scheme "://" server-name ":" server-port local-pathquery
「」 ://を計画してください」というサーバー名、」、:、」 サーバポートの地方のpathquery
6.2.3. Client Redirect Response
6.2.3. クライアントの再直接の応答
The CGI script can return an absolute URI path in a Location header field, to indicate to the client that it should reprocess the request using the URI specified.
CGIスクリプトがそうするべきであるのをクライアントに示すためにLocationヘッダーフィールドにおける絶対URI経路を返すことができる、「再-プロセス」、URIを使用する要求は指定しました。
client-redir-response = client-Location *extension-field NL
クライアント位置の*拡大分野クライアントredir応答=NL
The script MUST not provide any other header fields, except for server-defined CGI extension fields. For an HTTP client request, the server MUST generate a 302 'Found' HTTP response message.
スクリプトはサーバで定義されたCGI拡大分野以外のいかなる他のヘッダーフィールドも提供してはいけません。 HTTPクライアント要求のために、サーバはHTTP応答メッセージが'見つけられた'302を生成しなければなりません。
6.2.4. Client Redirect Response with Document
6.2.4. ドキュメントとのクライアントの再直接の応答
The CGI script can return an absolute URI path in a Location header field together with an attached document, to indicate to the client that it should reprocess the request using the URI specified.
CGIスクリプトがそうするべきであるのをクライアントに示すために添付書類と共にLocationヘッダーフィールドにおける絶対URI経路を返すことができる、「再-プロセス」、URIを使用する要求は指定しました。
client-redirdoc-response = client-Location Status Content-Type
*other-field NL response-body
クライアントredirdoc応答はクライアント位置のStatusコンテントタイプ*他の分野NL応答ボディーと等しいです。
The Status header field MUST be supplied and MUST contain a status value of 302 'Found', or it MAY contain an extension-code, that is, another valid status code that means client redirection. The server MUST make any appropriate modifications to the script's output to ensure that the response to the client complies with the response protocol version.
Statusヘッダーフィールドが供給しなければならなくて、'見つけられた'302の状態値を含まなければならない、さもなければ、それは拡張コード(すなわち、クライアントリダイレクションを意味する別の有効なステータスコード)を含むかもしれません。 サーバは、クライアントへの応答が応答プロトコルバージョンに従うのを保証するためにスクリプトの出力へのどんな適切な変更もしなければなりません。
Robinson & Coar Informational [Page 24] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[24ページ]情報のRFC3875CGIバージョン2004年10月1.1日
6.3. Response Header Fields
6.3. 応答ヘッダ分野
The response header fields are either CGI or extension header fields to be interpreted by the server, or protocol-specific header fields to be included in the response returned to the client. At least one CGI field MUST be supplied; each CGI field MUST NOT appear more than once in the response. The response header fields have the syntax:
応答ヘッダーフィールドは、CGIかサーバによって解釈されるべき拡大ヘッダーフィールドかクライアントに返された応答に含まれるべきプロトコル特有のヘッダーフィールドのどちらかです。 少なくとも1つのCGI野原を供給しなければなりません。 それぞれのCGI野原は応答で一度より多く見えてはいけません。 応答ヘッダーフィールドには、構文があります:
header-field = CGI-field | other-field
CGI-field = Content-Type | Location | Status
other-field = protocol-field | extension-field
protocol-field = generic-field
extension-field = generic-field
generic-field = field-name ":" [ field-value ] NL
field-name = token
field-value = *( field-content | LWSP )
field-content = *( token | separator | quoted-string )
ヘッダーフィールド=CGI分野| 他の分野CGI分野=コンテントタイプ| 位置| 状態他の分野=プロトコル分野| 「ジェネリック分野ジェネリック拡大分野プロトコル分野=ジェネリック分野拡大分野=分野はフィールド名と等しい」:、」 [分野値] *(分野内容| LWSP)分野NLフィールド名=トークン分野価値=内容は*と等しいです。(トークン|分離符|引用文字列)
The field-name is not case sensitive. A NULL field value is equivalent to a field not being sent. Note that each header field in a CGI-Response MUST be specified on a single line; CGI/1.1 does not support continuation lines. Whitespace is permitted between the ":" and the field-value (but not between the field-name and the ":"), and also between tokens in the field-value.
フィールド名は大文字と小文字を区別していません。 NULL分野価値は送られない野原に同等です。 単線の上でCGI応答における各ヘッダーフィールドを指定しなければならないことに注意してください。 CGI/1.1は継続行をサポートしません。 「空白が受入れられる、」、:、」 そして、「分野値、(フィールド名でない、」、:、」、)、分野値におけるトークンも
6.3.1. Content-Type
6.3.1. コンテントタイプ
The Content-Type response field sets the Internet Media Type [6] of the entity body.
コンテントタイプ応答分野は実体本体のインターネットメディアType[6]を設定します。
Content-Type = "Content-Type:" media-type NL
コンテントタイプが等しい、「コンテントタイプ:」 メディアタイプNL
If an entity body is returned, the script MUST supply a Content-Type field in the response. If it fails to do so, the server SHOULD NOT attempt to determine the correct content type. The value SHOULD be sent unmodified to the client, except for any charset parameter changes.
実体本体を返すなら、スクリプトは応答におけるコンテントタイプ野原を供給しなければなりません。 そうしないなら、サーバSHOULD NOTは、正しいcontent typeを決定するのを試みます。 クライアントにとって変更されていなく値のSHOULDを送って、どんなcharsetを除いても、パラメタは変化します。
Unless it is otherwise system-defined, the default charset assumed by the client for text media-types is ISO-8859-1 if the protocol is HTTP and US-ASCII otherwise. Hence the script SHOULD include a charset parameter. See section 3.4.1 of the HTTP/1.1 specification [4] for a discussion of this issue.
そうでなければ、プロトコルがHTTPと米国-ASCIIであり、そうでなければ、それがシステムによって定義されていない場合、テキストメディアタイプのためにクライアントによって想定されたデフォルトcharsetはISO-8859-1です。 したがって、スクリプトSHOULDはcharsetパラメタを含んでいます。 この問題の議論のための.1のセクション3.4HTTP/1.1仕様[4]を見てください。
Robinson & Coar Informational [Page 25] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[25ページ]情報のRFC3875CGIバージョン2004年10月1.1日
6.3.2. Location
6.3.2. 位置
The Location header field is used to specify to the server that the script is returning a reference to a document rather than an actual document (see sections 6.2.3 and 6.2.4). It is either an absolute URI (optionally with a fragment identifier), indicating that the client is to fetch the referenced document, or a local URI path (optionally with a query string), indicating that the server is to fetch the referenced document and return it to the client as the response.
セクション6.2.3と6.2を見てください。Locationヘッダーフィールドがスクリプトが実際のドキュメントよりむしろドキュメントの参照を返しているとサーバに指定するのに使用される、(.4)。 それが絶対URIである、(任意に、部分識別子)、クライアントが参照をつけられたドキュメント、または地方のURI経路をとって来ることになっているのを示す、(任意に、質問ストリング)、サーバが参照をつけられたドキュメントをとって来て、応答としてそれをクライアントに返すことであることを示します。
Location = local-Location | client-Location
client-Location = "Location:" fragment-URI NL
local-Location = "Location:" local-pathquery NL
fragment-URI = absoluteURI [ "#" fragment ]
fragment = *uric
local-pathquery = abs-path [ "?" query-string ]
abs-path = "/" path-segments
path-segments = segment *( "/" segment )
segment = *pchar
pchar = unreserved | escaped | extra
extra = ":" | "@" | "&" | "=" | "+" | "$" | ","
位置は地方の位置と等しいです。| クライアント位置のクライアント位置が等しい、「位置:」 断片URIのNLの地方の位置が等しい、「位置:」 「腹筋経路[“?"質問ストリング]腹筋地方のpathquery NL断片URI=absoluteURI[「#」断片]断片=*尿の地方のpathquery=経路は」 /と等しい」という経路セグメント経路セグメント=セグメント*(「/」セグメント)セグメントは*pchar pchar=と無遠慮な状態で等しいです。| 逃げられます。| 「付加的なエキストラ=」:、」 | "@" | "&" | "=" | "+" | "$" | ","
The syntax of an absoluteURI is incorporated into this document from that specified in RFC 2396 [2] and RFC 2732 [7]. A valid absoluteURI always starts with the name of scheme followed by ":"; scheme names start with a letter and continue with alphanumerics, "+", "-" or ".". The local URI path and query must be an absolute path, and not a relative path or NULL, and hence must start with a "/".
absoluteURIの構文はRFC2396[2]とRFC2732[7]で指定されたそれからのこのドキュメントに組み入れられます。 「有効なabsoluteURIは従われている体系の名前からいつも始まる」:、」、。 または、「体系名が、手紙から始まって、英数で「+」、「-」と続けている、」、」 「地方のURI経路と質問は、相対パスかNULLではなく、絶対パスでなければならなく、したがって、a」/から始まらなければなりません。」
Note that any message-body attached to the request (such as for a POST request) may not be available to the resource that is the target of the redirect.
要求(ポストの要求などの)に付けられたどんなメッセージ本体も再直接の目標であるリソースに利用可能でないかもしれないことに注意してください。
6.3.3. Status
6.3.3. 状態
The Status header field contains a 3-digit integer result code that indicates the level of success of the script's attempt to handle the request.
Statusヘッダーフィールドは要求を扱うスクリプトの試みの成功のレベルを示す3ケタの整数結果コードを含んでいます。
Status = "Status:" status-code SP reason-phrase NL
status-code = "200" | "302" | "400" | "501" | extension-code
extension-code = 3digit
reason-phrase = *TEXT
状態が等しい、「状態:」 ステータスコードSP理由句のNLステータスコード=「200」| "302" | "400" | "501" | 拡張コード拡張コード=3digit理由句の=*TEXT
Status code 200 'OK' indicates success, and is the default value assumed for a document response. Status code 302 'Found' is used with a Location header field and response message-body. Status code
ステータスコード200'OK'は、成功を示して、ドキュメント応答のために想定されたデフォルト値です。 '見つけられた'ステータスコード302はLocationヘッダーフィールドと応答メッセージ本体と共に使用されます。 ステータスコード
Robinson & Coar Informational [Page 26] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[26ページ]情報のRFC3875CGIバージョン2004年10月1.1日
400 'Bad Request' may be used for an unknown request format, such as a missing CONTENT_TYPE. Status code 501 'Not Implemented' may be returned by a script if it receives an unsupported REQUEST_METHOD.
400 '悪いRequest'はなくなったCONTENT_TYPEなどの未知の要求形式に使用されるかもしれません。 状態はImplementedではなく、501を'コード化します。'サポートされないREQUEST_METHODを受けるなら、スクリプトで返すかもしれません。
Other valid status codes are listed in section 6.1.1 of the HTTP specifications [1], [4], and also the IANA HTTP Status Code Registry [8] and MAY be used in addition to or instead of the ones listed above. The script SHOULD check the value of SERVER_PROTOCOL before using HTTP/1.1 status codes. The script MAY reject with error 405 'Method Not Allowed' HTTP/1.1 requests made using a method it does not support.
他の有効なステータスコードは、ものか上に記載されたものの代わりに.1のセクション6.1HTTP仕様[1]、[4]、およびIANA HTTP Status Code Registry[8]もに記載されていて、使用されるかもしれません。 HTTP/1.1のステータスコードを使用する前に、スクリプトSHOULDはSERVER_プロトコルの値をチェックします。 スクリプトは誤り405でそれがサポートしないメソッドを使用することでされた'メソッドNot Allowed'HTTP/1.1の要求を拒絶するかもしれません。
Note that returning an error status code does not have to mean an error condition with the script itself. For example, a script that is invoked as an error handler by the server should return the code appropriate to the server's error condition.
誤りステータスコードを返すとスクリプト自体があるエラー条件が意味する必要はないことに注意してください。 例えば、誤り操作者としてサーバによって呼び出されるスクリプトはサーバのエラー条件に適切なコードを返すべきです。
The reason-phrase is a textual description of the error to be returned to the client for human consumption.
理由句は人間の消費でクライアントに返される誤りの原文の記述です。
6.3.4. Protocol-Specific Header Fields
6.3.4. プロトコル特有のヘッダーフィールド
The script MAY return any other header fields that relate to the response message defined by the specification for the SERVER_PROTOCOL (HTTP/1.0 [1] or HTTP/1.1 [4]). The server MUST translate the header data from the CGI header syntax to the HTTP header syntax if these differ. For example, the character sequence for newline (such as UNIX's US-ASCII LF) used by CGI scripts may not be the same as that used by HTTP (US-ASCII CR followed by LF).
スクリプトはSERVER_プロトコルのための仕様で定義された応答メッセージに関連するいかなる他のヘッダーフィールドも返すかもしれません。(HTTP/1.0[1]かHTTP/1.1[4])。 これらが異なるなら、サーバはCGIヘッダー構文からHTTPヘッダ構文までヘッダー・データを翻訳しなければなりません。 例えば、CGIスクリプトによって使用されるニューライン(UNIXの米国-ASCII LFなどの)のためのキャラクタシーケンスはHTTPによって使用されるそれと同じでないかもしれません(米国-ASCII CRはLFで続きました)。
The script MUST NOT return any header fields that relate to client-side communication issues and could affect the server's ability to send the response to the client. The server MAY remove any such header fields returned by the client. It SHOULD resolve any conflicts between header fields returned by the script and header fields that it would otherwise send itself.
スクリプトは、クライアントサイドコミュニケーション問題に関連する少しのヘッダーフィールドも返してはいけなくて、応答をクライアントに送るサーバの能力に影響するかもしれません。 サーバはクライアントによって返されたどんなそのようなヘッダーフィールドも取り除くかもしれません。 それ、SHOULD自身はスクリプトで返されたヘッダーフィールドとそうでなければそれが送るヘッダーフィールドとのどんな闘争も解決します。
6.3.5. Extension Header Fields
6.3.5. 拡張ヘッダー分野
There may be additional implementation-defined CGI header fields, whose field names SHOULD begin with "X-CGI-". The server MAY ignore (and delete) any unrecognised header fields with names beginning "X- CGI-" that are received from the script.
SHOULDがフィールド名で始まる追加実装で定義されたCGIヘッダーフィールドがあるかもしれない、「X-CGI、-、」 サーバが無視するかもしれない、(削除、)、スクリプトから名前が「X CGI」 それを始めているどんな認識されていないヘッダーフィールドも受け取ります。
Robinson & Coar Informational [Page 27] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[27ページ]情報のRFC3875CGIバージョン2004年10月1.1日
6.4. Response Message-Body
6.4. 応答メッセージ本体
The response message-body is an attached document to be returned to the client by the server. The server MUST read all the data provided by the script, until the script signals the end of the message-body by way of an end-of-file condition. The message-body SHOULD be sent unmodified to the client, except for HEAD requests or any required transfer-codings, content-codings or charset conversions.
応答メッセージ本体はサーバによってクライアントに返される添付書類です。サーバはスクリプトで提供されたすべてのデータを読まなければなりません、スクリプトがファイル終了条件を通してメッセージ本体の先を示すまで。 クライアントにとって変更されていなくメッセージ本体SHOULDを送って、HEADを除いて、要求かいずれも転送コーディング、満足しているコーディングまたはcharset変換を必要としました。
response-body = *OCTET
応答本体=*OCTET
7. System Specifications
7. システム仕様
7.1. AmigaDOS
7.1. AmigaDOS
Meta-Variables
Meta-variables are passed to the script in identically named
environment variables. These are accessed by the DOS library
routine GetVar(). The flags argument SHOULD be 0. Case is
ignored, but upper case is recommended for compatibility with
case-sensitive systems.
メタ変数Meta-変数は同様に命名された環境変数のスクリプトに通過されます。 これらはDOSライブラリ・ルーチンGetVar()によってアクセスされます。 旗の議論SHOULD、0になってください。 ケースは無視されますが、大文字は大文字と小文字を区別するシステムとの互換性のために推薦されます。
The current working directory
The current working directory for the script is set to the
directory containing the script.
電流、ディレクトリを扱って、スクリプトのための現在の働くディレクトリはスクリプトを含むディレクトリに設定されます。
Character set
The US-ASCII character set [9] is used for the definition of
meta-variables, header fields and values; the newline (NL)
sequence is LF; servers SHOULD also accept CR LF as a newline.
文字集合、米国-ASCII文字の組[9]はメタ変数、ヘッダーフィールド、および値の定義に使用されます。 ニューライン(NL)系列はLFです。 また、サーバSHOULDはニューラインとしてCR LFを認めます。
7.2. UNIX
7.2. UNIX
For UNIX compatible operating systems, the following are defined:
UNIXコンパチブルオペレーティングシステムにおいて、以下は定義されます:
Meta-Variables
Meta-variables are passed to the script in identically named
environment variables. These are accessed by the C library
routine getenv() or variable environ.
メタ変数Meta-変数は同様に命名された環境変数のスクリプトに通過されます。 これらはCライブラリ・ルーチンgetenv()によってアクセスされるか、または変数が取り巻かれます。
The command line
This is accessed using the argc and argv arguments to main(). The
words have any characters which are 'active' in the Bourne shell
escaped with a backslash.
コマンドラインThisは、argcとargv議論をメイン()に使用することでアクセスされています。 単語には、どんなバックスラッシュで逃げられたBourneシェルの中に'アクティブな'キャラクタもあります。
The current working directory
The current working directory for the script SHOULD be set to the
directory containing the script.
現在の働くディレクトリ、現在の働くディレクトリ、スクリプトSHOULDには、スクリプトを含むディレクトリに設定されてください。
Robinson & Coar Informational [Page 28] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[28ページ]情報のRFC3875CGIバージョン2004年10月1.1日
Character set
The US-ASCII character set [9], excluding NUL, is used for the
definition of meta-variables, header fields and CHAR values; TEXT
values use ISO-8859-1. The PATH_TRANSLATED value can contain any
8-bit byte except NUL. The newline (NL) sequence is LF; servers
should also accept CR LF as a newline.
文字集合、NULを除いて、米国-ASCII文字の組[9]はメタ変数、ヘッダーフィールド、およびCHAR値の定義に使用されます。 TEXT値はISO-8859-1を使用します。 PATH_TRANSLATED値はNUL以外のどんな8ビットのバイトも含むことができます。 ニューライン(NL)系列はLFです。 また、サーバはニューラインとしてCR LFを認めるべきです。
7.3. EBCDIC/POSIX
7.3. EBCDIC/POSIX
For POSIX compatible operating systems using the EBCDIC character set, the following are defined:
EBCDIC文字集合を使用するPOSIXコンパチブルオペレーティングシステムにおいて、以下は定義されます:
Meta-Variables
Meta-variables are passed to the script in identically named
environment variables. These are accessed by the C library
routine getenv().
メタ変数Meta-変数は同様に命名された環境変数のスクリプトに通過されます。 これらはCライブラリ・ルーチンgetenv()によってアクセスされます。
The command line
This is accessed using the argc and argv arguments to main(). The
words have any characters which are 'active' in the Bourne shell
escaped with a backslash.
コマンドラインThisは、argcとargv議論をメイン()に使用することでアクセスされています。 単語には、どんなバックスラッシュで逃げられたBourneシェルの中に'アクティブな'キャラクタもあります。
The current working directory
The current working directory for the script SHOULD be set to the
directory containing the script.
現在の働くディレクトリ、現在の働くディレクトリ、スクリプトSHOULDには、スクリプトを含むディレクトリに設定されてください。
Character set
The IBM1047 character set [21], excluding NUL, is used for the
definition of meta-variables, header fields, values, TEXT strings
and the PATH_TRANSLATED value. The newline (NL) sequence is LF;
servers should also accept CR LF as a newline.
文字集合、NULを除いて、IBM1047文字集合[21]はメタ変数、ヘッダーフィールド、値、TEXTストリング、およびPATH_TRANSLATED価値の定義に使用されます。 ニューライン(NL)系列はLFです。 また、サーバはニューラインとしてCR LFを認めるべきです。
media-type charset default
The default charset value for text (and other implementation-
defined) media types is IBM1047.
テキスト(そして、定義された他の実装)メディアのためのデフォルトcharset価値がタイプするメディアタイプcharsetデフォルトはIBM1047です。
8. Implementation
8. 実装
8.1. Recommendations for Servers
8.1. サーバのための推薦
Although the server and the CGI script need not be consistent in their handling of URL paths (client URLs and the PATH_INFO data, respectively), server authors may wish to impose consistency. So the server implementation should specify its behaviour for the following cases:
サーバとCGIスクリプトは彼らのURL経路(それぞれクライアントURLとPATH_INFOデータ)の取り扱いで一貫している必要はありませんが、サーバ作者は一貫性を課したがっているかもしれません。 それで、サーバ実装は以下のケースのためのふるまいを指定するべきです:
1. define any restrictions on allowed path segments, in particular
whether non-terminal NULL segments are permitted;
1. 許容経路セグメントであらゆる制限を定義してください、そして、非端末であるか否かに関係なく、特に、NULLセグメントは受入れられます。
Robinson & Coar Informational [Page 29] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[29ページ]情報のRFC3875CGIバージョン2004年10月1.1日
2. define the behaviour for "." or ".." path segments; i.e.,
whether they are prohibited, treated as ordinary path segments
or interpreted in accordance with the relative URL
specification [2];
「2.はふるまいを定義する」、」、」、」 経路セグメント。 すなわち、それらが禁止されているか、普通の経路セグメントとして扱われるか、または相対的なURL仕様[2]通りに解釈されることにかかわらず。
3. define any limits of the implementation, including limits on
path or search string lengths, and limits on the volume of
header fields the server will parse.
3. 実装のあらゆる限界を定義してください、経路か検索ストリング長における限界、およびサーバが分析するヘッダーフィールドのボリュームにおける限界を含んでいて。
8.2. Recommendations for Scripts
8.2. スクリプトのための推薦
If the script does not intend processing the PATH_INFO data, then it should reject the request with 404 Not Found if PATH_INFO is not NULL.
PATH_INFOがNULLでなく、またスクリプトが、PATH_INFOデータを処理することを意図しないなら、それは404Not Foundとの要求を拒絶するべきです。
If the output of a form is being processed, check that CONTENT_TYPE is "application/x-www-form-urlencoded" [18] or "multipart/form-data" [16]. If CONTENT_TYPE is blank, the script can reject the request with a 415 'Unsupported Media Type' error, where supported by the protocol.
形式の出力が処理されているなら、CONTENT_TYPEが「x-wwwフォームはアプリケーション/urlencodedしている」[18]か「複合/フォームデータ」[16]であることをチェックしてください。 CONTENT_TYPEが空白であるなら、スクリプトは415'サポートされないメディアType'誤りで要求を拒絶できます、プロトコルによってサポートされるところで。
When parsing PATH_INFO, PATH_TRANSLATED or SCRIPT_NAME the script
should be careful of void path segments ("//") and special path
segments ("." and ".."). They should either be removed from the path
before use in OS system calls, or the request should be rejected with
404 'Not Found'.
そして、「PATH_INFO、PATH_TRANSLATEDまたはSCRIPT_NAMEを分析するとき、スクリプトが空の経路セグメント(「//」)と特別な経路セグメントに注意しているべきである、(「.」、」、」、) OSシステムコールにおける使用の前に経路からそれらを取り除くべきであるか、またはFoundではなく、404で'要求を拒絶するべきである、'
When returning header fields, the script should try to send the CGI header fields as soon as possible, and should send them before any HTTP header fields. This may help reduce the server's memory requirements.
ヘッダーフィールドを返すとき、スクリプトは、できるだけ早くCGIヘッダーフィールドを送ろうとするべきであって、どんなHTTPヘッダ分野の前にもそれらを送るべきです。 これは、サーバのメモリ要件を減らすのを助けるかもしれません。
Script authors should be aware that the REMOTE_ADDR and REMOTE_HOST meta-variables (see sections 4.1.8 and 4.1.9) may not identify the ultimate source of the request. They identify the client for the immediate request to the server; that client may be a proxy, gateway, or other intermediary acting on behalf of the actual source client.
スクリプト作者が意識しているべきである、それ、REMOTE_ADDRとREMOTE_HOSTメタ変数、(セクション4.1.8を見てください。そうすれば、4.1に、.9は)要求の究極の源を特定する必要はありません。 彼らは即座の要求のためにサーバにクライアントを特定します。 そのクライアントは、実際のソースクライアントを代表して行動しているプロキシ、ゲートウェイ、または他の仲介者であるかもしれません。
9. Security Considerations
9. セキュリティ問題
9.1. Safe Methods
9.1. 確実な方法
As discussed in the security considerations of the HTTP specifications [1], [4], the convention has been established that the GET and HEAD methods should be 'safe' and 'idempotent' (repeated requests have the same effect as a single request). See section 9.1 of RFC 2616 [4] for a full discussion.
[4] コンベンションはHTTP仕様[1]のセキュリティ問題で議論するように設立されました。GETとHEADメソッドは、'安全'、そして、'ベキ等元'であるべきです(再三の要求には、ただ一つの要求と同じ効果があります)。 十分な議論のためのRFC2616[4]のセクション9.1を見てください。
Robinson & Coar Informational [Page 30] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[30ページ]情報のRFC3875CGIバージョン2004年10月1.1日
9.2. Header Fields Containing Sensitive Information
9.2. 機密情報を含むヘッダーフィールド
Some HTTP header fields may carry sensitive information which the server should not pass on to the script unless explicitly configured to do so. For example, if the server protects the script by using the Basic authentication scheme, then the client will send an Authorization header field containing a username and password. The server validates this information and so it should not pass on the password via the HTTP_AUTHORIZATION meta-variable without careful consideration. This also applies to the Proxy-Authorization header field and the corresponding HTTP_PROXY_AUTHORIZATION meta-variable.
いくつかのHTTPヘッダ分野がそうするために明らかに構成されない場合サーバがスクリプトに通過するべきでない機密情報を運ぶかもしれません。 例えば、サーバがBasic認証体系を使用することによってスクリプトを保護すると、クライアントはユーザ名とパスワードを含むAuthorizationヘッダーフィールドを送るでしょう。 サーバがこの情報を有効にするので、それは熟慮のないHTTP_AUTHORIZATIONメタ変数でパスワードを伝えるべきではありません。 また、これはProxy-承認ヘッダーフィールドと対応するHTTP_PROXY_AUTHORIZATIONメタ変数に適用されます。
9.3. Data Privacy
9.3. データプライバシー
Confidential data in a request should be placed in a message-body as part of a POST request, and not placed in the URI or message headers. On some systems, the environment used to pass meta-variables to a script may be visible to other scripts or users. In addition, many existing servers, proxies and clients will permanently record the URI where it might be visible to third parties.
要求における秘密のデータはポストの要求の一部としてメッセージ本体に置いて、URIかメッセージヘッダーに置くべきではありません。 いくつかのシステムの上では、他のスクリプトかユーザにとって、メタ変数をスクリプトに通過するのに使用される環境は目に見えるかもしれません。 さらに、第三者にとって、それが目に見えるかもしれないところに多くの既存のサーバ、プロキシ、およびクライアントは永久に、URIを記録するでしょう。
9.4. Information Security Model
9.4. 情報機密保護モデル
For a client connection using TLS, the security model applies between the client and the server, and not between the client and the script. It is the server's responsibility to handle the TLS session, and thus it is the server which is authenticated to the client, not the CGI script.
TLSを使用しているクライアント接続のために、機密保護モデルはクライアントとスクリプトの間で申し込むのではなく、クライアントとサーバの間で申し込みます。 TLSセッションを扱うのが、サーバの責任であり、その結果、それはCGIスクリプトではなく、クライアントに認証されるサーバです。
This specification provides no mechanism for the script to authenticate the server which invoked it. There is no enforced integrity on the CGI request and response messages.
スクリプトがそれを呼び出したサーバを認証するように、この仕様はメカニズムを全く提供しません。 CGI要求と応答メッセージに関する保全は励行されません。
9.5. Script Interference with the Server
9.5. サーバのスクリプト干渉
The most common implementation of CGI invokes the script as a child process using the same user and group as the server process. It should therefore be ensured that the script cannot interfere with the server process, its configuration, documents or log files.
サーバとしての同じユーザを使用する子プロセスとグループが処理されるとき、CGIの最も一般的な実装はスクリプトを呼び出します。 したがって、スクリプトがサーバプロセス、構成、ドキュメントまたはログファイルを妨げることができないのが確実にされるべきです。
If the script is executed by calling a function linked in to the server software (either at compile-time or run-time) then precautions should be taken to protect the core memory of the server, or to ensure that untrusted code cannot be executed.
スクリプトがサーバソフトウェア(コンパイル時かランタイムの)にリンクされた機能を回収することによって作成されるなら、サーバのコアメモリを保護するか、または信頼されていないコードを実行できないのを保証するために注意するべきです。
Robinson & Coar Informational [Page 31] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[31ページ]情報のRFC3875CGIバージョン2004年10月1.1日
9.6. Data Length and Buffering Considerations
9.6. データの長さと問題をバッファリングすること。
This specification places no limits on the length of the message-body presented to the script. The script should not assume that statically allocated buffers of any size are sufficient to contain the entire submission at one time. Use of a fixed length buffer without careful overflow checking may result in an attacker exploiting 'stack-smashing' or 'stack-overflow' vulnerabilities of the operating system. The script may spool large submissions to disk or other buffering media, but a rapid succession of large submissions may result in denial of service conditions. If the CONTENT_LENGTH of a message-body is larger than resource considerations allow, scripts should respond with an error status appropriate for the protocol version; potentially applicable status codes include 503 'Service Unavailable' (HTTP/1.0 and HTTP/1.1), 413 'Request Entity Too Large' (HTTP/1.1), and 414 'Request-URI Too Large' (HTTP/1.1).
この仕様はスクリプトに提示されたメッセージ本体の長さに限界を全く置きません。 スクリプトは、どんなサイズの静的に割り当てられたバッファもひところ全体の服従を含むように十分であると仮定するべきではありません。 慎重なオーバーフローの照合のない固定長バッファの使用はオペレーティングシステムの'スタック粉砕'か'スタックオーバーフロー'脆弱性を利用している攻撃者をもたらすかもしれません。 スクリプトはメディアをバッファリングしながら、何らかのディスクに大きい差出をスプールするかもしれませんが、大きい差出の急速な連続は運転条件の否定をもたらすかもしれません。 メッセージ本体のCONTENT_LENGTHがリソース問題が許容するより大きいなら、スクリプトはプロトコルバージョンに、適切なエラー状況で応じるべきです。 潜在的に適切なステータスコードは'要求Entity Too Large'(HTTP/1.1)、および414'要求URI Too Large'(HTTP/1.1)503'サービスUnavailable'(HTTP/1.0とHTTP/1.1)、413を含んでいます。
Similar considerations apply to the server's handling of the CGI response from the script. There is no limit on the length of the header or message-body returned by the script; the server should not assume that statically allocated buffers of any size are sufficient to contain the entire response.
同様の問題はスクリプトからCGI応答のサーバの取り扱いに適用されます。 限界が全くスクリプトで返されたヘッダーかメッセージ本体の長さにありません。 サーバは、どんなサイズの静的に割り当てられたバッファも全体の応答を含むように十分であると仮定するべきではありません。
9.7. Stateless Processing
9.7. 状態がない処理
The stateless nature of the Web makes each script execution and resource retrieval independent of all others even when multiple requests constitute a single conceptual Web transaction. Because of this, a script should not make any assumptions about the context of the user-agent submitting a request. In particular, scripts should examine data obtained from the client and verify that they are valid, both in form and content, before allowing them to be used for sensitive purposes such as input to other applications, commands, or operating system services. These uses include (but are not limited to) system call arguments, database writes, dynamically evaluated source code, and input to billing or other secure processes. It is important that applications be protected from invalid input regardless of whether the invalidity is the result of user error, logic error, or malicious action.
複数の要求がただ一つの概念的なウェブトランザクションを構成さえするとき、ウェブの状態がない本質で、実行とすべての他のものの如何にかかわらずリソース各スクリプトを検索します。 これのために、スクリプトは、要求を提出しながら、ユーザエージェントの文脈に関する少しの仮定もするべきではありません。 スクリプトは、特に、クライアントから得られたデータを調べて、それらが有効であることを確かめるべきです、フォームと内容で、それらが他のアプリケーション、コマンド、またはオペレーティングシステムサービスに入力されるような敏感な目的に使用されるのを許容する前に。 データベースは、しかし、これらの用途が含んでいる、(制限されない、)、システムコール議論がダイナミックにソースコードを評価して、安全なプロセスを何らかの支払いに入力したと書きます。 アプリケーションが無効がユーザ誤り、論理誤り、または悪意がある行為の結果であるかどうかにかかわらず無効の入力から保護されるのは、重要です。
Authors of scripts involved in multi-request transactions should be particularly cautious about validating the state information; undesirable effects may result from the substitution of dangerous values for portions of the submission which might otherwise be presumed safe. Subversion of this type occurs when alterations are made to data from a prior stage of the transaction that were not meant to be controlled by the client (e.g., hidden HTML form elements, cookies, embedded URLs, etc.).
マルチ要求トランザクションにかかわるスクリプトの作者は州の情報を有効にすることに関して特に用心深いはずです。 望ましくない効果は別の方法で安全であると推定されるかもしれない服従の部分への危険な値の代替から生じるかもしれません。 変更をクライアントによって制御されることになっていなかった(例えば、HTMLフォームエレメント、クッキー、埋め込まれたURLなどを隠します)トランザクションの先のステージからデータにするとき、このタイプの転覆は起こります。
Robinson & Coar Informational [Page 32] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[32ページ]情報のRFC3875CGIバージョン2004年10月1.1日
9.8. Relative Paths
9.8. 相対パス
The server should be careful of ".." path segments in the request URI. These should be removed or resolved in the request URI before it is split into the script-path and extra-path. Alternatively, when the extra-path is used to find the PATH_TRANSLATED, care should be taken to avoid the path resolution from providing translated paths outside an expected path hierarchy.
「サーバは」 . . 」 要求ユリの経路セグメントに注意しているべきです。 それをスクリプト経路と付加的な経路に分ける前に、要求URIでこれらを取り除くべきであるか、または決議するべきです。 付加的な経路がPATH_がTRANSLATEDであることがわかるのに使用されるとき、あるいはまた、予想された経路階層構造の外で翻訳された経路を提供するので経路解決を避けるために注意するべきです。
9.9. Non-parsed Header Output
9.9. 非分析されたヘッダー出力
If a script returns a non-parsed header output, to be interpreted by the client in its native protocol, then the script must address all security considerations relating to that protocol.
固有のプロトコルでクライアントによって解釈されるようにスクリプトが非分析されたヘッダー出力を返すなら、スクリプトは、すべてのセキュリティがそのプロトコルに関連する問題であると扱わなければなりません。
10. Acknowledgements
10. 承認
This work is based on the original CGI interface that arose out of discussions on the 'www-talk' mailing list. In particular, Rob McCool, John Franks, Ari Luotonen, George Phillips and Tony Sanders deserve special recognition for their efforts in defining and implementing the early versions of this interface.
この仕事は'www-話'メーリングリストについての議論から起こった元のCGIインタフェースに基づいています。 特に、ロブMcCool、ジョン・フランクス、アリLuotonen、ジョージフィリップス、およびトニーSandersはこのインタフェースの早めのバージョンを定義して、実装する際に彼らの取り組みのための特別な認識に値します。
This document has also greatly benefited from the comments and suggestions made Chris Adie, Dave Kristol and Mike Meyer; also David Morris, Jeremy Madea, Patrick McManus, Adam Donahue, Ross Patterson and Harald Alvestrand.
また、このドキュメントは大いにコメントの利益を得ました、そして、提案はクリス・エーディ、デーヴ・クリストル、およびマイク・マイヤーを作りました。 デヴィッドモリスも、ジェレミーMadea、パトリック・マクマナス、アダム・ドナヒュー、ロス・パターソン、およびハラルドAlvestrand。
11. References
11. 参照
11.1 Normative References
11.1 標準の参照
[1] Berners-Lee, T., Fielding, R. and H. Frystyk, "Hypertext
Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996.
[1]バーナーズ・リー、T.、フィールディング、R.、およびH.Frystyk、「HTTP/1インチ、RFC1945、1996年ハイパーテキスト転送プロトコル--5月。」
[2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource
Identifiers (URI) : Generic Syntax", RFC 2396, August 1998.
[2]バーナーズ・リー、T.、フィールディング、R.、およびL.Masinter、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirements
Levels", BCP 14, RFC 2119, March 1997.
[3] ブラドナー、S.、「Indicate Requirements LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999.
[4] フィールディング、R.、Gettys、J.、ムガール人、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ・リー、「HTTP/1.1インチ、RFC2616、1999年ハイパーテキスト転送プロトコル--6月。」
[5] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication:
Basic and Digest Access Authentication", RFC 2617, June 1999.
[5] フランクス、J.、ハラム-ベイカー、P.、Hostetler、J.、ローレンス、S.、リーチ、P.、Luotonen、A.、およびL.スチュワート、「HTTP認証:」 「基本的、そして、ダイジェストアクセス認証」、RFC2617、1999年6月。
Robinson & Coar Informational [Page 33] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[33ページ]情報のRFC3875CGIバージョン2004年10月1.1日
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
解放された[6]、N.、およびN.Borenstein、「マルチパーパスインターネットメールエクステンション(MIME)は2を分けます」。 「メディアタイプ」、RFC2046、1996年11月。
[7] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[7]Hinden、R.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[8] "HTTP Status Code Registry",
http://www.iana.org/assignments/http-status-codes, IANA.
[8] 「HTTPステータスコード登録」、 http://www.iana.org/assignments/http-status-codes 、IANA。
[9] "Information Systems -- Coded Character Sets -- 7-bit American
Standard Code for Information Interchange (7-Bit ASCII)", ANSI
INCITS.4-1986 (R2002).
[9] 「情報システム--コード化文字集合--7ビットの情報交換用米国標準コード(7ビットのASCII)」、ANSI INCITS.4-1986(R2002)。
[10] "Information technology -- 8-bit single-byte coded graphic
character sets -- Part 1: Latin alphabet No. 1", ISO/IEC
8859-1:1998.
[10]、「情報技術--8ビットの単一のバイトコード化された図形文字セット--第1部:、」 ローマ字No.1インチ、ISO/IEC8859-1: 1998。
11.2. Informative References
11.2. 有益な参照
[11] Berners-Lee, T., "Universal Resource Identifiers in WWW: A
Unifying Syntax for the Expression of Names and Addresses of
Objects on the Network as used in the World-Wide Web", RFC 1630,
June 1994.
[11] バーナーズ・リー、T.、「WWWの普遍的なリソース識別子:」 「WWWに使用されるNetworkの上のObjectsのNamesとAddressesのExpressionのためのUnifying Syntax」、RFC1630(1994年6月)
[12] Braden, R., Ed., "Requirements for Internet Hosts -- Application
and Support", STD 3, RFC 1123, October 1989.
[12] ブレーデン、R.、エド、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日
[13] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[13] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、1982年8月。
[14] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
2246, January 1999.
[14] Dierks、T.、およびC.アレン、「TLSは1999年1月にバージョン1インチ、RFC2246について議定書の中で述べます」。
[15] Hinden R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[15]Hinden R.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[16] Masinter, L., "Returning Values from Forms:
multipart/form-data", RFC 2388, August 1998.
[16]Masinter、L.、「帰りはフォームから以下を評価します」。 「複合/フォームデータ」、RFC2388、1998年8月。
[17] Mockapetris, P., "Domain Names - Concepts and Facilities", STD
13, RFC 1034, November 1987.
[17]Mockapetris、P.、「ドメイン名--、概念と施設、」、STD13、RFC1034、11月1987日
[18] Raggett, D., Le Hors, A., and I. Jacobs, Eds., "HTML 4.01
Specification", W3C Recommendation December 1999,
http://www.w3.org/TR/html401/.
[18]RaggettとD.とLe Hors、A.とI.ジェイコブズ、Eds、「HTML4.01仕様」、W3C推薦1999年12月、 http://www.w3.org/TR/html401/ 。
[19] Rescola, E. "HTTP Over TLS", RFC 2818, May 2000.
[19] Rescola(E. 「TLSの上のHTTP」、RFC2818)は2000がそうするかもしれません。
Robinson & Coar Informational [Page 34] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[34ページ]情報のRFC3875CGIバージョン2004年10月1.1日
[20] St. Johns, M., "Identification Protocol", RFC 1413, February
1993.
[20] 聖ジョーンズ、M.、「識別プロトコル」、RFC1413、1993年2月。
[21] IBM National Language Support Reference Manual Volume 2,
SE09-8002-01, March 1990.
[21] 第2IBM国語サポート参照マニュアル巻、SE09-8002-01、1990年3月。
[22] "The Common Gateway Interface",
http://hoohoo.ncsa.uiuc.edu/cgi/, NCSA, University of Illinois.
[22] 「共通ゲートウェイインターフェイス」、 http://hoohoo.ncsa.uiuc.edu/cgi/ 、NCSA、イリノイ大学。
12. Authors' Addresses
12. 作者のアドレス
David Robinson The Apache Software Foundation
デイビッド・ロビンソンアパッチソフトウェア財団
EMail: drtr@apache.org
メール: drtr@apache.org
Ken A. L. Coar The Apache Software Foundation
ケンA.L.Coarアパッチソフトウェア財団
EMail: coar@apache.org
メール: coar@apache.org
Robinson & Coar Informational [Page 35] RFC 3875 CGI Version 1.1 October 2004
ロビンソンとCoar[35ページ]情報のRFC3875CGIバージョン2004年10月1.1日
13. Full Copyright Statement
13. 完全な著作権宣言文
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org, and except as set forth therein, the authors retain all their rights.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78とwww.rfc-editor.orgに含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the ISOC's procedures with respect to rights in ISOC Documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でISOC Documentsの権利に関するISOCの手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Robinson & Coar Informational [Page 36]
ロビンソンとCoar情報です。[36ページ]
一覧
スポンサーリンク
