RFC1945 日本語訳
1945 Hypertext Transfer Protocol -- HTTP/1.0. T. Berners-Lee, R.Fielding, H. Frystyk. May 1996. (Format: TXT=137582 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group T. Berners-Lee
Request for Comments: 1945 MIT/LCS
Category: Informational R. Fielding
UC Irvine
H. Frystyk
MIT/LCS
May 1996
コメントを求めるワーキンググループT.バーナーズ・リー要求をネットワークでつないでください: 1945 MIT/LCSカテゴリ: 1996年5月にUCアーバインH.Frystyk MIT/LCSをさばく情報のR.
Hypertext Transfer Protocol -- HTTP/1.0
ハイパーテキスト転送プロトコル--HTTP/1.0
Status of This Memo
このメモの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
IESG Note:
IESGは以下に注意します。
The IESG has concerns about this protocol, and expects this document to be replaced relatively soon by a standards track document.
IESGは、このプロトコルに関する心配を持って、このドキュメントが比較的早く標準化過程ドキュメントに取り替えられると予想します。
Abstract
要約
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods (commands). A feature of HTTP is the typing of data representation, allowing systems to be built independently of the data being transferred.
ハイパーテキストTransferプロトコル(HTTP)は分配されて、協力的なハイパーメディアインフォメーションシステムに必要な軽さと速度があるアプリケーションレベルプロトコルです。それはジェネリックです、状態がないです、多くのタスクに使用できる、オブジェクト指向プロトコル、ネームサーバや分散オブジェクトマネージメントシステムのように、要求メソッド(コマンド)の拡大で。 HTTPの特徴によるデータ表現のタイプです、システムが移されるデータの如何にかかわらず構築されるのを許容して。
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred to as "HTTP/1.0".
1990年以来HTTPはWWWのグローバルな情報イニシアチブで使用中です。 この仕様は「HTTP/1インチ」と呼ばれたプロトコルの一般的な用法を反映します。
Table of Contents
目次
1. Introduction .............................................. 4
1.1 Purpose .............................................. 4
1.2 Terminology .......................................... 4
1.3 Overall Operation .................................... 6
1.4 HTTP and MIME ........................................ 8
2. Notational Conventions and Generic Grammar ................ 8
2.1 Augmented BNF ........................................ 8
2.2 Basic Rules .......................................... 10
3. Protocol Parameters ....................................... 12
1. 序論… 4 1.1目的… 4 1.2用語… 4 1.3 総合的な操作… 6 1.4 HTTPとMIME… 8 2. 記号法のコンベンションとジェネリック文法… 8 2.1はBNFを増大させました… 8 2.2 基本的な規則… 10 3. パラメタについて議定書の中で述べてください… 12
Berners-Lee, et al Informational [Page 1] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[1ページ]RFC1945HTTP/1996年5月1日
3.1 HTTP Version ......................................... 12
3.2 Uniform Resource Identifiers ......................... 14
3.2.1 General Syntax ................................ 14
3.2.2 http URL ...................................... 15
3.3 Date/Time Formats .................................... 15
3.4 Character Sets ....................................... 17
3.5 Content Codings ...................................... 18
3.6 Media Types .......................................... 19
3.6.1 Canonicalization and Text Defaults ............ 19
3.6.2 Multipart Types ............................... 20
3.7 Product Tokens ....................................... 20
4. HTTP Message .............................................. 21
4.1 Message Types ........................................ 21
4.2 Message Headers ...................................... 22
4.3 General Header Fields ................................ 23
5. Request ................................................... 23
5.1 Request-Line ......................................... 23
5.1.1 Method ........................................ 24
5.1.2 Request-URI ................................... 24
5.2 Request Header Fields ................................ 25
6. Response .................................................. 25
6.1 Status-Line .......................................... 26
6.1.1 Status Code and Reason Phrase ................. 26
6.2 Response Header Fields ............................... 28
7. Entity .................................................... 28
7.1 Entity Header Fields ................................. 29
7.2 Entity Body .......................................... 29
7.2.1 Type .......................................... 29
7.2.2 Length ........................................ 30
8. Method Definitions ........................................ 30
8.1 GET .................................................. 31
8.2 HEAD ................................................. 31
8.3 POST ................................................. 31
9. Status Code Definitions ................................... 32
9.1 Informational 1xx .................................... 32
9.2 Successful 2xx ....................................... 32
9.3 Redirection 3xx ...................................... 34
9.4 Client Error 4xx ..................................... 35
9.5 Server Error 5xx ..................................... 37
10. Header Field Definitions .................................. 37
10.1 Allow ............................................... 38
10.2 Authorization ....................................... 38
10.3 Content-Encoding .................................... 39
10.4 Content-Length ...................................... 39
10.5 Content-Type ........................................ 40
10.6 Date ................................................ 40
10.7 Expires ............................................. 41
10.8 From ................................................ 42
3.1 HTTPバージョン… 12 3.2のUniform Resource Identifier… 14 3.2 .1の一般構文… 14 3.2 .2http URL… 15 3.3 日付/時間形式… 15 3.4の文字コード… 17 3.5 満足しているコーディング… 18 3.6のメディアタイプ… 19 3.6 .1 Canonicalizationとテキストはデフォルトとします… 19 3.6 .2 複合タイプ… 20 3.7 製品トークン… 20 4. HTTPメッセージ… 21 4.1 メッセージタイプ… 21 4.2 メッセージヘッダー… 22 4.3 一般ヘッダーフィールド… 23 5. 要求します。 23 5.1 要求線… 23 5.1 .1メソッド… 24 5.1 .2要求URI… 24 5.2 ヘッダーフィールドを要求してください… 25 6. 応答… 25 6.1状況表示行… 26 6.1 .1のステータスコードと理由句… 26 6.2 応答ヘッダーフィールド… 28 7. 実体… 28 7.1 実体ヘッダーフィールド… 29 7.2実体本体… 29 7.2 .1 タイプしてください… 29 7.2 .2の長さ… 30 8. メソッド定義… 30 8.1 得ます。 31 8.2 向かってください… 31 8.3 ポスト… 31 9. ステータスコード定義… 32 9.1 情報の1xx… 32 9.2 うまくいっている2xx… 32 9.3リダイレクション3xx… 34 9.4 クライアント誤り4xx… 35 9.5 サーバ誤り5xx… 37 10. ヘッダーフィールド定義… 37 10.1 許容します。 38 10.2承認… 38 10.3 内容をコード化しています… 39 10.4 満足している長さ… 39 10.5コンテントタイプ… 40 10.6 デートしてください… 40 10.7 期限が切れます… 41 10.8、… 42
Berners-Lee, et al Informational [Page 2] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[2ページ]RFC1945HTTP/1996年5月1日
10.9 If-Modified-Since ................................... 42
10.10 Last-Modified ....................................... 43
10.11 Location ............................................ 44
10.12 Pragma .............................................. 44
10.13 Referer ............................................. 44
10.14 Server .............................................. 45
10.15 User-Agent .......................................... 46
10.16 WWW-Authenticate .................................... 46
11. Access Authentication ..................................... 47
11.1 Basic Authentication Scheme ......................... 48
12. Security Considerations ................................... 49
12.1 Authentication of Clients ........................... 49
12.2 Safe Methods ........................................ 49
12.3 Abuse of Server Log Information ..................... 50
12.4 Transfer of Sensitive Information ................... 50
12.5 Attacks Based On File and Path Names ................ 51
13. Acknowledgments ........................................... 51
14. References ................................................ 52
15. Authors' Addresses ........................................ 54
Appendix A. Internet Media Type message/http ................ 55
Appendix B. Tolerant Applications ........................... 55
Appendix C. Relationship to MIME ............................ 56
C.1 Conversion to Canonical Form ......................... 56
C.2 Conversion of Date Formats ........................... 57
C.3 Introduction of Content-Encoding ..................... 57
C.4 No Content-Transfer-Encoding ......................... 57
C.5 HTTP Header Fields in Multipart Body-Parts ........... 57
Appendix D. Additional Features ............................. 57
D.1 Additional Request Methods ........................... 58
D.1.1 PUT ........................................... 58
D.1.2 DELETE ........................................ 58
D.1.3 LINK .......................................... 58
D.1.4 UNLINK ........................................ 58
D.2 Additional Header Field Definitions .................. 58
D.2.1 Accept ........................................ 58
D.2.2 Accept-Charset ................................ 59
D.2.3 Accept-Encoding ............................... 59
D.2.4 Accept-Language ............................... 59
D.2.5 Content-Language .............................. 59
D.2.6 Link .......................................... 59
D.2.7 MIME-Version .................................. 59
D.2.8 Retry-After ................................... 60
D.2.9 Title ......................................... 60
D.2.10 URI ........................................... 60
10.9 以来変更されるなら… 42 10.10 最後、変更される… 43 10.11位置… 44 10.12Pragma… 44 10.13Referer… 44 10.14サーバ… 45 10.15ユーザエージェント… 46 10.16 …をWWW認証してください… 46 11. 認証にアクセスしてください… 47 11.1基本認証体系… 48 12. セキュリティ問題… 49 12.1 クライアントの認証… 49 12.2 安全なメソッド… サーバログ情報の49 12.3乱用… 50 12.4 機密情報の転送… 50 12.5の攻撃がファイルとパス名を基礎づけました… 51 13. 承認… 51 14. 参照… 52 15. 作者のアドレス… 54 付録A.インターネットメディアTypeメッセージ/http… 55 付録のB.の許容性があるアプリケーション… 55 まねる付録C.関係… 56 標準形へのC.1変換… 56 日付の形式のC.2変換… 内容をコード化していることの57C.3導入… 57 C.4のいいえの満足している転送コード化… 57 複合身体部分のC.5HTTPヘッダ分野… 57 付録D.付加的な機能… 57 D.1の追加要求メソッド… 置かれた58D.1.1… D.1.2が削除する58… 58 D.1.3はリンクします… 58 D.1.4は離れます… 58 D.2の追加ヘッダーフィールド定義… 58 D.2.1は受け入れます… 58D.2.2、Charsetを受け入れます… 59D.2.3、コード化を受け入れます… 59D.2.4、言語を受け入れます… 59 D.2.5の満足している言語… 59 D.2.6はリンクします… 59 D.2.7MIMEバージョン… 59 D.2.8は-後に再試行します… 60 D.2.9タイトル… 60 D.2.10ユリ… 60
Berners-Lee, et al Informational [Page 3] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[3ページ]RFC1945HTTP/1996年5月1日
1. Introduction
1. 序論
1.1 Purpose
1.1 目的
The Hypertext Transfer Protocol (HTTP) is an application-level protocol with the lightness and speed necessary for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification reflects common usage of the protocol referred too as "HTTP/1.0". This specification describes the features that seem to be consistently implemented in most HTTP/1.0 clients and servers. The specification is split into two sections. Those features of HTTP for which implementations are usually consistent are described in the main body of this document. Those features which have few or inconsistent implementations are listed in Appendix D.
ハイパーテキストTransferプロトコル(HTTP)は分配されて、協力的なハイパーメディアインフォメーションシステムに必要な軽さと速度があるアプリケーションレベルプロトコルです。1990年以来HTTPはWWWのグローバルな情報イニシアチブで使用中です。 この仕様はまた、「HTTP/1インチ」として参照されたプロトコルの一般的な用法を反映します。 この仕様はほとんどのHTTP/1.0人のクライアントとサーバで一貫して実装されるように思える特徴について説明します。 仕様は2つのセクションに分けられます。 通常、実装が一貫しているHTTPのそれらの特徴はこのドキュメントの本体で説明されます。 わずかであるか矛盾した実装を持っているそれらの特徴がAppendix Dにリストアップされています。
Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. HTTP allows an open-ended set of methods to be used to indicate the purpose of a request. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) [2], as a location (URL) [4] or name (URN) [16], for indicating the resource on which a method is to be applied. Messages are passed in a format similar to that used by Internet Mail [7] and the Multipurpose Internet Mail Extensions (MIME) [5].
実用的な情報システムは検索、フロントエンドアップデート、および注釈を含む簡単な検索より多くの機能性を必要とします。 HTTPは要求の目的を示すのに使用されるべき制限のないメソッドを許容します。 それはUniform Resource Identifier(URI)[2]によって提供された参照の規律に建てられます、位置の(URL)[4]か名前(URN)[16]として、適用されているメソッドがことであるリソースを示すために。 メッセージはインターネットメール[7]とマルチパーパスインターネットメールエクステンション(MIME)[5]によって使用されるそれと同様の形式で通過されます。
HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet protocols, such as SMTP [12], NNTP [11], FTP [14], Gopher [1], and WAIS [8], allowing basic hypermedia access to resources available from diverse applications and simplifying the implementation of user agents.
また、HTTPはユーザエージェントとプロキシ/ゲートウェイとの他のインターネットプロトコルへのコミュニケーションにジェネリックプロトコルとして使用されます、SMTP[12]や、NNTP[11]や、FTP[14]や、ゴーファー[1]や、WAIS[8]などのように、さまざまのアプリケーションによって利用可能なリソースへの基本的なハイパーメディアアクセスを許して、ユーザエージェントの実装を簡素化して。
1.2 Terminology
1.2 用語
This specification uses a number of terms to refer to the roles played by participants in, and objects of, the HTTP communication.
この仕様は、HTTPコミュニケーションについて関係者によって果たされた役割について言及して、反対するのに項数を使用します。
connection
接続
A transport layer virtual circuit established between two
application programs for the purpose of communication.
トランスポート層の仮想の回路は2の間でコミュニケーションの目的のためのアプリケーション・プログラムを確立しました。
message
メッセージ
The basic unit of HTTP communication, consisting of a structured
sequence of octets matching the syntax defined in Section 4 and
transmitted via the connection.
HTTPコミュニケーションの原単位、構文に合っている八重奏の構造化された系列から成るのは、接続をセクション4で定義して、伝わりました。
Berners-Lee, et al Informational [Page 4] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[4ページ]RFC1945HTTP/1996年5月1日
request
要求
An HTTP request message (as defined in Section 5).
HTTP要求メッセージ(セクション5で定義されるように)。
response
応答
An HTTP response message (as defined in Section 6).
HTTP応答メッセージ(セクション6で定義されるように)。
resource
リソース
A network data object or service which can be identified by a
URI (Section 3.2).
URI(セクション3.2)で特定できるネットワークデータ・オブジェクトかサービス。
entity
実体
A particular representation or rendition of a data resource, or
reply from a service resource, that may be enclosed within a
request or response message. An entity consists of
metainformation in the form of entity headers and content in the
form of an entity body.
要求か応答メッセージの中に同封されるかもしれないデータリソースの特定の表現か表現、またはサービスリソースからの回答。 実体は実体本体の形で実体ヘッダーと内容の形でmetainformationから成ります。
client
クライアント
An application program that establishes connections for the
purpose of sending requests.
要求を送る目的のために関係を樹立するアプリケーション・プログラム。
user agent
ユーザエージェント
The client which initiates a request. These are often browsers,
editors, spiders (web-traversing robots), or other end user
tools.
要求を開始するクライアント。 これらは、しばしばブラウザ、エディタ、クモ(ウェブを横断するロボット)、または他のエンドユーザツールです。
server
サーバ
An application program that accepts connections in order to
service requests by sending back responses.
応答を返送することによって要求を修理するために接続を受け入れるアプリケーション・プログラム。
origin server
発生源サーバ
The server on which a given resource resides or is to be created.
住んでいるか、または作成される与えられたリソースがことであるサーバ。
proxy
プロキシ
An intermediary program which acts as both a server and a client
for the purpose of making requests on behalf of other clients.
Requests are serviced internally or by passing them, with
possible translation, on to other servers. A proxy must
interpret and, if necessary, rewrite a request message before
他のクライアントを代表して要求をする目的のためのサーバとクライアントの両方として作動する仲介者プログラム。 要求は、内部的か可能な翻訳で他のサーバにそれらを通過することによって、修理されます。 プロキシは、解釈して、必要なら、以前、要求メッセージを書き直さなければなりません。
Berners-Lee, et al Informational [Page 5] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[5ページ]RFC1945HTTP/1996年5月1日
forwarding it. Proxies are often used as client-side portals
through network firewalls and as helper applications for
handling requests via protocols not implemented by the user
agent.
それを進めます。 プロキシはネットワークファイアウォールを通したクライアントサイド入り口として取り扱い要求のためのユーザエージェントによって実装されなかったプロトコルを通した支援アプリケーションとしてしばしば使用されます。
gateway
ゲートウェイ
A server which acts as an intermediary for some other server.
Unlike a proxy, a gateway receives requests as if it were the
origin server for the requested resource; the requesting client
may not be aware that it is communicating with a gateway.
Gateways are often used as server-side portals through network
firewalls and as protocol translators for access to resources
stored on non-HTTP systems.
どれがある他のサーバのための仲介者として機能しますか?サーバ、aプロキシと異なって、ゲートウェイはまるでそれが要求されたリソースのための発生源サーバであるかのように要求を受け取ります。 要求しているクライアントはそれがゲートウェイで交信する予定であるのを意識していないかもしれません。 ゲートウェイはネットワークファイアウォールを通したサーバサイド入り口として非HTTPシステムの上に保存されたリソースへのアクセスのためのプロトコル翻訳者としてしばしば使用されます。
tunnel
トンネル
A tunnel is an intermediary program which is acting as a blind
relay between two connections. Once active, a tunnel is not
considered a party to the HTTP communication, though the tunnel
may have been initiated by an HTTP request. The tunnel ceases to
exist when both ends of the relayed connections are closed.
Tunnels are used when a portal is necessary and the intermediary
cannot, or should not, interpret the relayed communication.
トンネルはブラインドが2の間で接続をリレーするとき作動している仲介者プログラムです。 一度アクティブです、トンネルはHTTPコミュニケーションへのパーティーであると考えられません、トンネルはHTTP要求で開始されたかもしれませんが。 トンネルは、リレーされた接続の両端が閉じられるとき、存在するのをやめます。 または、入り口が必要であるときに、トンネルが使用されていて、仲介者が使用できない、リレーされたコミュニケーションを解釈するべきであってください。
cache
キャッシュ
A program's local store of response messages and the subsystem
that controls its message storage, retrieval, and deletion. A
cache stores cachable responses in order to reduce the response
time and network bandwidth consumption on future, equivalent
requests. Any client or server may include a cache, though a
cache cannot be used by a server while it is acting as a tunnel.
メッセージストレージ、検索、および削除を制御するプログラムの応答メッセージとサブシステムの地元の小売店。 キャッシュは、将来的で、同等な要求における応答時間とネットワーク回線容量消費を短縮するためにキャッシュ可能応答を保存します。 どんなクライアントやサーバもキャッシュを入れるかもしれません、トンネルとして機能している間サーバでキャッシュを使用できませんが。
Any given program may be capable of being both a client and a server; our use of these terms refers only to the role being performed by the program for a particular connection, rather than to the program's capabilities in general. Likewise, any server may act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
どんな与えられたプログラムもクライアントとサーバの両方であることができるかもしれません。 私たちのこれらの用語の使用は一般に、プログラムの能力にというよりむしろ特定の接続のためのプログラムで実行される役割だけについて言及します。 同様に、どんなサーバも発生源サーバ、プロキシ、ゲートウェイ、またはトンネルとして務めるかもしれません、それぞれの要求の本質に基づく振舞いを切り換えて。
1.3 Overall Operation
1.3 総合的な操作
The HTTP protocol is based on a request/response paradigm. A client establishes a connection with a server and sends a request to the server in the form of a request method, URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible body content. The server responds with a
HTTPプロトコルは要求/応答パラダイムに基づいています。 クライアントは、要求修飾語、クライアント情報、および可能なボディー内容を含むMIMEのようなメッセージがあとに続いた要求メソッド、URI、およびプロトコルバージョンの形でサーバで取引関係を築いて、要求をサーバに送ります。 サーバはaで反応します。
Berners-Lee, et al Informational [Page 6] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[6ページ]RFC1945HTTP/1996年5月1日
status line, including the message's protocol version and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible body content.
メッセージのプロトコルバージョンと成功かエラーコードを含む状況表示行がサーバ情報、実体metainformation、および可能なボディー内容を含むMIMEのようなメッセージで従いました。
Most HTTP communication is initiated by a user agent and consists of a request to be applied to a resource on some origin server. In the simplest case, this may be accomplished via a single connection (v) between the user agent (UA) and the origin server (O).
ほとんどのHTTPコミュニケーションが、ユーザエージェントによって開始されて、何らかの発生源サーバでリソースに適用されるという要求から成ります。最も簡単な場合では、これはユーザエージェント(UA)と発生源サーバ(O)の間の単独結合(v)で達成されるかもしれません。
request chain ------------------------>
UA -------------------v------------------- O
<----------------------- response chain
チェーンを要求してください。------------------------>Ua-------------------v------------------- ○ <。----------------------- 応答チェーン
A more complicated situation occurs when one or more intermediaries are present in the request/response chain. There are three common forms of intermediary: proxy, gateway, and tunnel. A proxy is a forwarding agent, receiving requests for a URI in its absolute form, rewriting all or parts of the message, and forwarding the reformatted request toward the server identified by the URI. A gateway is a receiving agent, acting as a layer above some other server(s) and, if necessary, translating the requests to the underlying server's protocol. A tunnel acts as a relay point between two connections without changing the messages; tunnels are used when the communication needs to pass through an intermediary (such as a firewall) even when the intermediary cannot understand the contents of the messages.
1人以上の仲介者が要求/応答チェーンで出席しているとき、より複雑な状況は起こります。 仲介者の3つの一般的なフォームがあります: プロキシ、ゲートウェイ、およびトンネル。 プロキシは小口運送業者です、絶対フォームにURIを求める要求を受け取って、すべてかメッセージの部分を書き直して、URIによって特定されたサーバに向かって再フォーマットされた要求を転送して。 ゲートウェイは受信エージェントです、層としてある他のサーバを超えて機能して、必要なら、基本的なサーバのプロトコルに要求を翻訳して。 メッセージを変えないで、トンネルは2つの接続の間のリレーポイントとして作動します。 仲介者がメッセージのコンテンツを理解できないならコミュニケーションが、仲介者(ファイアウォールなどの)を通り抜ける必要があるとき、トンネルは使用されています。
request chain -------------------------------------->
UA -----v----- A -----v----- B -----v----- C -----v----- O
<------------------------------------- response chain
チェーンを要求してください。-------------------------------------->Ua-----v----- A-----v----- B-----v----- C-----v----- ○ <。------------------------------------- 応答チェーン
The figure above shows three intermediaries (A, B, and C) between the user agent and origin server. A request or response message that travels the whole chain must pass through four separate connections. This distinction is important because some HTTP communication options may apply only to the connection with the nearest, non-tunnel neighbor, only to the end-points of the chain, or to all connections along the chain. Although the diagram is linear, each participant may be engaged in multiple, simultaneous communications. For example, B may be receiving requests from many clients other than A, and/or forwarding requests to servers other than C, at the same time that it is handling A's request.
上の図形はユーザエージェントと発生源サーバの間に(A、B、およびC)を3人の仲介者に示しています。全体のチェーンを旅行する要求か応答メッセージが4つの別々の接続を通り抜けなければなりません。 いくつかのHTTPコミュニケーションオプションが最も近くて、非トンネルの隣人との接続だけ、または、チェーンのエンドポイント、または、チェーンに沿ったすべての接続だけに適用されるかもしれないので、この区別は重要です。 ダイヤグラムは直線的ですが、各関係者は複数の、そして、同時のコミュニケーションに従事するかもしれません。 例えば、BはA以外の多くのクライアント、そして/または、推進要求からCを除いたサーバまでの要求を受け取っているかもしれません、それが取り扱いのA要求であるのと同時に。
Any party to the communication which is not acting as a tunnel may employ an internal cache for handling requests. The effect of a cache is that the request/response chain is shortened if one of the participants along the chain has a cached response applicable to that request. The following illustrates the resulting chain if B has a
トンネルとして機能していないコミュニケーションへのどんなパーティーも取り扱い要求のための内部キャッシュを使うかもしれません。 キャッシュの効果はキャッシュされた応答がチェーンに沿った関係者のひとりでその要求に適切になるなら要求/応答チェーンが短くされるということです。 Bにaがあるなら、以下は結果として起こるチェーンを例証します。
Berners-Lee, et al Informational [Page 7] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[7ページ]RFC1945HTTP/1996年5月1日
cached copy of an earlier response from O (via C) for a request which has not been cached by UA or A.
UAかAによってキャッシュされていない要求のためのO(Cを通した)から以前の応答のコピーをキャッシュしました。
request chain ---------->
UA -----v----- A -----v----- B - - - - - - C - - - - - - O
<--------- response chain
チェーンを要求してください。---------->Ua-----v----- A-----v----- B--、--、--、--、--、--C----、--、--、--、--、○ <。--------- 応答チェーン
Not all responses are cachable, and some requests may contain modifiers which place special requirements on cache behavior. Some HTTP/1.0 applications use heuristics to describe what is or is not a "cachable" response, but these rules are not standardized.
すべての応答がどんなキャッシュ可能であるというわけではありません、そして、いくつかの要求がキャッシュの振舞いに特別な要件を置く修飾語を含むかもしれません。 いくつかのHTTP/1.0のアプリケーションがあるか、"キャッシュ可能"応答でないことについて説明するのに発見的教授法を使用しますが、これらの規則は標準化されません。
On the Internet, HTTP communication generally takes place over TCP/IP connections. The default port is TCP 80 [15], but other ports can be used. This does not preclude HTTP from being implemented on top of any other protocol on the Internet, or on other networks. HTTP only presumes a reliable transport; any protocol that provides such guarantees can be used, and the mapping of the HTTP/1.0 request and response structures onto the transport data units of the protocol in question is outside the scope of this specification.
一般に、インターネットでは、HTTPコミュニケーションはTCP/IP接続の上で行われます。 デフォルトポートはTCP80[15]ですが、他のポートを使用できます。 これは、インターネットの上、または、他のネットワークの上のいかなる他のプロトコルの上でも実装されるので、HTTPを排除しません。 HTTPは信頼できる輸送を推定するだけです。 そのような保証を提供するどんなプロトコルも使用できます、そして、この仕様の範囲の外に問題のプロトコルの輸送データ単位へのHTTP/1.0要求と応答構造に関するマッピングがあります。
Except for experimental applications, current practice requires that the connection be established by the client prior to each request and closed by the server after sending the response. Both clients and servers should be aware that either party may close the connection prematurely, due to user action, automated time-out, or program failure, and should handle such closing in a predictable fashion. In any case, the closing of the connection by either or both parties always terminates the current request, regardless of its status.
実験用アプリケーションを除いて、現在の習慣は、接続が各要求の前にクライアントによって確立されて、応答を送った後にサーバによって閉店させられるのを必要とします。 クライアントとサーバの両方が何れの当事者が早まってユーザ動作、自動化されたタイムアウト、またはプログラム障害のため接続を終えるかもしれなくて、予測できるファッションで閉じながらそのようなものを扱うべきであるのを意識しているべきです。 どのような場合でも、どちらかか双方による接続の閉鎖はいつも現在の要求を終えます、状態にかかわらず。
1.4 HTTP and MIME
1.4 HTTPとMIME
HTTP/1.0 uses many of the constructs defined for MIME, as defined in RFC 1521 [5]. Appendix C describes the ways in which the context of HTTP allows for different use of Internet Media Types than is typically found in Internet mail, and gives the rationale for those differences.
HTTP/1.0はMIMEのためにRFC1521[5]で定義されるように定義された構造物の多くを使用します。 付録CはHTTPの文脈がインターネットメディアTypesのインターネット・メールで通常見つけられて、それらの違いのために原理を与えるのと異なった使用を考慮する方法を述べます。
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 [7]. Implementors will need to be familiar with the notation in order to understand this specification. The augmented BNF includes the following constructs:
本書では指定されたメカニズムのすべてが散文とRFC822[7]によって使用されるそれと同様の増大しているバッカス記法(BNF)の両方で説明されます。 作成者は、この仕様を理解するために記法によく知られる必要があるでしょう。 増大しているBNFは以下の構造物を含んでいます:
Berners-Lee, et al Informational [Page 8] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[8ページ]RFC1945HTTP/1996年5月1日
name = definition
名前=定義
The name of a rule is simply the name itself (without any
enclosing "<" and ">") and is separated from its definition by
the equal character "=". Whitespace is only significant in that
indentation of continuation lines is used to indicate a rule
definition that spans more than one line. Certain basic rules
are in uppercase, such as SP, LWS, HT, CRLF, DIGIT, ALPHA, etc.
Angle brackets are used within definitions whenever their
presence will facilitate discerning the use of rule names.
規則の名前は、単に名前(いずれも"<"と">"を同封することのない)自体であり、等しいキャラクタ「=」によって定義と切り離されます。 継続行の刻み目が1つ以上の系列にかかる規則定義を示すのに使用されるので、空白は重要であるだけです。 SPなどの大文字、LWS、HT、CRLF、DIGIT、アルファーなどには、ある基本的なルールがあります。 それらの存在が、規則名の使用について明察するのを容易にするときはいつも、角ブラケットは定義の中で使用されます。
"literal"
「リテラル」
Quotation marks surround literal text. Unless stated otherwise,
the text is case-insensitive.
引用符は文字通りのテキストを囲んでいます。 別の方法で述べられない場合、テキストは大文字と小文字を区別しないです。
rule1 | rule2
rule1| rule2
Elements separated by a bar ("I") are alternatives,
e.g., "yes | no" will accept yes or no.
バー(「私」)によって切り離された要素は代替手段、例えば、「はい」です。| 「いいえ」は諾否を受け入れるでしょう。
(rule1 rule2)
(rule1 rule2)
Elements enclosed in parentheses are treated as a single
element. Thus, "(elem (foo | bar) elem)" allows the token
sequences "elem foo elem" and "elem bar elem".
括弧に同封された要素はただ一つの要素として扱われます。 したがって、「(elem(foo| バー)elem)」はトークン系列"elem foo elem"と「elemバーelem」を許容します。
*rule
*規則
The character "*" preceding an element indicates repetition. The
full form is "<n>*<m>element" indicating at least <n> and at
most <m> occurrences of element. Default values are 0 and
infinity so that "*(element)" allows any number, including zero;
"1*element" requires at least one; and "1*2element" allows one
or two.
要素に先行するキャラクタ「*」は反復を示します。 完全形は要素の少なくとも<n>と高々<m>を示す「<n>*<m>要素」発生です。 「デフォルト値が0であり、無限がそう、それ、」 *、(要素) 」 ゼロを含むどんな数も許容します。 「1*要素」は少なくとも1を必要とします。 そして、「1*2element」は1か2を許容します。
[rule]
[規則]
Square brackets enclose optional elements; "[foo bar]" is
equivalent to "*1(foo bar)".
角括弧は随意的な要素を同封します。 「「[fooバー]」は」 *1(fooバー)に同等です。」
N rule
N規則
Specific repetition: "<n>(element)" is equivalent to
"<n>*<n>(element)"; that is, exactly <n> occurrences of
(element). Thus 2DIGIT is a 2-digit number, and 3ALPHA is a
string of three alphabetic characters.
特定の反復: 「<n>(要素)」は「<n>*<n>(要素)」に同等です。 すなわち、まさに(要素)の<n>発生。 したがって、2DIGITは2桁数です、そして、3ALPHAは一連の3つの英字です。
Berners-Lee, et al Informational [Page 9] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[9ページ]RFC1945HTTP/1996年5月1日
#rule
#規則
A construct "#" is defined, similar to "*", for defining lists
of elements. The full form is "<n>#<m>element" indicating at
least <n> and at most <m> elements, each separated by one or
more commas (",") and optional linear whitespace (LWS). This
makes the usual form of lists very easy; a rule such as
"( *LWS element *( *LWS "," *LWS element ))" can be shown as
"1#element". Wherever this construct is used, null elements are
allowed, but do not contribute to the count of elements present.
That is, "(element), , (element)" is permitted, but counts as
only two elements. Therefore, where at least one element is
required, at least one non-null element must be present. Default
values are 0 and infinity so that "#(element)" allows any
number, including zero; "1#element" requires at least one; and
"1#2element" allows one or two.
構造物「#」は、要素のリストを定義するための「*」と定義されていて、同様です。 完全形は少なくとも<n>と高々<m>を示す「<n>#<m>要素」要素です、1つ以上のコンマによって切り離されたそれぞれ、(「」、)、そして、任意の直線的な空白(LWS)。 これで、普通の形式のリストは非常に簡単になります。 「aが統治する、「(*LWS要素*、(*LWS、」、」、*LWS要素) 」 「1#要素」として示すことができます。 この構造物が中古であって、どこでも、ヌルであるところでは、要素が許容されていますが、要素の現在のカウントに貢献しないでください。 すなわち、「(要素)、(要素) 」 受入れられますが、2つの要素だけにみなします。 したがって、少なくとも1つの要素が必要であるところでは、少なくとも1つの非ヌル要素が存在していなければなりません。 「デフォルト値が0であり、無限がそう、それ、」 #、(要素) 」 ゼロを含むどんな数も許容します。 「1#要素」は少なくとも1を必要とします。 そして、「1#2element」は1か2を許容します。
; comment
; コメント
A semi-colon, set off some distance to the right of rule text,
starts a comment that continues to the end of line. This is a
simple way of including useful notes in parallel with the
specifications.
規則テキストの右への何らかの距離に引きたったセミコロンは行末に続くコメントを始めます。 これは仕様と平行して役に立つ注意を含む簡単な方法です。
implied *LWS
暗示している*LWS
The grammar described by this specification is word-based.
Except where noted otherwise, linear whitespace (LWS) can be
included between any two adjacent words (token or
quoted-string), and between adjacent tokens and delimiters
(tspecials), without changing the interpretation of a field. At
least one delimiter (tspecials) must exist between any two
tokens, since they would otherwise be interpreted as a single
token. However, applications should attempt to follow "common
form" when generating HTTP constructs, since there exist some
implementations that fail to accept anything beyond the common
forms.
この仕様で説明された文法は単語ベースです。 別の方法で注意されるのを除いて、どんな2つの続いている語(トークンか引用文字列)の間とも、そして、隣接しているトークンとデリミタ(tspecials)の間に直線的な空白(LWS)を含むことができます、分野の解釈を変えないで。 少なくとも1つのデリミタ(tspecials)がどんな2つのトークンの間にも存在しなければなりません、そうでなければ、それらはただ一つのトークンとして解釈されるでしょう、したがって。 しかしながら、アプリケーションは、HTTPが構造物であると生成するとき、「一般的なフォーム」に続くのを試みるべきです、何も一般的なフォームを超えたところまで受け入れないいくつかの実装が存在しているので。
2.2 Basic Rules
2.2 基本的な規則
The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by [17].
以下の規則は、基本的な構文解析構造物について説明するのにこの仕様中で使用されます。 米国-ASCIIコード化文字集合は[17]によって定義されます。
OCTET = <any 8-bit sequence of data>
CHAR = <any US-ASCII character (octets 0 - 127)>
UPALPHA = <any US-ASCII uppercase letter "A".."Z">
LOALPHA = <any US-ASCII lowercase letter "a".."z">
データ>CHAR=<において、どんな米国-ASCII文字(八重奏0--127)>UPALPHAも<と等しいです。「OCTETがどんな8ビットも配列する<と等しい、どんな米国-ASCII大文字「A」。」Z、「>LOALPHAがどんな米国-ASCIIも小文字で印刷する<と等しい、手紙“a"、」z">"
Berners-Lee, et al Informational [Page 10] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[10ページ]RFC1945HTTP/1996年5月1日
ALPHA = UPALPHA | LOALPHA
DIGIT = <any US-ASCII digit "0".."9">
CTL = <any US-ASCII control character
(octets 0 - 31) and DEL (127)>
CR = <US-ASCII CR, carriage return (13)>
LF = <US-ASCII LF, linefeed (10)>
SP = <US-ASCII SP, space (32)>
HT = <US-ASCII HT, horizontal-tab (9)>
<"> = <US-ASCII double-quote mark (34)>
アルファーはUPALPHAと等しいです。| LOALPHA DIGITは<とどんな米国-ASCIIケタ「0インチ」等しいです。9インチの>CTLが<と等しい、どんな米国-ASCII制御文字(八重奏0--31)とデル(127)>CR=<米国-ASCII CR、復帰(13)>LF=<米国-ASCII LF、ラインフィード(10)>SP=<米国-ASCII SP、<米国-ASCII HT、水平タブ(9)><「>の=<米国-ASCIIの二重引用符」とスペース(32)>HTは等しいです。(34)>。
HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker for all protocol elements except the Entity-Body (see Appendix B for tolerant applications). The end-of-line marker within an Entity-Body is defined by its associated media type, as described in Section 3.6.
HTTP/1.0はEntity-ボディー以外のすべてのプロトコル要素のための行末マーカーと八重奏系列CR LFを定義します(許容性があるアプリケーションに関してAppendix Bを見てください)。 Entity-ボディーの中の行末マーカーはセクション3.6で説明されるように関連メディアタイプによって定義されます。
CRLF = CR LF
CRLFはCR LFと等しいです。
HTTP/1.0 headers may be folded onto multiple lines if each continuation line begins with a space or horizontal tab. All linear whitespace, including folding, has the same semantics as SP.
各継続行がスペースか水平タブで始まるなら、HTTP/1.0個のヘッダーが複数の系列に折り重ねられるかもしれません。 折り重なるのを含むすべての直線的な空白がSPと同じ意味論を持っています。
LWS = [CRLF] 1*( SP | HT )
LWSは[CRLF]1*と等しいです。(SP| HT)
However, folding of header lines is not expected by some applications, and should not be generated by HTTP/1.0 applications.
しかしながら、ヘッダー系列の折り重なりをいくつかのアプリケーションで予想しないで、HTTP/1.0のアプリケーションで生成するべきではありません。
The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT may contain octets from character sets other than US-ASCII.
TEXT規則は描写的である分野コンテンツとメッセージパーサによって解釈されることを意図しない値に使用されるだけです。 *TEXTのワーズは米国-ASCIIを除いた文字集合からの八重奏を含むかもしれません。
TEXT = <any OCTET except CTLs,
but including LWS>
TEXT=<はCTLsの、しかし、含んでいるLWS>以外のあらゆるOCTETです。
Recipients of header field TEXT containing octets outside the US- ASCII character set may assume that they represent ISO-8859-1 characters.
米国ASCII文字の組の外に八重奏を含むヘッダー分野TEXTの受取人は、ISO-8859-1キャラクタの代理をすると仮定するかもしれません。
Hexadecimal numeric characters are used in several protocol elements.
16進数字は数個のプロトコル要素で使用されます。
HEX = "A" | "B" | "C" | "D" | "E" | "F"
| "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
十六進法=「A」| 「B」| 「C」| 「D」| 「E」| 「F」| "a"| 「b」| 「c」| 「d」| 「e」| 「f」| ケタ
Many HTTP/1.0 header field values consist of words separated by LWS or special characters. These special characters must be in a quoted string to be used within a parameter value.
多くのHTTP/1.0のヘッダーフィールド値がLWSか特殊文字によって切り離された単語から成ります。 パラメタ値の中で使用されるために、これらの特殊文字が引用文字列にあるに違いありません。
word = token | quoted-string
単語=トークン| 引用文字列
Berners-Lee, et al Informational [Page 11] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[11ページ]RFC1945HTTP/1996年5月1日
token = 1*<any CHAR except CTLs or tspecials>
トークン=1*<はCTLsかtspecials>以外のあらゆるCHARです。
tspecials = "(" | ")" | "<" | ">" | "@"
| "," | ";" | ":" | "\" | <">
| "/" | "[" | "]" | "?" | "="
| "{" | "}" | SP | HT
tspecialsが等しい、「(「|」、)、」| "<"| ">"| "@" | "," | ";" | ":" | "\" | <">"| "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP| HT
Comments may be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part of the field value.
コメントは、いくつかのHTTPヘッダ分野にコメントテキストを括弧に取り巻くことによって、含まれるかもしれません。 コメントは彼らの分野値の定義の一部として「コメント」を含む分野に許容されているだけです。 他のすべての分野では、括弧が分野価値の一部であると考えられます。
comment = "(" *( ctext | comment ) ")"
ctext = <any TEXT excluding "(" and ")">
そして、「(「*(ctext| コメント)」)」というコメント=ctextが<と等しい、どんなテキスト除外、も「(「」、)、">"
A string of text is parsed as a single word if it is quoted using double-quote marks.
それが二重引用符を使用することで引用されるなら、テキストの五弦は一語として分析されます。
quoted-string = ( <"> *(qdtext) <"> )
引用文字列=(<、「>*(qdtext)<、「>)」
qdtext = <any CHAR except <"> and CTLs,
but including LWS>
qdtextがどんなCHARも除く<と等しい、<、「>とCTLs、しかし、LWS>を含んでいること」。
Single-character quoting using the backslash ("\") character is not
permitted in HTTP/1.0.
バックスラッシュ(「\」)キャラクタを使用する単独のキャラクタ引用がHTTP/1.0で受入れられません。
3. Protocol Parameters
3. プロトコルパラメタ
3.1 HTTP Version
3.1 HTTPバージョン
HTTP uses a "<major>.<minor>" numbering scheme to indicate versions of the protocol. The protocol versioning policy is intended to allow the sender to indicate the format of a message and its capacity for understanding further HTTP communication, rather than the features obtained via that communication. No change is made to the version number for the addition of message components which do not affect communication behavior or which only add to extensible field values. The <minor> number is incremented when the changes made to the protocol add features which do not change the general message parsing algorithm, but which may add to the message semantics and imply additional capabilities of the sender. The <major> number is incremented when the format of a message within the protocol is changed.
HTTPは、プロトコルのバージョンを示すのに「<の主要な><の小さい方の>」ナンバリングスキームを使用します。 プロトコルversioning方針が、送付者がそのコミュニケーションで得られた特徴よりむしろさらなるHTTPコミュニケーションを理解するためにメッセージとその容量の書式を示すのを許容することを意図します。 変更を全くコミュニケーション行動に影響しないか、または広げることができる分野値に加えるだけであるメッセージコンポーネントの追加のバージョン番号にしません。 プロトコルにされた変更が一般的なメッセージ構文解析アルゴリズムを変えませんが、メッセージ意味論に加えて、送付者の追加能力を含意するかもしれない特徴を加えると、<の小さい方の>番号は増加されています。 プロトコルの中のメッセージの形式を変えるとき、<の主要な>番号は増加しています。
The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. If the protocol version is not specified, the recipient must assume that the message is in the
HTTPメッセージのバージョンはメッセージの最初の系列におけるHTTPバージョン分野によって示されます。 プロトコルバージョンが指定されないなら、受取人は、中にメッセージがあると仮定しなければなりません。
Berners-Lee, et al Informational [Page 12] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[12ページ]RFC1945HTTP/1996年5月1日
simple HTTP/0.9 format.
簡単なHTTP/0.9形式。
HTTP-Version = "HTTP" "/" 1*DIGIT "." 1*DIGIT
「HTTPバージョン=「HTTP」」/、」 1*ケタ、」、」 1*ケタ
Note that the major and minor numbers should be treated as separate integers and that each may be incremented higher than a single digit. Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is lower than HTTP/12.3. Leading zeros should be ignored by recipients and never generated by senders.
主要で小さい方の数が別々の整数として扱われるべきであり、それぞれが一桁より高く増加されるかもしれないことに注意してください。 したがって、HTTP/2.4は順番に低いHTTP/2.13より低いHTTP/12.3よりバージョンです。 先行ゼロは、受取人によって無視されて、送付者によって決して生成されるべきではありません。
This document defines both the 0.9 and 1.0 versions of the HTTP protocol. Applications sending Full-Request or Full-Response messages, as defined by this specification, must include an HTTP- Version of "HTTP/1.0".
このドキュメントはHTTPプロトコルの両方の0.9と1.0のバージョンを定義します。 この仕様で定義されるようにFull-要求かFull-応答メッセージを送るアプリケーションは「HTTP/1インチ」のHTTPバージョンを含まなければなりません。
HTTP/1.0 servers must:
HTTP/1.0のサーバはそうしなければなりません:
o recognize the format of the Request-Line for HTTP/0.9 and
HTTP/1.0 requests;
o HTTP/0.9とHTTP/1.0の要求としてRequest-線の形式を認識してください。
o understand any valid request in the format of HTTP/0.9 or
HTTP/1.0;
o HTTP/0.9かHTTP/1.0の形式であらゆる有効な要求を理解してください。
o respond appropriately with a message in the same protocol
version used by the client.
o メッセージがクライアントによって使用された同じプロトコルバージョンにある状態で、適切に応じてください。
HTTP/1.0 clients must:
HTTP/1.0人のクライアントはそうしなければなりません:
o recognize the format of the Status-Line for HTTP/1.0 responses;
o HTTP/1.0の応答としてStatus-線の形式を認識してください。
o understand any valid response in the format of HTTP/0.9 or
HTTP/1.0.
o HTTP/0.9かHTTP/1.0の形式であらゆる有効回答を理解してください。
Proxy and gateway applications must be careful in forwarding requests that are received in a format different than that of the application's native HTTP version. Since the protocol version indicates the protocol capability of the sender, a proxy/gateway must never send a message with a version indicator which is greater than its native version; if a higher version request is received, the proxy/gateway must either downgrade the request version or respond with an error. Requests with a version lower than that of the application's native format may be upgraded before being forwarded; the proxy/gateway's response to that request must follow the server requirements listed above.
プロキシとゲートウェイアプリケーションはアプリケーションの固有のHTTPバージョンのものと異なった形式で受け取られる推進要求で慎重であるに違いありません。 プロトコルバージョンが送付者のプロトコル能力を示すので、プロキシ/ゲートウェイは固有のバージョンよりすばらしいバージョンインディケータでメッセージを決して送ってはいけません。 より高いバージョン要求が受信されているなら、プロキシ/ゲートウェイは、要求バージョンを格下げしなければならないか、または誤りで応じなければなりません。 バージョンが進める前にアプリケーションのネイティブの形式のものをアップグレードさせるかもしれないより低い要求。 その要求へのプロキシ/ゲートウェイの応答は上にリストアップされたサーバ要件に続かなければなりません。
Berners-Lee, et al Informational [Page 13] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[13ページ]RFC1945HTTP/1996年5月1日
3.2 Uniform Resource Identifiers
3.2 Uniform Resource Identifier
URIs have been known by many names: WWW addresses, Universal Document Identifiers, Universal Resource Identifiers [2], and finally the combination of Uniform Resource Locators (URL) [4] and Names (URN) [16]. As far as HTTP is concerned, Uniform Resource Identifiers are simply formatted strings which identify--via name, location, or any other characteristic--a network resource.
URIは多くの名前によって知られています: Uniform Resource Locator(URL)[4]とNames(URN)[16]のWWWアドレス、Universal Document Identifiers、Universal Resource Identifiers[2]、および最終的に組み合わせ。 HTTPに関する限り、Uniform Resource Identifierは名前、位置、またはいかなる他の特性でもネットワーク資源を特定する単にフォーマットされたストリングです。
3.2.1 General Syntax
3.2.1 一般構文
URIs in HTTP can be represented in absolute form or relative to some known base URI [9], depending upon the context of their use. The two forms are differentiated by the fact that absolute URIs always begin with a scheme name followed by a colon.
絶対フォームか何らかの知られているベースURI[9]に比例してHTTPにおけるURIを表すことができます、彼らの使用の文脈によって。 2つのフォームがコロンが体系名のあとに続いていて絶対URIがいつも始まるという事実によって差別化されます。
URI = ( absoluteURI | relativeURI ) [ "#" fragment ]
URI=(absoluteURI| relativeURI)[「#」断片]
absoluteURI = scheme ":" *( uchar | reserved )
「absoluteURI=は計画する」:、」 *(予約されていた状態で|ucharします)
relativeURI = net_path | abs_path | rel_path
relativeURIはネットの_経路と等しいです。| 腹筋_経路| rel_経路
net_path = "//" net_loc [ abs_path ]
abs_path = "/" rel_path
rel_path = [ path ] [ ";" params ] [ "?" query ]
「ネットの_経路=」//」 ネットの_loc[腹筋_経路]腹筋_経路=」 /」 rel_経路rel_経路=[経路][「;」params][“?"質問]
path = fsegment *( "/" segment )
fsegment = 1*pchar
segment = *pchar
経路=fsegment*(「/」セグメント)fsegmentは1*pcharセグメント=*pcharと等しいです。
params = param *( ";" param )
param = *( pchar | "/" )
paramsがparam*と等しい、(「」、;param) paramが*と等しい 「(pchar| 」 /、」、)
scheme = 1*( ALPHA | DIGIT | "+" | "-" | "." )
net_loc = *( pchar | ";" | "?" )
query = *( uchar | reserved )
fragment = *( uchar | reserved )
「=1*を計画してください、(アルファー| DIGIT|「+」|「-」|、」、」、)、ネット_locが*と等しい、(pchar|、」、; 」 | “?") 質問=*(予約されていた状態で|ucharします)断片=*(予約されていた状態で|ucharします)
pchar = uchar | ":" | "@" | "&" | "=" | "+"
uchar = unreserved | escape
unreserved = ALPHA | DIGIT | safe | extra | national
pcharはucharと等しいです。| ":" | "@" | "&" | "=" | 「+」uchar=無遠慮です。| 無遠慮な=アルファーから逃げてください。| ケタ| 金庫| エキストラ| 国家
escape = "%" HEX HEX
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+"
extra = "!" | "*" | "'" | "(" | ")" | ","
safe = "$" | "-" | "_" | "."
unsafe = CTL | SP | <"> | "#" | "%" | "<" | ">"
national = <any OCTET excluding ALPHA, DIGIT,
「エスケープは「」 十六進法が魔法をかける%は=を予約したこと」と等しいです」 | "/" | "?" | ":" | "@" | "&" | "=" | 「+」 付加的な=“!" | "*" | "'" | "(" | ")" | 「」、安全な=「$」| "-" | "_" | 「. 」 危険な=CTL| SP| <">"| "#" | "%" | "<"| ">"国家の=<はアルファー、DIGITを除くあらゆるOCTETです。
Berners-Lee, et al Informational [Page 14] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[14ページ]RFC1945HTTP/1996年5月1日
reserved, extra, safe, and unsafe>
予約されて、付加的で、安全で、危険な>。
For definitive information on URL syntax and semantics, see RFC 1738 [4] and RFC 1808 [9]. The BNF above includes national characters not allowed in valid URLs as specified by RFC 1738, since HTTP servers are not restricted in the set of unreserved characters allowed to represent the rel_path part of addresses, and HTTP proxies may receive requests for URIs not defined by RFC 1738.
URL構文と意味論の決定的な情報に関しては、RFC1738[4]とRFC1808[9]を見てください。 上のBNFはRFC1738年までに指定されるとしての有効なURLに許容されなかった国民性を含んでいます、HTTPサーバがアドレスのrel_経路部分を表すことができた無遠慮な性格のセットで制限されないで、HTTPプロキシがRFC1738によって定義されなかったURIを求める要求を受け取るかもしれないので。
3.2.2 http URL
3.2.2 http URL
The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs.
"http"体系は、HTTPプロトコルでネットワーク資源の場所を見つけるのに使用されます。 このセクションはhttp URLのために体系特有の構文と意味論を定義します。
http_URL = "http:" "//" host [ ":" port ] [ abs_path ]
http_URL=は「以下をhttpします」。 「//」ホスト[「:」 ポート][腹筋_経路]
host = <A legal Internet host domain name
or IP address (in dotted-decimal form),
as defined by Section 2.1 of RFC 1123>
ホストは<のA法的なインターネット・ホストのドメイン名かIPアドレスと等しいです(ドット付き10進法フォームで)、RFC1123>のセクション2.1によって定義されるように
port = *DIGIT
ポートは*DIGITと等しいです。
If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path. If the abs_path is not present in the URL, it must be given as "/" when used as a Request-URI (Section 5.1.2).
ポートが人影がないか考えないで、ポート80は想定されます。 意味論は特定されたリソースがそのホストのそのポートの上でTCP接続の聞こうとするサーバで位置しているということです、そして、リソースのためのRequest-URIは腹筋_経路です。 いつがa要求URIとして(セクション5.1.2)を使用したかという「腹筋_経路がURLに存在していないなら、それは」 /として当然のことであるに違いありません」。
Note: Although the HTTP protocol is independent of the transport
layer protocol, the http URL only identifies resources by their
TCP location, and thus non-TCP resources must be identified by
some other URI scheme.
以下に注意してください。 HTTPプロトコルはトランスポート層プロトコルから独立していますが、http URLはそれらのTCP位置のそばでリソースを特定するだけです、そして、その結果、ある他のURI体系で非TCPリソースを特定しなければなりません。
The canonical form for "http" URLs is obtained by converting any UPALPHA characters in host to their LOALPHA equivalent (hostnames are case-insensitive), eliding the [ ":" port ] if the port is 80, and replacing an empty abs_path with "/".
「ホストでどんなUPALPHAキャラクタも変換することによって、"http"URLのための標準形を彼らのLOALPHA同等物に得ます(ホスト名は大文字と小文字を区別しないです)、削除している、[「: 」 ポート] ポートは80であるか、そして、人影のない腹筋_経路を」 /に取り替えること」。
3.3 Date/Time Formats
3.3 日付/時間形式
HTTP/1.0 applications have historically allowed three different formats for the representation of date/time stamps:
HTTP/1.0のアプリケーションが日付/タイムスタンプの表現のための3つの異なった形式を歴史的に許容しました:
Sun, 06 Nov 1994 08:49:37 GMT ; RFC 822, updated by RFC 1123
Sunday, 06-Nov-94 08:49:37 GMT ; RFC 850, obsoleted by RFC 1036
Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format
グリニッジ標準時1994年11月6日日曜日8時49分37秒。 RFC1123グリニッジ標準時1994年11月6日日曜日8時49分37秒までにアップデートされたRFC822。 RFC1036 1994年11月6日日曜日8時49分37秒までに時代遅れにされたRFC850。 ANSI Cのasctime()形式
Berners-Lee, et al Informational [Page 15] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[15ページ]RFC1945HTTP/1996年5月1日
The first format is preferred as an Internet standard and represents a fixed-length subset of that defined by RFC 1123 [6] (an update to RFC 822 [7]). The second format is in common use, but is based on the obsolete RFC 850 [10] date format and lacks a four-digit year. HTTP/1.0 clients and servers that parse the date value should accept all three formats, though they must never generate the third (asctime) format.
インターネット標準として好まれて、固定長部分集合を表します最初の形式がRFC1123[6]によって定義されたその。(RFC822[7])へのアップデート。 2番目の形式は、共用ですが、時代遅れのRFC850[10]日付の形式に基づいていて、4ケタの年間欠けています。 日付の値を分析するHTTP/1.0のクライアントとサーバがすべての3つの形式を受け入れるべきです、3番目の(asctime)が形式であると決して生成してはいけませんが。
Note: Recipients of date values are encouraged to be robust in
accepting date values that may have been generated by non-HTTP
applications, as is sometimes the case when retrieving or posting
messages via proxies/gateways to SMTP or NNTP.
以下に注意してください。 日付の値の受取人が非HTTPアプリケーションで生成されたかもしれない日付の値を受け入れるのにおいて強健であるよう奨励されます、SMTPかNNTPへのプロキシ/ゲートウェイを通してメッセージを検索するか、または掲示するとき、時々そうであるように。
All HTTP/1.0 date/time stamps must be represented in Universal Time (UT), also known as Greenwich Mean Time (GMT), without exception. This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for time zone, and should be assumed when reading the asctime format.
すべてのHTTP/1.0個の日付/タイムスタンプを世界標準時(ユタ)に表されて、また、(グリニッジ標準時に)グリニッジ標準時として例外なしで知っていなければなりません。 これは、時間帯のための3文字の略語として最初の2つの形式で「グリニッジ標準時」の包含で示されて、asctime書式を読むとき、想定されるべきです。
HTTP-date = rfc1123-date | rfc850-date | asctime-date
HTTP日付=rfc1123-日付| rfc850-日付| asctime-日付
rfc1123-date = wkday "," SP date1 SP time SP "GMT"
rfc850-date = weekday "," SP date2 SP time SP "GMT"
asctime-date = wkday SP date3 SP time SP 4DIGIT
「rfc1123-日付はwkdayと等しいです」、wkday SP date3 SP」SPが「」 グリニッジ標準時のrfc850-日付=平日」、「グリニッジ標準時」の」SP date2 SP時間SPのときにasctime日付を入れるSP date1 SP時間=時間SP 4DIGIT
date1 = 2DIGIT SP month SP 4DIGIT
; day month year (e.g., 02 Jun 1982)
date2 = 2DIGIT "-" month "-" 2DIGIT
; day-month-year (e.g., 02-Jun-82)
date3 = month SP ( 2DIGIT | ( SP 1DIGIT ))
; month day (e.g., Jun 2)
2DIGIT SP date1=月のSP 4DIGIT。 日月の2DIGIT「-」date2=月の年(例えば、1982年6月2日)の「-」2DIGIT。 日の月のdate3=月の年(例えば、1982年6月2日)のSP(2DIGIT| (SP 1DIGIT))。 月の日(例えば、6月2日)
time = 2DIGIT ":" 2DIGIT ":" 2DIGIT
; 00:00:00 - 23:59:59
「時間は2DIGITと等しい」:、」 "2DIGIT":、」 2DIGIT。 00:00:00 - 23:59:59
wkday = "Mon" | "Tue" | "Wed"
| "Thu" | "Fri" | "Sat" | "Sun"
wkday=「月曜日」| 「火曜日」| 「水曜日」| 「木曜日」| 「金曜日」| 「座っています」| 「Sun」
weekday = "Monday" | "Tuesday" | "Wednesday"
| "Thursday" | "Friday" | "Saturday" | "Sunday"
「月曜日」平日=| 「火曜日」| 「水曜日」| 「木曜日」| 「金曜日」| 「土曜日」| 「日曜日」
month = "Jan" | "Feb" | "Mar" | "Apr"
| "May" | "Jun" | "Jul" | "Aug"
| "Sep" | "Oct" | "Nov" | "Dec"
月=「1月」| 「2月」| 「3月」| 「4月」| 「5月」| 「6月」| 「7月」| 「8月」| 「9月」| 「10月」| 「11月」| 「12月」
Note: HTTP requirements for the date/time stamp format apply
only to their usage within the protocol stream. Clients and
servers are not required to use these formats for user
以下に注意してください。 日付/タイムスタンプ形式のためのHTTP要件はプロトコルストリームの中でそれらの用法だけに適用されます。 クライアントとサーバは、ユーザにこれらの形式を使用するのに必要ではありません。
Berners-Lee, et al Informational [Page 16] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[16ページ]RFC1945HTTP/1996年5月1日
presentation, request logging, etc.
プレゼンテーション、要求伐採など
3.4 Character Sets
3.4 文字コード
HTTP uses the same definition of the term "character set" as that described for MIME:
それがMIMEのために説明したようにHTTPは「文字集合」という用語の同じ定義を使用します:
The term "character set" is used in this document to refer to a
method used with one or more tables to convert a sequence of
octets into a sequence of characters. Note that unconditional
conversion in the other direction is not required, in that not all
characters may be available in a given character set and a
character set may provide more than one sequence of octets to
represent a particular character. This definition is intended to
allow various kinds of character encodings, from simple single-
table mappings such as US-ASCII to complex table switching methods
such as those that use ISO 2022's techniques. However, the
definition associated with a MIME character set name must fully
specify the mapping to be performed from octets to characters. In
particular, use of external profiling information to determine the
exact mapping is not permitted.
「文字集合」という用語は、八重奏の系列をキャラクタの系列に変換するのに1個以上のテーブルと共に使用されるメソッドを示すのに本書では使用されます。 もう片方の方向への無条件の変換は必要でないことに注意してください、すべてのキャラクタがどんな与えられた文字集合で手があくかもしれないというわけではなくて、文字集合が特定のキャラクタの代理をするために八重奏の1つ以上の系列を提供するかもしれないので。 この定義が様々な種類の文字符号化を許容することを意図します、米国-ASCIIなどの簡単なただ一つのテーブルマッピングから複雑なISO2022のテクニックを使用するものなどのテーブル切り換えメソッドまで。 しかしながら、MIME文字集合名に関連している定義は、八重奏からキャラクタまで実行されるためにマッピングを完全に指定しなければなりません。 特に、正確なマッピングを決定する外部のプロフィール情報の使用は受入れられません。
Note: This use of the term "character set" is more commonly
referred to as a "character encoding." However, since HTTP and
MIME share the same registry, it is important that the terminology
also be shared.
以下に注意してください。 「文字集合」という用語のこの使用は、より一般的に「文字符号化」と呼ばれます。 しかしながら、HTTPとMIMEが同じ登録を共有するので、また、用語が共有されるのは、重要です。
HTTP character sets are identified by case-insensitive tokens. The complete set of tokens are defined by the IANA Character Set registry [15]. However, because that registry does not define a single, consistent token for each character set, we define here the preferred names for those character sets most likely to be used with HTTP entities. These character sets include those registered by RFC 1521 [5] -- the US-ASCII [17] and ISO-8859 [18] character sets -- and other names specifically recommended for use within MIME charset parameters.
HTTP文字集合は大文字と小文字を区別しないトークンによって特定されます。 完全なセットのトークンはIANA文字コード登録[15]によって定義されます。 しかしながら、その登録が各文字集合のためにシングル、一貫したトークンを定義しないので、私たちはHTTP実体と共に最も使用されそうなそれらの文字集合のためにここで都合のよい名前を定義します。 これらの文字集合はRFC1521[5](米国-ASCII[17]とISO-8859[18]文字集合)によって登録されたものとMIME charsetパラメタの中の使用のために明確に推薦された他の名前を含んでいます。
charset = "US-ASCII"
| "ISO-8859-1" | "ISO-8859-2" | "ISO-8859-3"
| "ISO-8859-4" | "ISO-8859-5" | "ISO-8859-6"
| "ISO-8859-7" | "ISO-8859-8" | "ISO-8859-9"
| "ISO-2022-JP" | "ISO-2022-JP-2" | "ISO-2022-KR"
| "UNICODE-1-1" | "UNICODE-1-1-UTF-7" | "UNICODE-1-1-UTF-8"
| token
charsetは「米国-ASCII」と等しいです。| 「ISO8859、1インチ、」| 「ISO8859、2インチ、」| 「ISO8859、3インチ、」| 「ISO8859、4インチ、」| 「ISO8859、5インチ、」| 「ISO8859、6インチ、」| 「ISO8859、7インチ、」| 「ISO8859、8インチ、」| 「ISO8859、9インチ、」| 「ISO2022JP」| 「ISO2022JP、2インチ、」| 「ISO2022Kr」| 「ユニコード1、1インチ、」| 「ユニコード1-1UTF、7インチ、」| 「ユニコード1-1UTF、8インチ、」| トークン
Although HTTP allows an arbitrary token to be used as a charset value, any token that has a predefined value within the IANA Character Set registry [15] must represent the character set defined
HTTPは、任意のトークンがcharset値として使用されるのを許容しますが、IANA文字コード登録[15]の中に事前に定義された値を持っているどんなトークンも定義された文字集合を表さなければなりません。
Berners-Lee, et al Informational [Page 17] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[17ページ]RFC1945HTTP/1996年5月1日
by that registry. Applications should limit their use of character sets to those defined by the IANA registry.
その登録のそばで。 アプリケーションは彼らの文字集合の使用をIANA登録によって定義されたものに制限するべきです。
The character set of an entity body should be labelled as the lowest common denominator of the character codes used within that body, with the exception that no label is preferred over the labels US-ASCII or ISO-8859-1.
実体本体の文字集合がそのボディーの中で使用されたキャラクタコードの最小公分母としてラベルされるべきであり、例外で、そのラベルなしはラベルの米国-ASCIIかISO-8859-1より好まれます。
3.5 Content Codings
3.5 満足しているコーディング
Content coding values are used to indicate an encoding transformation that has been applied to a resource. Content codings are primarily used to allow a document to be compressed or encrypted without losing the identity of its underlying media type. Typically, the resource is stored in this encoding and only decoded before rendering or analogous usage.
満足しているコード化値は、リソースに適用されたコード化変換を示すのに使用されます。 満足しているコーディングは、ドキュメントが基本的なメディアタイプのアイデンティティを失わないで圧縮されるか、または暗号化されるのを許容するのに主として使用されます。 通常、リソースは、レンダリングか類似の用法の前にコード化して、解読するだけでありながら、これに保存されます。
content-coding = "x-gzip" | "x-compress" | token
内容をコード化する="x-gzip"| 「x-湿布」| トークン
Note: For future compatibility, HTTP/1.0 applications should
consider "gzip" and "compress" to be equivalent to "x-gzip"
and "x-compress", respectively.
以下に注意してください。 将来の互換性のために、HTTP/1.0のアプリケーションが、"gzip"と「湿布」がそれぞれ"x-gzip"と「x-湿布」に相当していると考えるべきです。
All content-coding values are case-insensitive. HTTP/1.0 uses content-coding values in the Content-Encoding (Section 10.3) header field. Although the value describes the content-coding, what is more important is that it indicates what decoding mechanism will be required to remove the encoding. Note that a single program may be capable of decoding multiple content-coding formats. Two values are defined by this specification:
すべての内容をコード化する値が大文字と小文字を区別しないです。 HTTP/1.0はContentをコード化している(セクション10.3)ヘッダーフィールドに内容をコード化する値を使用します。 値は内容をコード化しているのと説明しますが、より重要なことはどんな解読メカニズムがコード化を取り除かなければならないかを示すということです。 単一のプログラムが複数の内容をコード化する書式を解読できるかもしれないことに注意してください。 2つの値がこの仕様で定義されます:
x-gzip
An encoding format produced by the file compression program
"gzip" (GNU zip) developed by Jean-loup Gailly. This format is
typically a Lempel-Ziv coding (LZ77) with a 32 bit CRC.
ジャンルー・ゲイルによって開発されたファイル圧縮プログラム"gzip"(GNUはすばやく動く)でx-gzip Anコード化形式は発生しました。 通常、この形式は32ビットのCRCがあるLempel-Ziv符号(LZ77)です。
x-compress
The encoding format produced by the file compression program
"compress". This format is an adaptive Lempel-Ziv-Welch coding
(LZW).
「湿布」というファイル圧縮プログラムで発生したコード化形式をxで圧縮してください。 この形式は適応型のLempel-Ziv-ウェルチコード化(LZW)です。
Note: Use of program names for the identification of
encoding formats is not desirable and should be discouraged
for future encodings. Their use here is representative of
historical practice, not good design.
以下に注意してください。 プログラム名のコード化形式の識別の使用は、望ましくなく、将来のencodingsのためにお勧めできなくあるべきです。 ここでの彼らの使用は良いデザインではなく、歴史的な習慣を代表しています。
Berners-Lee, et al Informational [Page 18] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[18ページ]RFC1945HTTP/1996年5月1日
3.6 Media Types
3.6のメディアタイプ
HTTP uses Internet Media Types [13] in the Content-Type header field (Section 10.5) in order to provide open and extensible data typing.
HTTPは、開いていて広げることができるデータ型定義を提供するのにコンテントタイプヘッダーフィールド(セクション10.5)にインターネットメディアTypes[13]を使用します。
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
」 「メディアタイプはタイプと等しく」/「副-タイプ」*(「;」パラメタ)タイプはトークン「副-タイプ」=トークンと等しいです。
Parameters may follow the type/subtype in the form of attribute/value pairs.
パラメタは属性/値の組の形でタイプ/「副-タイプ」に続くかもしれません。
parameter = attribute "=" value
attribute = token
value = token | quoted-string
パラメタ=属性「=」値属性=トークン価値はトークンと等しいです。| 引用文字列
The type, subtype, and parameter attribute names are case- insensitive. Parameter values may or may not be case-sensitive, depending on the semantics of the parameter name. LWS must not be generated between the type and subtype, nor between an attribute and its value. Upon receipt of a media type with an unrecognized parameter, a user agent should treat the media type as if the unrecognized parameter and its value were not present.
タイプ、「副-タイプ」、およびパラメタ属性名はケース鈍感です。 パラメタ名の意味論によって、パラメタ値は大文字と小文字を区別しているかもしれません。 タイプと「副-タイプ」の間と、そして、属性とその値の間でLWSを生成してはいけません。 認識されていないパラメタがあるメディアタイプを受け取り次第、まるで認識されていないパラメタとその値が存在していないかのようにユーザエージェントはメディアタイプを扱うべきです。
Some older HTTP applications do not recognize media type parameters. HTTP/1.0 applications should only use media type parameters when they are necessary to define the content of a message.
いくつかの、より古いHTTPアプリケーションはメディア型引数を認識しません。 それらがメッセージの内容を定義するのに必要であるときにだけ、HTTP/1.0のアプリケーションがメディア型引数を使用するべきです。
Media-type values are registered with the Internet Assigned Number Authority (IANA [15]). The media type registration process is outlined in RFC 1590 [13]. Use of non-registered media types is discouraged.
メディアでタイプしている値はISOCの機関の一つでに示されます。(IANA[15])。 メディアタイプ登録手続はRFC1590[13]に概説されています。 非登録されたメディアタイプの使用はお勧めできないです。
3.6.1 Canonicalization and Text Defaults
3.6.1 Canonicalizationとテキストはデフォルトとします。
Internet media types are registered with a canonical form. In general, an Entity-Body transferred via HTTP must be represented in the appropriate canonical form prior to its transmission. If the body has been encoded with a Content-Encoding, the underlying data should be in canonical form prior to being encoded.
インターネットメディアタイプは標準形に示されます。 一般に、トランスミッションの前に適切な標準形にHTTPで移されたEntity-ボディーを表さなければなりません。 ボディーがContent-コード化でコード化されたなら、基本的なデータがコード化される前に、標準形にあるべきです。
Media subtypes of the "text" type use CRLF as the text line break when in canonical form. However, HTTP allows the transport of text media with plain CR or LF alone representing a line break when used consistently within the Entity-Body. HTTP applications must accept CRLF, bare CR, and bare LF as being representative of a line break in text media received via HTTP.
標準形にあるとき、「テキスト」タイプのメディア血液型亜型はテキストラインブレイクとしてCRLFを使用します。 しかしながら、HTTPは、Entity-ボディーの中で一貫して使用されるとラインブレイクを表しながら、明瞭なCRかLFが単独のテキストメディアの輸送を許容します。 HTTPアプリケーションはラインブレイクを代表するとHTTPで受け取られたテキストメディアでCRLF、むき出しのCR、およびむき出しのLFを認めなければなりません。
Berners-Lee, et al Informational [Page 19] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[19ページ]RFC1945HTTP/1996年5月1日
In addition, if the text media is represented in a character set that does not use octets 13 and 10 for CR and LF respectively, as is the case for some multi-byte character sets, HTTP allows the use of whatever octet sequences are defined by that character set to represent the equivalent of CR and LF for line breaks. This flexibility regarding line breaks applies only to text media in the Entity-Body; a bare CR or LF should not be substituted for CRLF within any of the HTTP control structures (such as header fields and multipart boundaries).
さらに、テキストメディアがCRとLFにそれぞれ八重奏13と10を使用しない文字集合で代表されるなら、いくつかの多バイト文字セットのためのケースのように、その文字集合によって定義されるどんな八重奏系列の使用もラインブレイクのためにHTTPでCRとLFの同等物を表すことができます。 ラインブレイクに関するこの柔軟性はEntity-ボディーのテキストメディアだけに適用されます。 HTTP制御構造(ヘッダーフィールドや複合境界などの)のどれかの中でむき出しのCRかLFをCRLFに代入するべきではありません。
The "charset" parameter is used with some media types to define the character set (Section 3.4) of the data. When no explicit charset parameter is provided by the sender, media subtypes of the "text" type are defined to have a default charset value of "ISO-8859-1" when received via HTTP. Data in character sets other than "ISO-8859-1" or its subsets must be labelled with an appropriate charset value in order to be consistently interpreted by the recipient.
"charset"パラメタは、データの文字集合(セクション3.4)を定義するのに何人かのメディアタイプで使用されます。 「テキスト」タイプのメディア血液型亜型がデフォルトcharset価値を持つためにどんな明白なcharsetパラメタもいつ送付者によって提供されないかが定義される、「ISO、8859、1インチ、いつ、HTTPで受信するか、」 または、データがぴったりしたセットする、「ISO8859、1インチ、受取人によって一貫して解釈されるように適切なcharset値で部分集合をラベルしなければならない、」
Note: Many current HTTP servers provide data using charsets other
than "ISO-8859-1" without proper labelling. This situation reduces
interoperability and is not recommended. To compensate for this,
some HTTP user agents provide a configuration option to allow the
user to change the default interpretation of the media type
character set when no charset parameter is given.
以下に注意してください。 多くの現在のHTTPサーバがcharsetsを使用するデータを提供する、「ISO8859、1インチ、適切なラベル、」 この状況は、相互運用性を減少させて、推薦されません。 これを補うなら、何人かのHTTPユーザエージェントが、charsetパラメタを全く与えないとき、ユーザがメディアタイプ文字集合のデフォルト解釈を変えるのを許容するために設定オプションを提供します。
3.6.2 Multipart Types
3.6.2 複合タイプ
MIME provides for a number of "multipart" types -- encapsulations of several entities within a single message's Entity-Body. The multipart types registered by IANA [15] do not have any special meaning for HTTP/1.0, though user agents may need to understand each type in order to correctly interpret the purpose of each body-part. An HTTP user agent should follow the same or similar behavior as a MIME user agent does upon receipt of a multipart type. HTTP servers should not assume that all HTTP clients are prepared to handle multipart types.
MIMEは多くの「複合」のタイプに備えます--ただ一つのメッセージのEntity-ボディーの中のいくつかの実体のカプセル化。 IANA[15]によって示された複合タイプはHTTP/1.0のための少しの特別な意味も持っていません、ユーザエージェントが、正しくそれぞれの身体部分の目的を解釈するために各タイプを理解する必要があるかもしれませんが。 MIMEユーザエージェントが複合タイプを受け取り次第するとき、HTTPユーザエージェントは同じであるか同様の振舞いの後をつけるべきです。 HTTPサーバは、すべてのHTTPクライアントが複合タイプを扱う用意ができていると仮定するべきではありません。
All multipart types share a common syntax and must include a boundary parameter as part of the media type value. The message body is itself a protocol element and must therefore use only CRLF to represent line breaks between body-parts. Multipart body-parts may contain HTTP header fields which are significant to the meaning of that part.
すべての複合タイプが、一般的な構文を共有して、タイプが評価するメディアの一部として境界パラメタを入れなければなりません。 メッセージ本体は、それ自体でプロトコル要素であり、したがって、身体部分の間のラインブレイクを表すのにCRLFだけを使用しなければなりません。 複合身体部分はその部分の意味に重要なHTTPヘッダ分野を含むかもしれません。
3.7 Product Tokens
3.7 製品トークン
Product tokens are used to allow communicating applications to identify themselves via a simple product token, with an optional slash and version designator. Most fields using product tokens also allow subproducts which form a significant part of the application to
製品トークンは簡単な製品トークンで自分たちを特定するためにアプリケーションを伝えるのを許容するのに使用されます、任意のスラッシュとバージョン指示子で。 またトークンがアプリケーションのかなりの部分を形成する「副-製品」を許容する製品を使用するほとんどの分野
Berners-Lee, et al Informational [Page 20] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[20ページ]RFC1945HTTP/1996年5月1日
be listed, separated by whitespace. By convention, the products are listed in order of their significance for identifying the application.
空白によって記載されて、切り離されてください。 コンベンションによって、製品はアプリケーションを特定するためのそれらの意味の順に記載されています。
product = token ["/" product-version]
product-version = token
製品=トークン[「/」製品バージョン]製品バージョン=トークン
Examples:
例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
ユーザエージェント: CERN-LineMode/2.15libwww/2.17b3
Server: Apache/0.8.4
サーバ: アパッチ/0.8.4
Product tokens should be short and to the point -- use of them for advertizing or other non-essential information is explicitly forbidden. Although any token character may appear in a product- version, this token should only be used for a version identifier (i.e., successive versions of the same product should only differ in the product-version portion of the product value).
製品トークンは、短くて、肝心であるべきです--それらのadvertizingか他の不要不急な情報の使用は明らかに禁じられます。 どんなトークンキャラクタも製品バージョンに現れるかもしれませんが、このトークンはバージョン識別子に使用されるだけであるべきです(すなわち、同じ製品の連続したバージョンは生産物価値の製品バージョン部分で異なるだけであるべきです)。
4. HTTP Message
4. HTTPメッセージ
4.1 Message Types
4.1 メッセージタイプ
HTTP messages consist of requests from client to server and responses from server to client.
HTTPメッセージはクライアントからサーバまでの要求とサーバからクライアントまでの応答から成ります。
HTTP-message = Simple-Request ; HTTP/0.9 messages
| Simple-Response
| Full-Request ; HTTP/1.0 messages
| Full-Response
HTTPメッセージは簡単な要求と等しいです。 HTTP/0.9のメッセージ| 簡単な応答| 完全な要求。 HTTP/1.0のメッセージ| 完全な応答
Full-Request and Full-Response use the generic message format of RFC 822 [7] for transferring entities. Both messages may include optional header fields (also known as "headers") and an entity body. The entity body is separated from the headers by a null line (i.e., a line with nothing preceding the CRLF).
完全な要求とFull-応答は、実体を移すのにRFC822[7]のジェネリックメッセージ・フォーマットを使用します。 両方のメッセージは任意のヘッダーフィールド(また、「ヘッダー」として、知られている)と実体本体を含むかもしれません。 空行(すなわち、何もCRLFに先行していない系列)によって実体本体はヘッダーと切り離されます。
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
完全な要求は要求線と等しいです。 セクション5.1*(一般ヘッダー; セクション4.3| 要求ヘッダー; セクション5.2| 実体ヘッダー)。 セクション7.1 CRLF[実体本体]。 セクション7.2
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
完全な応答は状況表示行と等しいです。 セクション6.1*、(一般ヘッダー; セクション4.3| 応答ヘッダ; セクション6.2
Berners-Lee, et al Informational [Page 21] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[21ページ]RFC1945HTTP/1996年5月1日
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
|、実体ヘッダー) ; セクション7.1 CRLF[実体本体]。 セクション7.2
Simple-Request and Simple-Response do not allow the use of any header information and are limited to a single request method (GET).
簡単な要求とSimple-応答は、どんなヘッダー情報の使用も許さないで、ただ一つの要求メソッド(GET)に制限されます。
Simple-Request = "GET" SP Request-URI CRLF
簡単な要求=「得てください」SP要求URI CRLF
Simple-Response = [ Entity-Body ]
簡単な応答=[実体本体]
Use of the Simple-Request format is discouraged because it prevents the server from identifying the media type of the returned entity.
それが、サーバが返された実体のメディアタイプを特定するのを防ぐので、Simple-要求形式の使用はお勧めできないです。
4.2 Message Headers
4.2 メッセージヘッダー
HTTP header fields, which include General-Header (Section 4.3),
Request-Header (Section 5.2), Response-Header (Section 6.2), and
Entity-Header (Section 7.1) fields, follow the same generic format as
that given in Section 3.1 of RFC 822 [7]. Each header field consists
of a name followed immediately by a colon (":"), a single space (SP)
character, and the field value. Field names are case-insensitive.
Header fields can be extended over multiple lines by preceding each
extra line with at least one SP or HT, though this is not
recommended.
HTTPヘッダ分野(一般ヘッダー(セクション4.3)、Request-ヘッダー(セクション5.2)、Response-ヘッダー(セクション6.2)、およびEntity-ヘッダー(セクション7.1)分野を含んでいる)はRFC822[7]のセクション3.1におけるそんなに与えられるのと同じジェネリック形式に続きます。 各ヘッダーフィールドがすぐコロンがあとに続いた名前から成る、(「:」、)、シングルスペース(SP)キャラクタ、および分野値。 フィールド名は大文字と小文字を区別しないです。 ヘッダーフィールドはそれぞれの付加的な系列に先行することによって、達せられた倍数が少なくとも1SPかHTと共に立ち並んでいます、これが推薦されませんがことであるかもしれません。
HTTP-header = field-name ":" [ field-value ] CRLF
「HTTPヘッダ=フィールド名」:、」 [分野値] CRLF
field-name = token
field-value = *( field-content | LWS )
フィールド名=トークン分野価値は*と等しいです。(分野内容| LWS)
field-content = <the OCTETs making up the field-value
and consisting of either *TEXT or combinations
of token, tspecials, and quoted-string>
分野内容が<と等しい、分野値を作って、トークンの*TEXTか組み合わせのどちらかから成るOCTETs、tspecials、および引用文字列>。
The order in which header fields are received is not significant. However, it is "good practice" to send General-Header fields first, followed by Request-Header or Response-Header fields prior to the Entity-Header fields.
ヘッダーフィールドが受け取られているオーダーは重要ではありません。 しかしながら、Request-ヘッダーかResponse-ヘッダーフィールドがEntity-ヘッダーフィールドの前に支えた一般ヘッダーフィールド1番目を送るのは、「良い習慣」です。
Multiple HTTP-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]. It must be possible to combine the multiple header fields into one "field- name: field-value" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma.
そして、同じフィールド名がある複数のHTTPヘッダ分野がメッセージに存在しているかもしれない、そのヘッダーフィールドのための全体の分野値がコンマで切り離されたリスト[すなわち、#値()]と定義される場合にだけ。 ある「分野は以下を命名する」と複数のヘッダーフィールドを結合するのが可能であるに違いありません。 それぞれのその後の分野値を1日に追加することによってメッセージの意味論を変えないで、「分野値」組はコンマでそれぞれ分離しました。
Berners-Lee, et al Informational [Page 22] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[22ページ]RFC1945HTTP/1996年5月1日
4.3 General Header Fields
4.3 一般ヘッダーフィールド
There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These headers apply only to the message being transmitted.
要求と応答メッセージの両方のために一般的な適用性を持っていますが、移される実体に適用されないいくつかのヘッダーフィールドがあります。 これらのヘッダーは送られるメッセージだけに適用します。
General-Header = Date ; Section 10.6
| Pragma ; Section 10.12
一般ヘッダー=日付。 セクション10.6| Pragma。 セクション10.12
General header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general header fields. Unrecognized header fields are treated as Entity-Header fields.
単にプロトコルバージョンにおける変化と組み合わせて一般ヘッダーフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが一般的なヘッダーフィールドであると認めるなら、一般的なヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドはEntity-ヘッダーフィールドとして扱われます。
5. Request
5. 要求
A request message from a client to a server includes, within the first line of that message, the method to be applied to the resource, the identifier of the resource, and the protocol version in use. For backwards compatibility with the more limited HTTP/0.9 protocol, there are two valid formats for an HTTP request:
クライアントからサーバまでの要求メッセージはそのメッセージの最初の系列の中にリソースに適用されるべきメソッド、リソースに関する識別子、および使用中のプロトコルバージョンを含んでいます。 より限られたHTTP/0.9プロトコルとの遅れている互換性のために、HTTP要求のための2つの有効な形式があります:
Request = Simple-Request | Full-Request
=簡単な要求を要求してください。| 完全な要求
Simple-Request = "GET" SP Request-URI CRLF
簡単な要求=「得てください」SP要求URI CRLF
Full-Request = Request-Line ; Section 5.1
*( General-Header ; Section 4.3
| Request-Header ; Section 5.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
完全な要求は要求線と等しいです。 セクション5.1*(一般ヘッダー; セクション4.3| 要求ヘッダー; セクション5.2| 実体ヘッダー)。 セクション7.1 CRLF[実体本体]。 セクション7.2
If an HTTP/1.0 server receives a Simple-Request, it must respond with an HTTP/0.9 Simple-Response. An HTTP/1.0 client capable of receiving a Full-Response should never generate a Simple-Request.
HTTP/1.0サーバがSimple-要求を受け取るなら、それはHTTP/0.9Simple-応答で応じなければなりません。 Full-応答を受けることができるHTTP/1.0クライアントはSimple-要求を決して生成するべきではありません。
5.1 Request-Line
5.1 要求線
The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The elements are separated by SP characters. No CR or LF are allowed except in the final CRLF sequence.
Request-URIとプロトコルバージョンがあとに続いていて、CRLFと共に終わって、Request-線はメソッドトークンで始まります。 要素はSPキャラクタによって切り離されます。 最終的なCRLF系列以外に、どんなCRもLFも許容されていません。
Request-Line = Method SP Request-URI SP HTTP-Version CRLF
メソッドSP要求URI SP HTTPバージョン要求線=CRLF
Berners-Lee, et al Informational [Page 23] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[23ページ]RFC1945HTTP/1996年5月1日
Note that the difference between a Simple-Request and the Request- Line of a Full-Request is the presence of the HTTP-Version field and the availability of methods other than GET.
Full-要求のSimple-要求とRequest線の違いがHTTPバージョン分野の存在とGET以外のメソッドの有用性であることに注意してください。
5.1.1 Method
5.1.1 メソッド
The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.
MethodトークンはRequest-URIによって特定されたリソースに実行されるべきメソッドを示します。 メソッドは大文字と小文字を区別しています。
Method = "GET" ; Section 8.1
| "HEAD" ; Section 8.2
| "POST" ; Section 8.3
| extension-method
メソッドは「得てください」と等しいです。 セクション8.1| 「向かってください」。 セクション8.2| 「ポスト」。 セクション8.3| 拡大メソッド
extension-method = token
拡大メソッドはトークンと等しいです。
The list of methods acceptable by a specific resource can change dynamically; the client is notified through the return code of the response if a method is not allowed on a resource. Servers should return the status code 501 (not implemented) if the method is unrecognized or not implemented.
特定のリソースで許容できるメソッドのリストはダイナミックに変化できます。 メソッドがリソースに許容されていないなら、クライアントは応答の復帰コードを通して通知されます。 メソッドが認識されていないか実装されないなら、サーバはステータスコード501(実装されません)を返すべきです。
The methods commonly used by HTTP/1.0 applications are fully defined in Section 8.
HTTP/1.0のアプリケーションで一般的に使用されるメソッドはセクション8で完全に定義されます。
5.1.2 Request-URI
5.1.2 要求URI
The Request-URI is a Uniform Resource Identifier (Section 3.2) and identifies the resource upon which to apply the request.
Request-URIは、Uniform Resource Identifier(セクション3.2)であり、要求を適用するリソースを特定します。
Request-URI = absoluteURI | abs_path
要求URI=absoluteURI| 腹筋_経路
The two options for Request-URI are dependent on the nature of the request.
Request-URIのための2つのオプションが要求の本質に依存しています。
The absoluteURI form is only allowed when the request is being made to a proxy. The proxy is requested to forward the request and return the response. If the request is GET or HEAD and a prior response is cached, the proxy may use the cached message if it passes any restrictions in the Expires header field. Note that the proxy may forward the request on to another proxy or directly to the server specified by the absoluteURI. In order to avoid request loops, a proxy must be able to recognize all of its server names, including any aliases, local variations, and the numeric IP address. An example Request-Line would be:
要求がプロキシに出されているときだけ、absoluteURIフォームは許容されています。 要求を転送して、プロキシが応答を返すよう要求されています。 要求がGETかHEADであり、先の応答がキャッシュされるなら、何かExpiresヘッダーフィールドにおける制限に合格するなら、プロキシはキャッシュされたメッセージを使用するかもしれません。 プロキシが別のプロキシ、または、直接absoluteURIによって指定されたサーバに要求を転送するかもしれないことに注意してください。 要求輪を避けるために、プロキシはサーバー名のすべてを認識できなければなりません、どんな別名、地理的変異、および数値IPアドレスも含んでいて。 例のRequest-線は以下の通りでしょう。
GET http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0
http://www.w3.org/pub/WWW/TheProject.html HTTP/1.0を得てください。
Berners-Lee, et al Informational [Page 24] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[24ページ]RFC1945HTTP/1996年5月1日
The most common form of Request-URI is that used to identify a resource on an origin server or gateway. In this case, only the absolute path of the URI is transmitted (see Section 3.2.1, abs_path). For example, a client wishing to retrieve the resource above directly from the origin server would create a TCP connection to port 80 of the host "www.w3.org" and send the line:
最も一般的なフォームのRequest-URIは発生源サーバかゲートウェイに関するリソースを特定するのにおいてそんなに使用されています。 この場合、URIの絶対パスだけが伝えられます(セクション3.2.1、腹筋_経路を見てください)。 例えば、直接発生源サーバからの上記のリソースを検索したがっているクライアントは80ホスト"www.w3.org"を移植して、系列を送るためにTCP接続を創造するでしょう:
GET /pub/WWW/TheProject.html HTTP/1.0
/pub/WWW/TheProject.html HTTP/1.0を手に入れてください。
followed by the remainder of the Full-Request. Note that the absolute path cannot be empty; if none is present in the original URI, it must be given as "/" (the server root).
Full-要求の残りはあとに続いています。 絶対パスが空であるはずがないことに注意してください。 「なにもオリジナルのURIで存在していないなら、」 /としてそれを与えなければならない」(サーバルート)。
The Request-URI is transmitted as an encoded string, where some characters may be escaped using the "% HEX HEX" encoding defined by RFC 1738 [4]. The origin server must decode the Request-URI in order to properly interpret the request.
キャラクタもあるかもしれません。((そこでは、キャラクタ、使用することで逃げられます))。「Request-URIがコード化されたストリングとして伝えられる、」 %は」 コード化がRFC1738[4]で定義した十六進法に魔法をかけます。 発生源サーバは、適切に要求を解釈するためにRequest-URIを解読しなければなりません。
5.2 Request Header Fields
5.2 要求ヘッダーフィールド
The request header fields allow the client to pass additional information about the request, and about the client itself, to the server. These fields act as request modifiers, with semantics equivalent to the parameters on a programming language method (procedure) invocation.
クライアントは要求ヘッダーフィールドで要求、およびクライアント自身に関する追加情報を通過できます、サーバに。これらの分野は要求修飾語として機能します、プログラミング言語メソッド(手順)実施に関するパラメタに同等な意味論で。
Request-Header = Authorization ; Section 10.2
| From ; Section 10.8
| If-Modified-Since ; Section 10.9
| Referer ; Section 10.13
| User-Agent ; Section 10.15
要求ヘッダーは承認と等しいです。 セクション10.2| 。 セクション10.8| 以来変更されるなら。 セクション10.9| Referer。 セクション10.13| ユーザエージェント。 セクション10.15
Request-Header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of request header fields if all parties in the communication recognize them to be request header fields. Unrecognized header fields are treated as Entity-Header fields.
単にプロトコルバージョンにおける変化と組み合わせて要求ヘッダーフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが要求ヘッダーフィールドであると認めるなら、要求ヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドはEntity-ヘッダーフィールドとして扱われます。
6. Response
6. 応答
After receiving and interpreting a request message, a server responds in the form of an HTTP response message.
要求メッセージを受け取って、解釈した後に、サーバはHTTP応答メッセージの形で反応します。
Response = Simple-Response | Full-Response
応答は簡単な応答と等しいです。| 完全な応答
Simple-Response = [ Entity-Body ]
簡単な応答=[実体本体]
Berners-Lee, et al Informational [Page 25] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[25ページ]RFC1945HTTP/1996年5月1日
Full-Response = Status-Line ; Section 6.1
*( General-Header ; Section 4.3
| Response-Header ; Section 6.2
| Entity-Header ) ; Section 7.1
CRLF
[ Entity-Body ] ; Section 7.2
完全な応答は状況表示行と等しいです。 セクション6.1*(一般ヘッダー; セクション4.3| 応答ヘッダ; セクション6.2| 実体ヘッダー)。 セクション7.1 CRLF[実体本体]。 セクション7.2
A Simple-Response should only be sent in response to an HTTP/0.9 Simple-Request or if the server only supports the more limited HTTP/0.9 protocol. If a client sends an HTTP/1.0 Full-Request and receives a response that does not begin with a Status-Line, it should assume that the response is a Simple-Response and parse it accordingly. Note that the Simple-Response consists only of the entity body and is terminated by the server closing the connection.
HTTP/0.9Simple-要求かサーバが、より限られたHTTP/0.9プロトコルをサポートするだけであるかどうかに対応してSimple-応答を送るだけであるべきです。 クライアントがHTTP/1.0Full-要求を送って、Status-線で始まらない応答を受けるなら、それは、応答がSimple-応答であると仮定して、それに従って、それを分析するべきです。 Simple-応答が実体本体だけから成って、接続を終えるサーバによって終えられることに注意してください。
6.1 Status-Line
6.1 状況表示行
The first line of a Full-Response message is the Status-Line, consisting of the protocol version followed by a numeric status code and its associated textual phrase, with each element separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
Full-応答メッセージの最初の系列はStatus-線です、数値ステータスコードとその関連原文の句があとに続いたプロトコルバージョンから成って、各要素がSPキャラクタによって切り離されている状態で。 最終的なCRLF系列以外に、どんなCRもLFも許容されていません。
Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
状況表示行=HTTPバージョンSPステータスコードSP理由句のCRLF
Since a status line always begins with the protocol version and status code
状況表示行がいつもプロトコルバージョンとステータスコードで始まるので
"HTTP/" 1*DIGIT "." 1*DIGIT SP 3DIGIT SP
「「HTTP/」1*ケタ」、」 1*ケタSP 3DIGIT SP
(e.g., "HTTP/1.0 200 "), the presence of that expression is sufficient to differentiate a Full-Response from a Simple-Response. Although the Simple-Response format may allow such an expression to occur at the beginning of an entity body, and thus cause a misinterpretation of the message if it was given in response to a Full-Request, most HTTP/0.9 servers are limited to responses of type "text/html" and therefore would never generate such a response.
(例えば、「HTTP/1.0 200」)、その式の存在は、Simple-応答とFull-応答を区別するために十分です。 Full-要求に対応してそれを与えたなら、Simple-応答形式は、そのような式が実体本体の始めに現れるのを許容して、ほとんどのHTTP/0.9のサーバがタイプ「テキスト/html」の応答に制限されて、したがって、そのような応答を決して生成して、その結果、メッセージの誤解を引き起こすことがないかもしれません。
6.1.1 Status Code and Reason Phrase
6.1.1 コードと理由が言葉で表す状態
The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason-Phrase.
Status-コード要素は要望を理解して、応じる試みの3ケタの整数結果コードです。 Reason-句がStatus-コードの短い原文の記述を与えることを意図します。 Status-コードは使用のためにオートマトンで意図します、そして、Reason-句は人間のユーザのために意図します。 クライアントは、Reason-句を調べるか、または表示する必要はありません。
Berners-Lee, et al Informational [Page 26] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[26ページ]RFC1945HTTP/1996年5月1日
The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. There are 5 values for the first digit:
Status-コードの最初のケタは応答のクラスを定義します。 下2ケタには、どんな分類の役割もありません。 最初のケタのための5つの値があります:
o 1xx: Informational - Not used, but reserved for future use
o 1xx: 情報、使用されませんが、今後の使用のために、予約されます。
o 2xx: Success - The action was successfully received,
understood, and accepted.
o 2xx: 成功--動作を首尾よく受けて、理解して、受け入れました。
o 3xx: Redirection - Further action must be taken in order to
complete the request
o 3xx: リダイレクション--要求を終了するためにさらなる行動を取らなければなりません。
o 4xx: Client Error - The request contains bad syntax or cannot
be fulfilled
o 4xx: クライアントError--要求が、誤りのある構文を含んでいるか、または実現できません。
o 5xx: Server Error - The server failed to fulfill an apparently
valid request
o 5xx: サーバError--サーバは明らかに有効な要求を実現させませんでした。
The individual values of the numeric status codes defined for HTTP/1.0, and an example set of corresponding Reason-Phrase's, are presented below. The reason phrases listed here are only recommended -- they may be replaced by local equivalents without affecting the protocol. These codes are fully defined in Section 9.
以下でHTTP/1.0のために定義された数値ステータスコードの個人価値、および対応する句のReasonものの例のセットを寄贈します。 ここにリストアップされた句がお勧めであるだけである理由--プロトコルに影響しないで、それらを地方の同等物に取り替えるかもしれません。 これらのコードはセクション9で完全に定義されます。
Status-Code = "200" ; OK
| "201" ; Created
| "202" ; Accepted
| "204" ; No Content
| "301" ; Moved Permanently
| "302" ; Moved Temporarily
| "304" ; Not Modified
| "400" ; Bad Request
| "401" ; Unauthorized
| "403" ; Forbidden
| "404" ; Not Found
| "500" ; Internal Server Error
| "501" ; Not Implemented
| "502" ; Bad Gateway
| "503" ; Service Unavailable
| extension-code
ステータスコード=「200」。 OK| "201" ; 作成されます。| "202" ; 受け入れます。| "204" ; 内容がありません。| "301" ; 永久に、移行します。| "302" ; 一時、移行します。| "304" ; 変更されません。| "400" ; 悪い要求| "401" ; 権限のない| "403" ; 禁じられます。| "404" ; 見つけられません。| "500" ; 内部サーバーエラー| "501" ; 実装されません。| "502" ; 悪いゲートウェイ| "503" ; 入手できないサービス| 拡張コード
extension-code = 3DIGIT
拡張コード=3DIGIT
Reason-Phrase = *<TEXT, excluding CR, LF>
CR、LF>を除いた理由句の=*<TEXT
HTTP status codes are extensible, but the above codes are the only ones generally recognized in current practice. HTTP applications are not required to understand the meaning of all registered status
HTTPステータスコードは広げることができますが、上のコードは一般に、実際には現在の認識された唯一のものです。 HTTPアプリケーションは、すべての登録された状態の意味を理解するのに必要ではありません。
Berners-Lee, et al Informational [Page 27] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[27ページ]RFC1945HTTP/1996年5月1日
codes, though such understanding is obviously desirable. However, applications must understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent to the x00 status code of that class, with the exception that an unrecognized response must not be cached. For example, if an unrecognized status code of 431 is received by the client, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 status code. In such cases, user agents should present to the user the entity returned with the response, since that entity is likely to include human-readable information which will explain the unusual status.
そのような理解は明らかに望ましいのですが、コード化します。 しかしながら、アプリケーションは、最初のケタによって示されるようにどんなステータスコードのクラスも理解して、認識されていない応答が例外があるそのクラスのステータスコードであるに違いありませんが、x00に同等であるとしてキャッシュされていた状態でどんな認識されていない応答も扱わなければなりません。 例えば、431の認識されていないステータスコードがクライアントによって受け取られるなら、それは、まるで400ステータスコードを受け取ったかのように要求には不具合があったと安全に仮定して、応答を扱うことができます。 そのような場合、ユーザエージェントは応答と共に返された実体をユーザに提示するべきです、その実体が珍しい状態がわかる人間が読める情報を含んでいそうであるので。
6.2 Response Header Fields
6.2 応答ヘッダーフィールド
The response header fields allow the server to pass additional information about the response which cannot be placed in the Status- Line. These header fields give information about the server and about further access to the resource identified by the Request-URI.
応答ヘッダーフィールドで、サーバはStatus線に置くことができない応答に関する追加情報を通過できます。 これらのヘッダーフィールドはサーバの周りと、そして、Request-URIによって特定されたリソースへのさらなるアクセスの周りに関して知らせます。
Response-Header = Location ; Section 10.11
| Server ; Section 10.14
| WWW-Authenticate ; Section 10.16
応答ヘッダは位置と等しいです。 セクション10.11| サーバ。 セクション10.14| WWW認証します。 セクション10.16
Response-Header field names can be extended reliably only in
combination with a change in the protocol version. However, new or
experimental header fields may be given the semantics of response
header fields if all parties in the communication recognize them to
be response header fields. Unrecognized header fields are treated as
Entity-Header fields.
単にプロトコルバージョンにおける変化と組み合わせて応答ヘッダーフィールド名を確かに広げることができます。 しかしながら、コミュニケーションにおけるすべてのパーティーが、彼らが応答ヘッダーフィールドであると認めるなら、応答ヘッダーフィールドの意味論を新しいか実験しているヘッダーフィールドに与えるかもしれません。 認識されていないヘッダーフィールドはEntity-ヘッダーフィールドとして扱われます。
7. Entity
7. 実体
Full-Request and Full-Response messages may transfer an entity within some requests and responses. An entity consists of Entity-Header fields and (usually) an Entity-Body. In this section, both sender and recipient refer to either the client or the server, depending on who sends and who receives the entity.
完全な要求とFull-応答メッセージはいくつかの要求と応答の中で実体を移すかもしれません。 実体はEntity-ヘッダーフィールドと(通常)Entity-ボディーから成ります。 このセクションで、送付者と受取人の両方がクライアントかサーバのどちらかについて言及します、だれが発信するか、そして、だれが実体を受けるかによって。
Berners-Lee, et al Informational [Page 28] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[28ページ]RFC1945HTTP/1996年5月1日
7.1 Entity Header Fields
7.1 実体ヘッダーフィールド
Entity-Header fields define optional metainformation about the Entity-Body or, if no body is present, about the resource identified by the request.
実体ヘッダーフィールドがEntity-ボディーに関して任意のmetainformationを定義するか、またはボディーはいいえなら存在しています、要求で特定されたリソースに関して。
Entity-Header = Allow ; Section 10.1
| Content-Encoding ; Section 10.3
| Content-Length ; Section 10.4
| Content-Type ; Section 10.5
| Expires ; Section 10.7
| Last-Modified ; Section 10.10
| extension-header
=が許容する実体ヘッダー。 セクション10.1| 内容をコード化しています。 セクション10.3| コンテンツの長さ。 セクション10.4| コンテントタイプ。 セクション10.5| 期限が切れます。 セクション10.7| 最終更新日。 セクション10.10| 拡張ヘッダー
extension-header = HTTP-header
拡張ヘッダーはHTTPヘッダと等しいです。
The extension-header mechanism allows additional Entity-Header fields to be defined without changing the protocol, but these fields cannot be assumed to be recognizable by the recipient. Unrecognized header fields should be ignored by the recipient and forwarded by proxies.
拡張ヘッダーメカニズムは、追加Entity-ヘッダーフィールドがプロトコルを変えないで定義されるのを許容しますが、受取人が認識可能であるとこれらの分野を思うことができません。 認識されていないヘッダーフィールドは、受取人によって無視されて、プロキシによって進められるべきです。
7.2 Entity Body
7.2 実体本体
The entity body (if any) sent with an HTTP request or response is in a format and encoding defined by the Entity-Header fields.
Entity-ヘッダーフィールドによって定義された書式とコード化にはHTTP要求か応答と共に送られた実体本体(もしあれば)があります。
Entity-Body = *OCTET
実体本体=*八重奏
An entity body is included with a request message only when the request method calls for one. The presence of an entity body in a request is signaled by the inclusion of a Content-Length header field in the request message headers. HTTP/1.0 requests containing an entity body must include a valid Content-Length header field.
要求メソッドが1を求めるときだけ、実体本体は要求メッセージで含まれています。 要求メッセージヘッダーでのContent-長さのヘッダーフィールドの包含で要求における、実体本体の存在は合図されます。 実体本体を含むHTTP/1.0の要求が有効なContent-長さのヘッダーフィールドを含まなければなりません。
For response messages, whether or not an entity body is included with a message is dependent on both the request method and the response code. All responses to the HEAD request method must not include a body, even though the presence of entity header fields may lead one to believe they do. All 1xx (informational), 204 (no content), and 304 (not modified) responses must not include a body. All other responses must include an entity body or a Content-Length header field defined with a value of zero (0).
実体本体が含まれているか否かに関係なく、メッセージと共に、応答メッセージに、要求メソッドと応答コードの両方の扶養家族は賛成しています。 HEADへのすべての応答が、メソッドがボディーを含んではいけないよう要求します、実体ヘッダーフィールドの存在は、人が、そうすると信じているように導くかもしれませんが。 すべての1xx(情報の)、204(内容がない)、および304(変更されない)の応答がボディーを含んではいけません。 他のすべての応答がヘッダーフィールドが(0)がない値で定義した実体本体かContent-長さを含まなければなりません。
7.2.1 Type
7.2.1 タイプ
When an Entity-Body is included with a message, the data type of that body is determined via the header fields Content-Type and Content- Encoding. These define a two-layer, ordered encoding model:
Entity-ボディーがメッセージで含まれているとき、そのボディーのデータ型はヘッダーフィールドコンテントタイプとContentコード化を通して決定しています。 これらはモデルをコード化しながら注文された2層を定義します:
Berners-Lee, et al Informational [Page 29] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[29ページ]RFC1945HTTP/1996年5月1日
entity-body := Content-Encoding( Content-Type( data ) )
実体本体:=内容コード化(コンテントタイプ(データ))
A Content-Type specifies the media type of the underlying data. A Content-Encoding may be used to indicate any additional content coding applied to the type, usually for the purpose of data compression, that is a property of the resource requested. The default for the content encoding is none (i.e., the identity function).
コンテントタイプは基本的なデータのメディアタイプを指定します。 Content-コード化はどんな追加満足しているコード化もタイプに適用されたのを示すのに使用されるかもしれません、すなわち、通常データ圧縮の目的、要求されたリソースの特性のために。 満足しているコード化のためのデフォルトはなし(すなわち、アイデンティティ機能)です。
Any HTTP/1.0 message containing an entity body should include a Content-Type header field defining the media type of that body. If and only if the media type is not given by a Content-Type header, as is the case for Simple-Response messages, the recipient may attempt to guess the media type via inspection of its content and/or the name extension(s) of the URL used to identify the resource. If the media type remains unknown, the recipient should treat it as type "application/octet-stream".
実体本体を含むどんなHTTP/1.0メッセージもそのボディーのメディアタイプを定義するコンテントタイプヘッダーフィールドを含むべきです。 Simple-応答メッセージのためにそうであるようにコンテントタイプヘッダーがメディアタイプを与えない場合にだけ、受取人はメディアが内容の点検でタイプされると推測する試み、そして/または、拡大というリソースを特定するのに使用されるURLの名前を与えます。 メディアタイプが未知のままでいるなら、受取人はタイプ「八重奏アプリケーション/ストリーム」としてそれを扱うべきです。
7.2.2 Length
7.2.2 長さ
When an Entity-Body is included with a message, the length of that body may be determined in one of two ways. If a Content-Length header field is present, its value in bytes represents the length of the Entity-Body. Otherwise, the body length is determined by the closing of the connection by the server.
Entity-ボディーがメッセージで含まれているとき、そのボディーの長さは2つの方法の1つで決定しているかもしれません。 Content-長さのヘッダーフィールドが存在しているなら、バイトで表現される値はEntity-ボディーの長さを表します。 さもなければ、ボディーの長さはサーバによる接続の閉鎖によって測定されます。
Closing the connection cannot be used to indicate the end of a request body, since it leaves no possibility for the server to send back a response. Therefore, HTTP/1.0 requests containing an entity body must include a valid Content-Length header field. If a request contains an entity body and Content-Length is not specified, and the server does not recognize or cannot calculate the length from other fields, then the server should send a 400 (bad request) response.
要求本体の先を示すのに接続を終えるのを使用できません、サーバが応答を返送する可能性が全く残っていないので。 したがって、実体本体を含むHTTP/1.0の要求が有効なContent-長さのヘッダーフィールドを含まなければなりません。 要求が実体本体を含んでいるか、そして、Content-長さは指定されません、そして、サーバは指定されません。サーバは、他の分野からの長さについて認識できませんし、計算できないで、次に、400(悪い要求)応答を送るべきです。
Note: Some older servers supply an invalid Content-Length when
sending a document that contains server-side includes dynamically
inserted into the data stream. It must be emphasized that this
will not be tolerated by future versions of HTTP. Unless the
client knows that it is receiving a response from a compliant
server, it should not depend on the Content-Length value being
correct.
以下に注意してください。 それが含むドキュメントを送るとサーバ側がダイナミックに含むストリームがデータに挿入されたとき、いくつかの、より古いサーバが無効のContent-長さを供給します。 これがHTTPの将来のバージョンによって許容されないと強調しなければなりません。 クライアントが、対応するサーバから応答を受けているのを知らない場合、それは正しいContent-長さの値に依存するべきではありません。
8. Method Definitions
8. メソッド定義
The set of common methods for HTTP/1.0 is defined below. Although this set can be expanded, additional methods cannot be assumed to share the same semantics for separately extended clients and servers.
HTTP/1.0のための共通方法のセットは以下で定義されます。 このセットは膨張できますが、追加メソッドが別々に拡張しているクライアントとサーバのために同じ意味論を共有すると思うことができません。
Berners-Lee, et al Informational [Page 30] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[30ページ]RFC1945HTTP/1996年5月1日
8.1 GET
8.1は得られます。
The GET method means retrieve whatever information (in the form of an entity) is identified by the Request-URI. If the Request-URI refers to a data-producing process, it is the produced data which shall be returned as the entity in the response and not the source text of the process, unless that text happens to be the output of the process.
GETメソッドは、Request-URIによって特定されるどんな情報(実体の形の)も検索することを意味します。 Request-URIがデータを作り出すプロセスについて言及するなら、それはプロセスの原始テキストではなく、応答における実体として返されるものとする、生産されたデータです、そのテキストがたまたまプロセスの出力でないなら。
The semantics of the GET method changes to a "conditional GET" if the request message includes an If-Modified-Since header field. A conditional GET method requests that the identified resource be transferred only if it has been modified since the date given by the If-Modified-Since header, as described in Section 10.9. The conditional GET method is intended to reduce network usage by allowing cached entities to be refreshed without requiring multiple requests or transferring unnecessary data.
GETメソッドの意味論は、要求メッセージが以来変更されたIfヘッダーフィールドを含んでいるかどうかを「条件付きのGET」に変えます。 条件付きのGETメソッドは、以来変更されたIfヘッダーによって与えられた日付以来それが変更されている場合にだけ特定されたリソースが移されるよう要求します、セクション10.9で説明されるように。 キャッシュされた実体が複数の要求を必要とするか、または不要なデータを移さないでリフレッシュされるのを許容することによって条件付きのGETメソッドがネットワーク用法を減少させることを意図します。
8.2 HEAD
8.2 ヘッド
The HEAD method is identical to GET except that the server must not return any Entity-Body in the response. The metainformation contained in the HTTP headers in response to a HEAD request should be identical to the information sent in response to a GET request. This method can be used for obtaining metainformation about the resource identified by the Request-URI without transferring the Entity-Body itself. This method is often used for testing hypertext links for validity, accessibility, and recent modification.
サーバが応答でどんなEntity-ボディーも返してはいけないのを除いて、HEADメソッドはGETと同じです。 HEAD要求に対応してHTTPヘッダに含まれたmetainformationはGET要求に対応して送られた情報と同じであるべきです。 Request-URIによってEntity-ボディー自体を移さないで特定されたリソースに関してmetainformationを入手するのにこのメソッドを使用できます。 このメソッドは、正当性、アクセシビリティ、および最近の変更がないかどうかハイパーテキストリンクをテストするのにしばしば使用されます。
There is no "conditional HEAD" request analogous to the conditional GET. If an If-Modified-Since header field is included with a HEAD request, it should be ignored.
条件付きのGETへの類似のどんな「条件付きのHEAD」要求もありません。 以来変更されたIfヘッダーフィールドがHEAD要求で含まれているなら、それは無視されるべきです。
8.3 POST
8.3 ポスト
The POST method is used to request that the destination server accept the entity enclosed in the request as a new subordinate of the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following functions:
ポストメソッドは、目的地サーバがリソースの新しい部下がRequest-線のRequest-URIで特定したように要求に同封された実体を受け入れるよう要求するのに使用されます。 ポストは以下の機能をカバーする一定のメソッドを許容するように設計されています:
o Annotation of existing resources;
o 既存のリソースの注釈。
o Posting a message to a bulletin board, newsgroup, mailing list,
or similar group of articles;
o 記事の掲示板、ニュースグループ、メーリングリスト、または同様のグループにメッセージを掲示します。
o Providing a block of data, such as the result of submitting a
form [3], to a data-handling process;
o フォーム[3]を提出するという結果などのデータハンドリングプロセスに1ブロックのデータを提供します。
o Extending a database through an append operation.
o データベースを広げている、操作を追加してください。
Berners-Lee, et al Informational [Page 31] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[31ページ]RFC1945HTTP/1996年5月1日
The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI. The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
ポストメソッドで実行された実際の関数は、サーバで決定して、通常、Request-URIに依存しています。 掲示された実体がそれを含むディレクトリに下位で同じようにファイルがそうであるそのURIを従属することである、ニュース記事がそれが掲示されるニュースグループに下位です、または記録はデータベースに下位です。
A successful POST does not require that the entity be created as a resource on the origin server or made accessible for future reference. That is, the action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either 200 (ok) or 204 (no content) is the appropriate response status, depending on whether or not the response includes an entity that describes the result.
うまくいっているポストは、実体をリソースとして発生源サーバで作成するか、または後日のためにアクセスしやすくするのを必要としません。 すなわち、ポストメソッドで実行された動作はURIで特定できるリソースをもたらさないかもしれません。 この場合、どちらかの200(OK)か204(内容がない)が適切な応答状態です、応答が結果について説明する実体を含んでいるかどうかによって。
If a resource has been created on the origin server, the response should be 201 (created) and contain an entity (preferably of type "text/html") which describes the status of the request and refers to the new resource.
発生源サーバでリソースを作成してあるなら、応答は、201(作成される)であり、要求の状態について説明して、新しいリソースを示す実体(望ましくはタイプ「テキスト/html」の)を含むべきです。
A valid Content-Length is required on all HTTP/1.0 POST requests. An HTTP/1.0 server should respond with a 400 (bad request) message if it cannot determine the length of the request message's content.
有効なContent-長さがすべてのHTTP/1.0のポストの要求のときに必要です。 要求メッセージの内容の長さを測定できないなら、HTTP/1.0サーバは400(悪い要求)メッセージで反応するべきです。
Applications must not cache responses to a POST request because the application has no way of knowing that the server would return an equivalent response on some future request.
アプリケーションにはサーバが何らかの今後の要求のときに同等な応答を返すのを知る方法が全くないので、アプリケーションはポストの要求への応答をキャッシュしてはいけません。
9. Status Code Definitions
9. ステータスコード定義
Each Status-Code is described below, including a description of which method(s) it can follow and any metainformation required in the response.
各Status-コードは以下で説明されます、それがどのメソッドに従うことができるかに関する記述と応答で必要であるmetainformationを含んでいて。
9.1 Informational 1xx
9.1 情報の1xx
This class of status code indicates a provisional response, consisting only of the Status-Line and optional headers, and is terminated by an empty line. HTTP/1.0 does not define any 1xx status codes and they are not a valid response to a HTTP/1.0 request. However, they may be useful for experimental applications which are outside the scope of this specification.
このクラスのステータスコードは、Status-線と任意のヘッダーだけから成って、暫定的な応答を示して、空の系列によって終えられます。 HTTP/1.0は少しの1xxステータスコードも定義しません、そして、それらはHTTP/1.0要求への有効回答ではありません。 しかしながら、それらはこの仕様の範囲の外にある実験用利用の役に立つかもしれません。
9.2 Successful 2xx
9.2 うまくいっている2xx
This class of status code indicates that the client's request was successfully received, understood, and accepted.
このクラスのステータスコードは、クライアントの要求が首尾よく受け取られて、理解されて、受け入れられたのを示します。
Berners-Lee, et al Informational [Page 32] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[32ページ]RFC1945HTTP/1996年5月1日
200 OK
200 OK
The request has succeeded. The information returned with the response is dependent on the method used in the request, as follows:
要求は成功しました。 応答と共に返された情報は以下の通り要求で使用されるメソッドに依存しています:
GET an entity corresponding to the requested resource is sent
in the response;
要求されたリソースに対応する実体が応答で送られるGET。
HEAD the response must only contain the header information and
no Entity-Body;
HEAD、ヘッダー情報を含んでいますが、応答はどんなEntity-ボディーも含むだけでよくはありません。
POST an entity describing or containing the result of the action.
ポスト、動作の結果を説明するか、または含む実体。
201 Created
作成された201
The request has been fulfilled and resulted in a new resource being created. The newly created resource can be referenced by the URI(s) returned in the entity of the response. The origin server should create the resource before using this Status-Code. If the action cannot be carried out immediately, the server must include in the response body a description of when the resource will be available; otherwise, the server should respond with 202 (accepted).
要求は、実現して作成される新しいリソースとなっています。 応答の実体で返されたURIは新たに作成されたリソースに参照をつけることができます。 このStatus-コードを使用する前に、発生源サーバはリソースを作成するべきです。 すぐに動作を行うことができないなら、サーバは応答本体にリソースが利用可能になる時に関する記述を含まなければなりません。 さもなければ、サーバは202(受け入れる)で反応するべきです。
Of the methods defined by this specification, only POST can create a resource.
この仕様で定義されたメソッドでは、ポストだけがリソースを作成できます。
202 Accepted
202は受け入れました。
The request has been accepted for processing, but the processing has not been completed. The request may or may not eventually be acted upon, as it may be disallowed when processing actually takes place. There is no facility for re-sending a status code from an asynchronous operation such as this.
処理のために要求を受け入れましたが、処理を終了していません。 処理が実際に行われるとき、それが禁じられるとき、要求は結局、実行されるかもしれません。 これなどの非同期動作からステータスコードを再送するための施設が全くありません。
The 202 response is intentionally non-committal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The entity returned with this response should include an indication of the request's current status and either a pointer to a status monitor or some estimate of when the user can expect the request to be fulfilled.
202応答は故意にどっちつかずです。 目的は過程が完了するまでサーバとのユーザエージェントの接続が固執する必要でないサーバがある他のプロセス(恐らく1日に一度実行されるだけであるバッチ指向のプロセス)のために申し込みに応じるのを許容することです。 この応答と共に返された実体は要求の現在の状態のしるしと状態モニターへの指針かユーザが実現するという要求を予想できる時に関する何らかの見積りのどちらかを含むべきです。
204 No Content
204 内容がありません。
The server has fulfilled the request but there is no new information to send back. If the client is a user agent, it should not change its document view from that which caused the request to
サーバは要求を実現させましたが、返送する新情報が全くありません。 クライアントがユーザエージェントであるなら、それは要求を引き起こしたそれからドキュメント意見を変えるべきではありません。
Berners-Lee, et al Informational [Page 33] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[33ページ]RFC1945HTTP/1996年5月1日
be generated. This response is primarily intended to allow input for scripts or other actions to take place without causing a change to the user agent's active document view. The response may include new metainformation in the form of entity headers, which should apply to the document currently in the user agent's active view.
生成されてください。 主として、この応答がスクリプトか他の動作がユーザエージェントの作業中の文書視点への変化を引き起こさないで行われるために入力を許すことを意図します。 応答は実体ヘッダーの形に新しいmetainformationを含むかもしれません。(ヘッダーは現在ユーザエージェントのアクティブな意見でドキュメントに適用するべきです)。
9.3 Redirection 3xx
9.3 リダイレクション3xx
This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. The action required may be carried out by the user agent without interaction with the user if and only if the method used in the subsequent request is GET or HEAD. A user agent should never automatically redirect a request more than 5 times, since such redirections usually indicate an infinite loop.
このクラスのステータスコードは、さらなる動作が、要求を実現させるためにユーザエージェントによって取られる必要であるのを示します。 必要な行動がユーザとの相互作用なしでユーザエージェントによって行われるかもしれない、その後の要求で中古のメソッドである場合にだけ、GETかHEADがそうです。 ユーザエージェントは自動的に5回以上の要求を決して向け直すべきではありません、そのようなリダイレクションが通常無限ループを示すので。
300 Multiple Choices
300の選択式
This response code is not directly used by HTTP/1.0 applications, but serves as the default for interpreting the 3xx class of responses.
この応答コードは、HTTP/1.0のアプリケーションで直接使用されませんが、応答の3xxのクラスを解釈するためのデフォルトとして機能します。
The requested resource is available at one or more locations. Unless it was a HEAD request, the response should include an entity containing a list of resource characteristics and locations from which the user or user agent can choose the one most appropriate. If the server has a preferred choice, it should include the URL in a Location field; user agents may use this field value for automatic redirection.
要求されたリソースは複数の位置で利用可能です。 それがHEAD要求でないなら、応答はユーザかユーザエージェントが最も適切な状態でものを選ぶことができるリソースの特性と位置のリストを含む実体を含んでいるでしょうに。 サーバに都合のよい選択があるなら、Location分野にURLを含むべきです。 ユーザエージェントは自動リダイレクションにこの分野値を使用するかもしれません。
301 Moved Permanently
301は永久に、移行しました。
The requested resource has been assigned a new permanent URL and any future references to this resource should be done using that URL. Clients with link editing capabilities should automatically relink references to the Request-URI to the new reference returned by the server, where possible.
新しい永久的なURLを要求されたリソースに割り当ててあります、そして、このリソースのどんな後学もそのURLを使用し終わるべきです。 連係編集能力があるクライアントはサーバによって可能であるところに返された新しい参照へのRequest-URIの自動的にrelinkな参照がそうするべきです。
The new URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URL.
応答におけるLocation分野で新しいURLを与えなければなりません。 それがHEAD要求でないなら、応答のEntity-ボディーは新しいURLにハイパーリンクがある短いメモを含むでしょうに。
If the 301 status code is received in response to a request using the POST method, the user agent must not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
ポストメソッドを使用することで要求に対応して301ステータスコードを受け取って、ユーザがそれを確認できないなら、ユーザエージェントは自動的に要求を向け直してはいけません、これが要求が出された状態を変えるかもしれないので。
Berners-Lee, et al Informational [Page 34] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[34ページ]RFC1945HTTP/1996年5月1日
Note: When automatically redirecting a POST request after
receiving a 301 status code, some existing user agents will
erroneously change it into a GET request.
以下に注意してください。 301ステータスコードを受け取った後に自動的にポストの要求を向け直すとき、何人かの既存のユーザエージェントが誤ってそれをGET要求に変えるでしょう。
302 Moved Temporarily
302は一時移行しました。
The requested resource resides temporarily under a different URL. Since the redirection may be altered on occasion, the client should continue to use the Request-URI for future requests.
要求されたリソースは異なったURLの下で仮住まいします。 リダイレクションが時々変更されるかもしれないので、クライアントは、今後の要求にRequest-URIを使用し続けるべきです。
The URL must be given by the Location field in the response. Unless it was a HEAD request, the Entity-Body of the response should contain a short note with a hyperlink to the new URI(s).
応答におけるLocation分野でURLを与えなければなりません。 それがHEAD要求でないなら、応答のEntity-ボディーは新しいURIにハイパーリンクがある短いメモを含むでしょうに。
If the 302 status code is received in response to a request using the POST method, the user agent must not automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
ポストメソッドを使用することで要求に対応して302ステータスコードを受け取って、ユーザがそれを確認できないなら、ユーザエージェントは自動的に要求を向け直してはいけません、これが要求が出された状態を変えるかもしれないので。
Note: When automatically redirecting a POST request after
receiving a 302 status code, some existing user agents will
erroneously change it into a GET request.
以下に注意してください。 302ステータスコードを受け取った後に自動的にポストの要求を向け直すとき、何人かの既存のユーザエージェントが誤ってそれをGET要求に変えるでしょう。
304 Not Modified
変更されなかった304
If the client has performed a conditional GET request and access is allowed, but the document has not been modified since the date and time specified in the If-Modified-Since field, the server must respond with this status code and not send an Entity-Body to the client. Header fields contained in the response should only include information which is relevant to cache managers or which may have changed independently of the entity's Last-Modified date. Examples of relevant header fields include: Date, Server, and Expires. A cache should update its cached entity to reflect any new field values given in the 304 response.
クライアントが条件付きのGET要求を実行して、アクセスが許されていますが、日時が以来変更されたIf分野で指定して以来ドキュメントが変更されていないなら、サーバは、このステータスコードで応じて、Entity-ボディーをクライアントに送ってはいけません。 応答に含まれたヘッダーフィールドはキャッシュマネージャに関連しているか、または独自に変化したかもしれない実体の最終更新日日付の情報を含んでいるだけであるべきです。 関連ヘッダーフィールドに関する例は: そして、日付、サーバ、期限が切れます。 キャッシュは、304応答で与えられたどんな新しい分野値も反映するためにキャッシュされた実体をアップデートするべきです。
9.4 Client Error 4xx
9.4 クライアント誤り4xx
The 4xx class of status code is intended for cases in which the client seems to have erred. If the client has not completed the request when a 4xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method.
ステータスコードの4xxのクラスはクライアントが間違えたように思える場合のために意図します。 4xxコードが受け取られているとき、クライアントが要求を終了していないなら、それは、すぐに、データをサーバに送るのをやめるべきです。HEAD要求に応じる時を除いて、サーバはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含む実体を含むべきです。 これらのステータスコードはどんな要求メソッドにも適切です。
Berners-Lee, et al Informational [Page 35] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[35ページ]RFC1945HTTP/1996年5月1日
Note: If the client is sending data, server implementations on TCP
should be careful to ensure that the client acknowledges receipt
of the packet(s) containing the response prior to closing the
input connection. If the client continues sending data to the
server after the close, the server's controller will send a reset
packet to the client, which may erase the client's unacknowledged
input buffers before they can be read and interpreted by the HTTP
application.
以下に注意してください。 クライアントがデータを送るなら、TCPの上のサーバ実装は入力接続を終える前に応答を含んで、クライアントがパケットの領収書を受け取ったことを知らせるのを保証するのに慎重であるはずです。 クライアントが、閉鎖の後にデータをサーバに送り続けていると、サーバのコントローラはリセットパケットをクライアントに送るでしょう。(HTTPアプリケーションでそれらを読んで、解釈できる前にそのクライアントは、クライアントの不承認の入力バッファを消すかもしれません)。
400 Bad Request
400の悪い要求
The request could not be understood by the server due to malformed syntax. The client should not repeat the request without modifications.
奇形の構文のためサーバに要求を解釈できませんでした。 クライアントは変更なしで要求を繰り返すべきではありません。
401 Unauthorized
401、権限のなさ
The request requires user authentication. The response must include a WWW-Authenticate header field (Section 10.16) containing a challenge applicable to the requested resource. The client may repeat the request with a suitable Authorization header field (Section 10.2). If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user should be presented the entity that was given in the response, since that entity may include relevant diagnostic information. HTTP access authentication is explained in Section 11.
要求はユーザー認証を必要とします。 応答は包含しなければなりません。要求されたリソースに適切な挑戦を含んでいて、aはヘッダーフィールド(セクション10.16)をWWW認証します。 クライアントは適当なAuthorizationヘッダーフィールド(セクション10.2)で要求を繰り返すかもしれません。 要求が既にAuthorization資格証明書を含んだなら、401応答は、承認がそれらの資格証明書のために拒否されたのを示します。 401応答が先の応答と同じ挑戦を含んでいて、ユーザエージェントが少なくとも一度既に認証を試みたことがあるなら、応答で与えられた実体はユーザに提示されるべきです、その実体が関連診断情報を含むかもしれないので。 HTTPアクセス認証はセクション11で説明されます。
403 Forbidden
禁じられた403
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request should not be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it should describe the reason for the refusal in the entity body. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
サーバは、要求を理解していますが、それを実現させるのを拒否しています。 承認は助けないでしょう、そして、要求を繰り返すべきではありません。 要求メソッドがHEADでなく、サーバが要求が実現していない理由を公表したいなら、それは実体本体での拒否の理由について説明するべきです。 サーバが、要求がちょうどなぜ拒否されたか、そして、または他のどんな応答もいつ適切でないかを明らかにしたがっていないとき、このステータスコードは一般的に使用されます。
404 Not Found
見つけられなかった404
The server has not found anything matching the Request-URI. No indication is given of whether the condition is temporary or permanent. If the server does not wish to make this information available to the client, the status code 403 (forbidden) can be used instead.
サーバは、何もRequest-URIに合っているのがわかっていません。 状態が一時的であるか、または永久的であるかを指示を全く与えません。 この情報がサーバでクライアントにとって利用可能になりたいと思わないなら、代わりに、ステータスコード403(禁じられます)を使用できます。
Berners-Lee, et al Informational [Page 36] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[36ページ]RFC1945HTTP/1996年5月1日
9.5 Server Error 5xx
9.5 サーバ誤り5xx
Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. If the client has not completed the request when a 5xx code is received, it should immediately cease sending data to the server. Except when responding to a HEAD request, the server should include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. These response codes are applicable to any request method and there are no required header fields.
応答状態はケタで、「5インチはサーバがそれが間違えたのを意識しているか、または要求を実行できない場合を示す」始めをコード化します。 5xxコードが受け取られているとき、クライアントが要求を終了していないなら、それは、すぐに、データをサーバに送るのをやめるべきです。HEAD要求に応じる時を除いて、サーバはエラー状態とそれが一時的であるか永久的な状態であるかどうかに関する説明を含む実体を含むべきです。 これらの応答コードはどんな要求メソッドにも適切です、そして、どんな必要なヘッダーフィールドもありません。
500 Internal Server Error
500 内部サーバーエラー
The server encountered an unexpected condition which prevented it from fulfilling the request.
サーバはそれが要求を実現させるのを防いだ予期していなかった状態に遭遇しました。
501 Not Implemented
実装されなかった501
The server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
サーバは要求を実現させるのに必要である機能性をサポートしません。 これは、サーバが要求メソッドを認識しないときの適切な応答であり、どんなリソースのためにもそれをサポートすることができません。
502 Bad Gateway
502 悪いゲートウェイ
The server, while acting as a gateway or proxy, received an invalid response from the upstream server it accessed in attempting to fulfill the request.
サーバはゲートウェイかプロキシとして務めている間、要求を実現させるのを試みる際にそれがアクセスした上流のサーバから無効回答を受けました。
503 Service Unavailable
入手できない503サービス
The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication is that this is a temporary condition which will be alleviated after some delay.
サーバは現在、サーバの一時的な積みすぎかメインテナンスのため要求を扱うことができません。含意はこれが少し遅れてから軽減される一時的な病態であるということです。
Note: The existence of the 503 status code does not imply
that a server must use it when becoming overloaded. Some
servers may wish to simply refuse the connection.
以下に注意してください。 503ステータスコードの存在は、積みすぎられるようになるとき、サーバがそれを使用しなければならないのを含意しません。 いくつかのサーバが単に接続を拒否したがっているかもしれません。
10. Header Field Definitions
10. ヘッダーフィールド定義
This section defines the syntax and semantics of all commonly used HTTP/1.0 header fields. For general and entity header fields, both sender and recipient refer to either the client or the server, depending on who sends and who receives the message.
このセクションは構文を定義します、そして、すべての意味論は一般的にHTTP/1.0のヘッダーフィールドを使用しました。 一般と実体ヘッダーフィールドについて、送付者と受取人の両方がクライアントかサーバのどちらかについて言及します、だれが発信するか、そして、だれがメッセージを受け取るかによって。
Berners-Lee, et al Informational [Page 37] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[37ページ]RFC1945HTTP/1996年5月1日
10.1 Allow
10.1は許容します。
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. The Allow header field is not permitted in a request using the POST method, and thus should be ignored if it is received as part of a POST entity.
Allow実体ヘッダーフィールドはRequest-URIによって特定されたリソースによってサポートされたメソッドのセットを記載します。 この分野の目的はリソースに関連している有効なメソッドについて厳密に受取人に知らせることです。 Allowヘッダーフィールドを要求でポストメソッドを使用することで受入れないで、その結果、ポスト実体の一部としてそれを受け取るなら、無視するべきです。
Allow = "Allow" ":" 1#method
「=「許容」を許してください」:、」 1#メソッド
Example of use:
使用に関する例:
Allow: GET, HEAD
許容します: ヘッドは得てください。
This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value should be followed. The actual set of allowed methods is defined by the origin server at the time of each request.
この分野のために、クライアントは他のメソッドを試みることができません。 しかしながら、Allowヘッダーフィールド価値によって与えられた指摘は続かれるべきです。 実際の許容メソッドは各要求時点で、発生源サーバによって定義されます。
A proxy must not modify the Allow header field even if it does not understand all the methods specified, since the user agent may have other means of communicating with the origin server.
すべてのメソッドが指定したのを理解していなくても、プロキシはAllowヘッダーフィールドを変更してはいけません、ユーザエージェントには発生源サーバとコミュニケートする他の手段があるかもしれないので。
The Allow header field does not indicate what methods are implemented by the server.
Allowヘッダーフィールドは、どんなメソッドがサーバによって実装されるかを示しません。
10.2 Authorization
10.2 承認
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization request-header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
サーバで通常それ自体を認証しますが、401応答--要求でAuthorization要求ヘッダーフィールドを含んでいることによってそうするかもしれないのを受けた後に必ず認証したがっているというわけではないユーザエージェント。 Authorization分野価値は要求されているリソースの分野にユーザエージェントの認証情報を含む資格証明書から成ります。
Authorization = "Authorization" ":" credentials
「承認=「承認」」:、」 資格証明書
HTTP access authentication is described in Section 11. If a request is authenticated and a realm specified, the same credentials should be valid for all other requests within this realm.
HTTPアクセス認証はセクション11で説明されます。 要求が認証されて、分野が指定するなら、この分野の中の他のすべての要求に、同じ資格証明書は有効でしょうに。
Responses to requests containing an Authorization field are not cachable.
Authorization分野を含む要求への応答はキャッシュ可能ではありません。
Berners-Lee, et al Informational [Page 38] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[38ページ]RFC1945HTTP/1996年5月1日
10.3 Content-Encoding
10.3 内容コード化
The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content coding has been applied to the resource, and thus what decoding mechanism must be applied in order to obtain the media-type referenced by the Content-Type header field. The Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
Contentをコード化している実体ヘッダーフィールドは修飾語としてメディアタイプに使用されます。 プレゼント、値は、いつ追加満足しているコード化が何であるかをリソースに適用されていた状態で示すか、そして、その結果、コンテントタイプヘッダーフィールドによって参照をつけられるメディアタイプを得るためにどんな解読メカニズムを申し込まなければなりませんか? Content-コード化は、ドキュメントが基本的なメディアタイプのアイデンティティを失わないで圧縮されるのを許容するのに主として使用されます。
Content-Encoding = "Content-Encoding" ":" content-coding
「「内容コード化内容をコード化する=」」:、」 内容をコード化しています。
Content codings are defined in Section 3.5. An example of its use is
満足しているコーディングはセクション3.5で定義されます。 使用に関する例はそうです。
Content-Encoding: x-gzip
内容をコード化しています: x-gzip
The Content-Encoding is a characteristic of the resource identified by the Request-URI. Typically, the resource is stored with this encoding and is only decoded before rendering or analogous usage.
Content-コード化はRequest-URIによって特定されたリソースの特性です。 リソースは、通常、このコード化で保存されて、レンダリングか類似の用法の前に解読されるだけです。
10.4 Content-Length
10.4 コンテンツの長さ
The Content-Length entity-header field indicates the size of the Entity-Body, in decimal number of octets, sent to the recipient or, in the case of the HEAD method, the size of the Entity-Body that would have been sent had the request been a GET.
Content-長さの実体ヘッダーフィールドは、八重奏の10進数における、Entity-ボディーのサイズが受取人かHEADメソッドの場合における、要求がGETであったなら送られたEntity-ボディーのサイズに発信したのを示します。
Content-Length = "Content-Length" ":" 1*DIGIT
「コンテンツの長さは「コンテンツの長さ」と等しい」:、」 1*ケタ
An example is
例はそうです。
Content-Length: 3495
コンテンツの長さ: 3495
Applications should use this field to indicate the size of the Entity-Body to be transferred, regardless of the media type of the entity. A valid Content-Length field value is required on all HTTP/1.0 request messages containing an entity body.
アプリケーションは移すためにEntity-ボディーのサイズを示すのにこの分野を使用するべきです、実体のメディアタイプにかかわらず。 有効なContent-長さの分野価値が実体本体を含むすべてのHTTP/1.0の要求メッセージで必要です。
Any Content-Length greater than or equal to zero is a valid value. Section 7.2.2 describes how to determine the length of a response entity body if a Content-Length is not given.
どんなゼロ以上のContent-長さも有効値です。 セクション7.2 .2 Content-長さが与えられないなら、応答実体本体の長さを測定する方法を説明します。
Note: The meaning of this field is significantly different from
the corresponding definition in MIME, where it is an optional
field used within the "message/external-body" content-type. In
HTTP, it should be used whenever the entity's length can be
determined prior to being transferred.
以下に注意してください。 この分野の意味はMIMEとの対応する定義とかなり異なっています。(そこでは、それが「外部のメッセージ/ボディー」content typeの中で使用された任意の分野です)。 HTTPでは、移す前に実体の長さを測定できるときはいつも、それは使用されるべきです。
Berners-Lee, et al Informational [Page 39] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[39ページ]RFC1945HTTP/1996年5月1日
10.5 Content-Type
10.5 コンテントタイプ
The Content-Type entity-header field indicates the media type of the Entity-Body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET.
コンテントタイプ実体ヘッダーフィールドは、Entity-ボディーのメディアタイプが受取人かHEADメソッドの場合における要求がGETであったなら送られたメディアタイプに発信したのを示します。
Content-Type = "Content-Type" ":" media-type
「コンテントタイプは「コンテントタイプ」と等しい」:、」 メディアタイプ
Media types are defined in Section 3.6. An example of the field is
メディアタイプはセクション3.6で定義されます。 分野に関する例はそうです。
Content-Type: text/html
コンテントタイプ: テキスト/html
Further discussion of methods for identifying the media type of an entity is provided in Section 7.2.1.
実体のメディアタイプを特定するためのメソッドのさらなる議論をセクション7.2.1に提供します。
10.6 Date
10.6 日付
The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in Section 3.3.
Dateの一般的なヘッダーフィールドはメッセージが溯源された日時を表します、RFC822のorig-日付と同じ意味論を持っていて。 分野値はセクション3.3で説明されるようにHTTP日付です。
Date = "Date" ":" HTTP-date
「「日付」と=の日付を入れてください」:、」 HTTP日付
An example is
例はそうです。
Date: Tue, 15 Nov 1994 08:12:31 GMT
日付: グリニッジ標準時1994年11月15日火曜日8時12分31秒
If a message is received via direct connection with the user agent (in the case of requests) or the origin server (in the case of responses), then the date can be assumed to be the current date at the receiving end. However, since the date--as it is believed by the origin--is important for evaluating cached responses, origin servers should always include a Date header. Clients should only send a Date header field in messages that include an entity body, as in the case of the POST request, and even then it is optional. A received message which does not have a Date header field should be assigned one by the recipient if the message will be cached by that recipient or gatewayed via a protocol which requires a Date.
ユーザエージェント(要求の場合における)か発生源サーバ(応答の場合における)とのダイレクト関係でメッセージを受け取るなら、現在の期日の犠牲者に、あると日付を思うことができます。 しかしながら、キャッシュされた応答を評価するのに、それが発生源によって信じられているような期日が重要であるので、発生源サーバはいつもDateヘッダーを含むべきです。 クライアントは実体本体を含んでいるメッセージのDateヘッダーフィールドを送るだけであるべきです、それがポストの要求のケースと、その時でさえ任意であるので。 メッセージがその受取人によってキャッシュされるか、またはDateを必要とするプロトコルでgatewayedされるなら、1つは受取人によってDateヘッダーフィールドを持っていない受信されたメッセージに割り当てられるべきです。
In theory, the date should represent the moment just before the entity is generated. In practice, the date can be generated at any time during the message origination without affecting its semantic value.
理論上、実体が発生しているすぐ前に日付は瞬間を表すべきです。 実際には、意味値に影響しないで、いつでも、メッセージ創作の間、日付を生成することができます。
Note: An earlier version of this document incorrectly specified
that this field should contain the creation date of the enclosed
Entity-Body. This has been changed to reflect actual (and proper)
以下に注意してください。 このドキュメントの以前のバージョンは、この分野が同封のEntity-ボディーの作成日付を含むべきであると不当に指定しました。 実際状態で反射するためにこれを変えました。(適切)
Berners-Lee, et al Informational [Page 40] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[40ページ]RFC1945HTTP/1996年5月1日
usage.
用法。
10.7 Expires
10.7は期限が切れます。
The Expires entity-header field gives the date/time after which the entity should be considered stale. This allows information providers to suggest the volatility of the resource, or a date after which the information may no longer be valid. Applications must not cache this entity beyond the date given. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time. However, information providers that know or even suspect that a resource will change by a certain date should include an Expires header with that date. The format is an absolute date and time as defined by HTTP-date in Section 3.3.
Expires実体ヘッダーフィールドは実体が聞き古したである考えられるべきである日付/時を与えます。 これで、情報提供者はリソースの不安定さ、または情報がもう有効でないかもしれない日付を勧めることができます。 アプリケーションは与えられた日付にこの実体をキャッシュしてはいけません。 Expires分野の存在は、オリジナルのリソースが変化するのを含意もしませんし、その時の前かその時か、その時以降存在するのをやめもしません。 しかしながら、知っているか、またはリソースが決まった日までに変化すると疑いさえする情報提供者はその日付があるExpiresヘッダーを入れるべきです。 形式はセクション3.3のHTTP日付までに定義されるように絶対日時です。
Expires = "Expires" ":" HTTP-date
「=「期限が切れること」を吐き出す」:、」 HTTP日付
An example of its use is
使用に関する例はそうです。
Expires: Thu, 01 Dec 1994 16:00:00 GMT
期限が切れます: グリニッジ標準時1994年12月1日木曜日16時0分0秒
If the date given is equal to or earlier than the value of the Date header, the recipient must not cache the enclosed entity. If a resource is dynamic by nature, as is the case with many data- producing processes, entities from that resource should be given an appropriate Expires value which reflects that dynamism.
Dateヘッダーにおいて、期日等しいか値より与えられた前半であるなら、受取人は同封の実体をキャッシュしてはいけません。 リソースが生来ダイナミックであるなら、多くのデータがプロセスを生産しているケースのように、その力動説を反映する適切なExpires値をそのリソースからの実体に与えるべきです。
The Expires field cannot be used to force a user agent to refresh its display or reload a resource; its semantics apply only to caching mechanisms, and such mechanisms need only check a resource's expiration status when a new request for that resource is initiated.
ユーザエージェントにディスプレイをリフレッシュするか、またはリソースを再び積ませるのにExpires分野を使用できません。 意味論はメカニズムをキャッシュするだけに当てはまります、そして、そのリソースに関する新しい要求が開始されるとき、そのようなメカニズムはリソースの満了状態をチェックするだけでよいです。
User agents often have history mechanisms, such as "Back" buttons and history lists, which can be used to redisplay an entity retrieved earlier in a session. By default, the Expires field does not apply to history mechanisms. If the entity is still in storage, a history mechanism should display it even if the entity has expired, unless the user has specifically configured the agent to refresh expired history documents.
ユーザエージェントには、歴史メカニズムがしばしばあります、「逆」ボタンや履歴リストなどのように。(実体がセッションのときに前に検索した「再-ディスプレイ」に履歴リストを使用できます)。 デフォルトで、Expires分野は歴史メカニズムに適用されません。実体がまだストレージ中であるなら、実体が期限が切れたとしても、歴史メカニズムはそれを表示するはずです、ユーザが、リフレッシュするエージェントが歴史ドキュメントを吐き出したのを明確に構成していない場合。
Note: Applications are encouraged to be tolerant of bad or
misinformed implementations of the Expires header. A value of zero
(0) or an invalid date format should be considered equivalent to
an "expires immediately." Although these values are not legitimate
for HTTP/1.0, a robust implementation is always desirable.
以下に注意してください。 アプリケーションはExpiresヘッダーの悪いか誤伝された実装において許容性があるよう奨励されます。 (0)がない値か無効の日付の形式が相当していると考えられるべきである、「すぐに、期限が切れます」。 HTTP/1.0には、これらの値は正統ではありませんが、強健な実装はいつも望ましいです。
Berners-Lee, et al Informational [Page 41] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[41ページ]RFC1945HTTP/1996年5月1日
10.8 From
10.8
The From request-header field, if given, should contain an Internet e-mail address for the human user who controls the requesting user agent. The address should be machine-usable, as defined by mailbox in RFC 822 [7] (as updated by RFC 1123 [6]):
考えて、From要求ヘッダーフィールドは要求しているユーザエージェントを監督する人間のユーザへのインターネットEメールアドレスを含むべきです。 アドレスがメールボックスによってRFC822[7]で定義されるようにマシン使用可能であるべきである、(RFC1123[6])でアップデートするように:
From = "From" ":" mailbox
「=“From"」:、」 メールボックス
An example is:
例は以下の通りです。
From: webmaster@w3.org
From: webmaster@w3.org
This header field may be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It should not be used as an insecure form of access protection. The interpretation of this field is that the request is being performed on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents should include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving end.
このヘッダーフィールドは伐採目的と無効の、または、求められていない要求の源を特定するための手段として使用されるかもしれません。 不安定な形式のアクセス保護としてそれを使用するべきではありません。 この分野の解釈はメソッドが働いたので要求が与えられている人を代表して実行されているということです。その人は、責任を引き受けます。 特に、ロボットエージェントは、問題が受ける側になって起こるならロボットを動かすのに責任がある人に連絡できるようにこのヘッダーを入れるべきです。
The Internet e-mail address in this field may be separate from the Internet host which issued the request. For example, when a request is passed through a proxy, the original issuer's address should be used.
この分野のインターネット電子メールアドレスはインターネット・ホストから別々であるかもしれません(要求を出しました)。 要求がプロキシに通り抜けるとき、例えば、オリジナルの発行人のアドレスは使用されるべきです。
Note: The client should not send the From header field without the
user's approval, as it may conflict with the user's privacy
interests or their site's security policy. It is strongly
recommended that the user be able to disable, enable, and modify
the value of this field at any time prior to a request.
以下に注意してください。 クライアントはヘッダーフィールドからユーザの賛成なしで送るべきではありません、ユーザのプライバシー利益のためかそれらのサイトの安全保障政策と衝突するとき。 ユーザが要求の前にいつでもこの分野の値を無効にして、可能にして、変更できることが強く勧められます。
10.9 If-Modified-Since
10.9、以来、変更されます。
The If-Modified-Since request-header field is used with the GET method to make it conditional: if the requested resource has not been modified since the time specified in this field, a copy of the resource will not be returned from the server; instead, a 304 (not modified) response will be returned without any Entity-Body.
以来変更されたIf要求ヘッダーフィールドはそれを条件付きにするGETメソッドで使用されます: 時間がこの分野で指定して以来要求されたリソースが変更されていないと、リソースのコピーはサーバから返されないでしょう。 代わりに、少しもEntity-ボディーなしで304(変更されない)応答を返すでしょう。
If-Modified-Since = "If-Modified-Since" ":" HTTP-date
「= 以来変更されるなら「以来変更されるなら」」:、」 HTTP日付
An example of the field is:
分野に関する例は以下の通りです。
If-Modified-Since: Sat, 29 Oct 1994 19:43:31 GMT
以来変更されるなら: グリニッジ標準時1994年10月29日土曜日19時43分31秒
Berners-Lee, et al Informational [Page 42] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[42ページ]RFC1945HTTP/1996年5月1日
A conditional GET method requests that the identified resource be transferred only if it has been modified since the date given by the If-Modified-Since header. The algorithm for determining this includes the following cases:
条件付きのGETメソッドは、以来変更されたIfヘッダーによって与えられた日付以来それが変更されている場合にだけ特定されたリソースが移されるよう要求します。 これを決定するためのアルゴリズムは以下のケースを含んでいます:
a) If the request would normally result in anything other than
a 200 (ok) status, or if the passed If-Modified-Since date
is invalid, the response is exactly the same as for a
normal GET. A date which is later than the server's current
time is invalid.
a) 通常、要求が200(OK)状態以外の何かをもたらすだろうか、または通っている以来変更されたIf期日が無効であるなら、応答はまさに正常なGETのように同じです。 サーバの現在の時間より後半である期日は無効です。
b) If the resource has been modified since the
If-Modified-Since date, the response is exactly the same as
for a normal GET.
b) 以来変更されたIf日付以来リソースが変更されているなら、応答はまさに正常なGETのように同じです。
c) If the resource has not been modified since a valid
If-Modified-Since date, the server shall return a 304 (not
modified) response.
c) 有効な以来変更されたIf期日以来リソースが変更されていないなら、サーバは304(変更されない)応答を返すものとします。
The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead.
この特徴の目的は最小の量のトランザクションオーバーヘッドがあるキャッシュされた情報の効率的なアップデートを許すことです。
10.10 Last-Modified
10.10 最終更新日
The Last-Modified entity-header field indicates the date and time at which the sender believes the resource was last modified. The exact semantics of this field are defined in terms of how the recipient should interpret it: if the recipient has a copy of this resource which is older than the date given by the Last-Modified field, that copy should be considered stale.
最終更新日実体ヘッダーフィールドは、送付者がリソースを信じている日時が最後に変更されたのを示します。 受取人がどうそれを解釈するべきであるかに関してこの分野の正確な意味論は定義されます: 受取人に最終更新日分野によって与えられた日付より古いこのリソースのコピーがあるなら、そのコピーは聞き古したである考えられるべきです。
Last-Modified = "Last-Modified" ":" HTTP-date
「最終更新日は「最終更新日」と等しい」:、」 HTTP日付
An example of its use is
使用に関する例はそうです。
Last-Modified: Tue, 15 Nov 1994 12:45:26 GMT
最終更新日: グリニッジ標準時1994年11月15日火曜日12時45分26秒
The exact meaning of this header field depends on the implementation of the sender and the nature of the original resource. For files, it may be just the file system last-modified time. For entities with dynamically included parts, it may be the most recent of the set of last-modify times for its component parts. For database gateways, it may be the last-update timestamp of the record. For virtual objects, it may be the last time the internal state changed.
このヘッダーフィールドの正確な意味は送付者の実装とオリジナルのリソースの本質によります。 ファイルに関しては、まさしくファイルシステムが最後に時間を変更したということであるかもしれません。 それがダイナミックに含まれている部品がある実体のための、そうである、最新である、セット、コンポーネントが離れているので、最後に回を変更してください。 データベースゲートウェイに関しては、それは記録に関するアップデートタイムスタンプであるかもしれません。 仮想オブジェクトに関しては、内部の状態が変化した最後の時であるかもしれません。
An origin server must not send a Last-Modified date which is later than the server's time of message origination. In such cases, where the resource's last modification would indicate some time in the
発生源サーバはサーバのメッセージ創作の時間より後半である最終更新日期日を送ってはいけません。 変更が中にいつか、示すそのような場合。(そこでは、リソースが最後です)。
Berners-Lee, et al Informational [Page 43] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[43ページ]RFC1945HTTP/1996年5月1日
future, the server must replace that date with the message origination date.
未来、サーバはその日付をメッセージ創作日付に取り替えなければなりません。
10.11 Location
10.11 位置
The Location response-header field defines the exact location of the resource that was identified by the Request-URI. For 3xx responses, the location must indicate the server's preferred URL for automatic redirection to the resource. Only one absolute URL is allowed.
Location応答ヘッダ分野はRequest-URIによって特定されたリソースの正確な位置を定義します。 3xx応答のために、位置は自動リダイレクションのためのサーバの都合のよいURLをリソースに示さなければなりません。 1つの絶対URLだけが許容されています。
Location = "Location" ":" absoluteURI
「位置は「位置」と等しい」:、」 absoluteURI
An example is
例はそうです。
Location: http://www.w3.org/hypertext/WWW/NewLocation.html
位置: http://www.w3.org/hypertext/WWW/NewLocation.html
10.12 Pragma
10.12 Pragma
The Pragma general-header field is used to include implementation- specific directives that may apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems may require that behavior be consistent with the directives.
Pragmaの一般的なヘッダーフィールドは、要求/応答チェーンに沿ったどんな受取人にも適用されるかもしれない実装の特定の指示を含むのに使用されます。 すべてのpragma指示がプロトコルの観点から任意の振舞いを指定します。 しかしながら、いくつかのシステムが、振舞いが指示と一致しているのを必要とするかもしれません。
Pragma = "Pragma" ":" 1#pragma-directive
「Pragmaは"Pragma"と等しい」:、」 1#pragma-指示
pragma-directive = "no-cache" | extension-pragma
extension-pragma = token [ "=" word ]
pragma-指示=「キャッシュがありません」| 拡大-pragma拡大-pragmaはトークンと等しいです。[「=」単語]
When the "no-cache" directive is present in a request message, an application should forward the request toward the origin server even if it has a cached copy of what is being requested. This allows a client to insist upon receiving an authoritative response to its request. It also allows a client to refresh a cached copy which is known to be corrupted or stale.
「キャッシュがありません」指示が要求メッセージに存在しているとき、それに要求されているキャッシュされたコピーのものがあっても、アプリケーションは発生源サーバに向かって要求を転送するべきです。 これで、クライアントは、要求への正式の応答を受けると言い張ることができます。 それで、また、クライアントは、崩壊したのが知られているキャッシュされたコピーをリフレッシュするか、または古くさくなります。
Pragma directives must be passed through by a proxy or gateway application, regardless of their significance to that application, since the directives may be applicable to all recipients along the request/response chain. It is not possible to specify a pragma for a specific recipient; however, any pragma directive not relevant to a recipient should be ignored by that recipient.
プロキシかゲートウェイアプリケーションでPragma指示を通り抜けなければなりません、そのアプリケーションへのそれらの意味にかかわらず、指示が要求/応答チェーンに沿ったすべての受取人に適切であるかもしれないので。 特定の受取人にpragmaを指定するのは可能ではありません。 しかしながら、受取人に関連していないどんなpragma指示もその受取人によって無視されるべきです。
10.13 Referer
10.13 Referer
The Referer request-header field allows the client to specify, for the server's benefit, the address (URI) of the resource from which the Request-URI was obtained. This allows a server to generate lists
クライアントはReferer要求ヘッダーフィールドで指定できます、サーバの利益のために、Request-URIが得られたリソースのアドレス(URI)。 これで、サーバはリストを生成することができます。
Berners-Lee, et al Informational [Page 44] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[44ページ]RFC1945HTTP/1996年5月1日
of back-links to resources for interest, logging, optimized caching, etc. It also allows obsolete or mistyped links to be traced for maintenance. The Referer field must not be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard.
関心、伐採、最適化されたキャッシュなどのためのリソースへの逆リンクについて また、それは、時代遅れの、または、mistypedされたリンクがメインテナンスのためにたどられるのを許容します。 ユーザキーボードから入力されるようなそれ自身のURIを持っていないソースからRequest-URIを得たなら、Referer野原を送ってはいけません。
Referer = "Referer" ":" ( absoluteURI | relativeURI )
「Refererは"Referer"と等しい」:、」 (absoluteURI| relativeURI)
Example:
例:
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
Referer: http://www.w3.org/hypertext/DataSources/Overview.html
If a partial URI is given, it should be interpreted relative to the Request-URI. The URI must not include a fragment.
部分的なURIを与えるなら、Request-URIに比例してそれを解釈するべきです。 URIは断片を含んではいけません。
Note: Because the source of a link may be private information or
may reveal an otherwise private information source, it is strongly
recommended that the user be able to select whether or not the
Referer field is sent. For example, a browser client could have a
toggle switch for browsing openly/anonymously, which would
respectively enable/disable the sending of Referer and From
information.
以下に注意してください。 リンクの情報筋が個人情報であるかもしれないかそうでなければ、個人的な情報源を明らかにするかもしれないので、ユーザが、Referer野原が送られるかどうかを選択できることが強く勧められます。 例えば、ブラウザクライアントはオープンに匿名で/をブラウズするためのトグルスイッチを持つことができました。(それは、それぞれRefererとFrom情報の発信を可能にするか、または無効にするでしょう)。
10.14 Server
10.14 サーバ
The Server response-header field contains information about the software used by the origin server to handle the request. The field can contain multiple product tokens (Section 3.7) and comments identifying the server and any significant subproducts. By convention, the product tokens are listed in order of their significance for identifying the application.
Server応答ヘッダ分野は発生源サーバによって使用される、要求を扱うソフトウェアの情報を含んでいます。 分野は複数の製品トークン(セクション3.7)、サーバを特定するコメント、およびどんな重要な「副-製品」も含むことができます。 コンベンションによって、製品トークンはアプリケーションを特定するためのそれらの意味の順に記載されています。
Server = "Server" ":" 1*( product | comment )
「サーバ=「サーバ」」:、」 1*(製品| コメント)
Example:
例:
Server: CERN/3.0 libwww/2.17
サーバ: CERN/3.0libwww/2.17
If the response is being forwarded through a proxy, the proxy application must not add its data to the product list.
プロキシを通して応答を進めているなら、プロキシアプリケーションは製品リストにデータを追加してはいけません。
Note: Revealing the specific software version of the server may
allow the server machine to become more vulnerable to attacks
against software that is known to contain security holes. Server
implementors are encouraged to make this field a configurable
option.
以下に注意してください。 サーバの特定のソフトウェアバージョンを明らかにすることによって、サーバマシンはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 サーバ作成者がこの分野を構成可能なオプションにするよう奨励されます。
Berners-Lee, et al Informational [Page 45] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[45ページ]RFC1945HTTP/1996年5月1日
Note: Some existing servers fail to restrict themselves to the
product token syntax within the Server field.
以下に注意してください。 いくつかの既存のサーバは自分たちをServer分野の中の製品トークン構文に制限しません。
10.15 User-Agent
10.15 ユーザエージェント
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. Although it is not required, user agents should include this field with requests. The field can contain multiple product tokens (Section 3.7) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
User-エージェント要求ヘッダーフィールドは要求を溯源するユーザエージェントの情報を含んでいます。 これは統計的な目的、プロトコル違反をたどること、および特定のユーザエージェント制限を避けるために応答を合わせることのためにユーザエージェントの自動化された認識のためのものです。 それは必要ではありませんが、ユーザエージェントは要求があるこの分野を入れるべきです。 分野はユーザエージェントのかなりの部分を形成する複数の製品トークン(セクション3.7)、エージェントを特定するコメント、およびどんな「副-製品」も含むことができます。 コンベンションによって、製品トークンはアプリケーションを特定するためのそれらの意味の順に記載されています。
User-Agent = "User-Agent" ":" 1*( product | comment )
「ユーザエージェント=「ユーザエージェント」」:、」 1*(製品| コメント)
Example:
例:
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
ユーザエージェント: CERN-LineMode/2.15libwww/2.17b3
Note: Some current proxy applications append their product
information to the list in the User-Agent field. This is not
recommended, since it makes machine interpretation of these
fields ambiguous.
以下に注意してください。 いくつかの現在のプロキシアプリケーションがUser-エージェント分野のリストにそれらの製品情報を追加します。 これらの分野のマシン解釈をあいまいにするので、これは推薦されません。
Note: Some existing clients fail to restrict themselves to
the product token syntax within the User-Agent field.
以下に注意してください。 自分たちをUser-エージェント分野の中の製品トークン構文に制限しない既存のクライアントもいます。
10.16 WWW-Authenticate
10.16はWWW認証します。
The WWW-Authenticate response-header field must be included in 401 (unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the Request-URI.
応答ヘッダ分野をWWW認証してください、401の(権限のない)の応答メッセージに含まなければなりません。 分野値はRequest-URIに適切な認証体系とパラメタについて簡単に述べる少なくとも1つの挑戦から成ります。
WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge
「WWW認証、=が「WWW認証する」、」、:、」 1#挑戦
The HTTP access authentication process is described in Section 11. User agents must take special care in parsing the WWW-Authenticate field value if it contains more than one challenge, or if more than one WWW-Authenticate header field is provided, since the contents of a challenge may itself contain a comma-separated list of authentication parameters.
HTTPアクセス認証過程はセクション11で説明されます。 1つ以上の挑戦を含んでいるか、またはより多くの人がヘッダーをWWW認証するなら挑戦のコンテンツが供給するのでそれ自体で野原を供給するなら、分野値をWWW認証してください。ユーザエージェントが構文解析で特別に注意を払わなければならない、認証パラメタのコンマで切り離されたリストを含んでください。
Berners-Lee, et al Informational [Page 46] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[46ページ]RFC1945HTTP/1996年5月1日
11. Access Authentication
11. アクセス認証
HTTP provides a simple challenge-response authentication mechanism which may be used by a server to challenge a client request and by a client to provide authentication information. It uses an extensible, case-insensitive token to identify the authentication scheme, followed by a comma-separated list of attribute-value pairs which carry the parameters necessary for achieving authentication via that scheme.
HTTPは認証情報を提供するのにクライアント要求に挑戦するサーバとクライアントによって使用されるかもしれない簡単なチャレンジレスポンス認証メカニズムを提供します。 それは、その体系で認証を達成するのに必要なパラメタを運ぶ属性値組のコンマで切り離されたリストがあとに続いた認証体系を特定するのに広げることができて、大文字と小文字を区別しないトークンを使用します。
auth-scheme = token
auth-体系=トークン
auth-param = token "=" quoted-string
auth-paramはトークン「=」引用文字列と等しいです。
The 401 (unauthorized) response message is used by an origin server to challenge the authorization of a user agent. This response must include a WWW-Authenticate header field containing at least one challenge applicable to the requested resource.
401の(権限のない)の応答メッセージは発生源サーバによって使用されて、ユーザエージェントの承認に挑戦します。 この応答はaを含まなければなりません。要求されたリソースに適切な少なくとも1つの挑戦を含んで、ヘッダーフィールドをWWW認証してください。
challenge = auth-scheme 1*SP realm *( "," auth-param )
挑戦はauth-体系1*SP分野*と等しいです。(「」、auth-param)
realm = "realm" "=" realm-value
realm-value = quoted-string
分野=「分野」「=」分野価値の分野価値は引用文字列と等しいです。
The realm attribute (case-insensitive) is required for all authentication schemes which issue a challenge. The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme.
分野属性(大文字と小文字を区別しない)が挑戦を発行するすべての認証体系に必要です。 アクセスされるサーバの正準な根のURLと組み合わせて、分野値(大文字と小文字を区別する)は保護スペースを定義します。 これらの分野は、サーバに関する保護されたリソースが1セットの保護空間に仕切られるのを許容します、それぞれそれ自身の認証体系、そして/または、承認データベースで。 分野値は追加意味論を認証体系に特定にするかもしれない一般に、発生源サーバによって割り当てられたストリングです。
A user agent that wishes to authenticate itself with a server-- usually, but not necessarily, after receiving a 401 response--may do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.
サーバで通常それ自体を認証しますが、401応答--要求でAuthorizationヘッダーフィールドを含んでいることによってそうするかもしれないのを受けた後に必ず認証したがっているというわけではないユーザエージェント。 Authorization分野価値は要求されているリソースの分野にユーザエージェントの認証情報を含む資格証明書から成ります。
credentials = basic-credentials
| ( auth-scheme #auth-param )
資格証明書は基本的な資格証明書と等しいです。| (auth-体系#auth-param)
The domain over which credentials can be automatically applied by a user agent is determined by the protection space. If a prior request has been authorized, the same credentials may be reused for all other requests within that protection space for a period of time determined
ユーザエージェントが自動的に資格証明書を適用できるドメインは保護スペースのそばで決定しています。 先の要求が認可されたなら、同じ資格証明書は他のすべての要求のためにスペースがしばらく決定したその保護の中で再利用されるかもしれません。
Berners-Lee, et al Informational [Page 47] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[47ページ]RFC1945HTTP/1996年5月1日
by the authentication scheme, parameters, and/or user preference. Unless otherwise defined by the authentication scheme, a single protection space cannot extend outside the scope of its server.
認証体系、パラメタ、そして/または、ユーザー選択で。 別の方法で認証体系によって定義されない場合、ただ一つの保護スペースはサーバの範囲の外で広がることができません。
If the server does not wish to accept the credentials sent with a request, it should return a 403 (forbidden) response.
サーバが要求と共に送られた資格証明書を受け入れたくないなら、それは403(禁じられる)応答を返すべきです。
The HTTP protocol does not restrict applications to this simple challenge-response mechanism for access authentication. Additional mechanisms may be used, such as encryption at the transport level or via message encapsulation, and with additional header fields specifying authentication information. However, these additional mechanisms are not defined by this specification.
HTTPプロトコルはアクセス認証のためにアプリケーションをこの簡単なチャレンジレスポンスメカニズムに制限しません。 追加メカニズムは使用されるかもしれません、輸送レベルにおけるメッセージカプセル化を通して、追加ヘッダーフィールドが認証情報を指定している暗号化などのように。 しかしながら、これらの追加メカニズムはこの仕様で定義されません。
Proxies must be completely transparent regarding user agent authentication. That is, they must forward the WWW-Authenticate and Authorization headers untouched, and must not cache the response to a request containing Authorization. HTTP/1.0 does not provide a means for a client to be authenticated with a proxy.
プロキシはユーザエージェント認証に関して完全に透明でなければなりません。 すなわち、前方にそうしなければならない、WWW認証、Authorizationヘッダー、触れない、そして、Authorizationを含むaへの応答が要求するキャッシュではなく、必須。 HTTP/1.0はクライアントがプロキシと共に認証される手段を提供しません。
11.1 Basic Authentication Scheme
11.1 基本認証体系
The "basic" authentication scheme is based on the model that the user agent must authenticate itself with a user-ID and a password for each realm. The realm value should be considered an opaque string which can only be compared for equality with other realms on that server. The server will authorize the request only if it can validate the user-ID and password for the protection space of the Request-URI. There are no optional authentication parameters.
「基本的な」認証体系はユーザIDと各分野のためのパスワードでそれ自体でユーザエージェントが認証しなければならないモデルに基づいています。 分野値は平等のためにそのサーバの他の分野にたとえることができるだけである不透明なストリングであると考えられるべきです。Request-URIの保護スペースのためのユーザIDとパスワードを有効にすることができる場合にだけ、サーバは要求を認可するでしょう。 どんな任意の認証パラメタもありません。
Upon receipt of an unauthorized request for a URI within the protection space, the server should respond with a challenge like the following:
保護スペースの中のURIを求める権限のない要求を受け取り次第、サーバは以下のように挑戦で反応するべきです:
WWW-Authenticate: Basic realm="WallyWorld"
以下をWWW認証してください。 基本的な分野="WallyWorld"
where "WallyWorld" is the string assigned by the server to identify the protection space of the Request-URI.
"WallyWorld"がサーバによって割り当てられた、Request-URIの保護スペースを特定したストリングであるところ。
To receive authorization, the client sends the user-ID and password,
separated by a single colon (":") character, within a base64 [5]
encoded string in the credentials.
承認を受けるために、クライアントが1コロンによって切り離されたユーザIDとパスワードを送る、(「:」、)、キャラクタ、base64の中では、[5]は資格証明書でストリングをコード化しました。
basic-credentials = "Basic" SP basic-cookie
基本的な資格証明書は「基本的な」SP基本的なクッキーと等しいです。
basic-cookie = <base64 [5] encoding of userid-password,
except not limited to 76 char/line>
76炭/系列>に制限されないのを除いたユーザIDパスワードの基本的なクッキー=<base64[5]コード化
Berners-Lee, et al Informational [Page 48] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[48ページ]RFC1945HTTP/1996年5月1日
userid-password = [ token ] ":" *TEXT
「ユーザIDパスワード=[トークン]」:、」 *テキスト
If the user agent wishes to send the user-ID "Aladdin" and password "open sesame", it would use the following header field:
ユーザエージェントがユーザID「アラジン」とパスワードに「開けごまの呪文」を送りたいなら、以下のヘッダーフィールドを使用するでしょう:
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
承認: 基本的なQWxhZGRpbjpvcGVuIHNlc2FtZQ=
The basic authentication scheme is a non-secure method of filtering unauthorized access to resources on an HTTP server. It is based on the assumption that the connection between the client and the server can be regarded as a trusted carrier. As this is not generally true on an open network, the basic authentication scheme should be used accordingly. In spite of this, clients should implement the scheme in order to communicate with servers that use it.
基本認証体系はHTTPサーバに関するリソースへの不正アクセスをフィルターにかける非安全なメソッドです。それはクライアントとサーバとの関係を信じられたキャリヤーと見なすことができるという仮定に基づいています。 これがオープンネットワークで一般に本当でないので、基本認証体系はそれに従って、使用されるべきです。 これにもかかわらず、クライアントは、それを使用するサーバとコミュニケートするために体系を実装するべきです。
12. Security Considerations
12. セキュリティ問題
This section is meant to inform application developers, information providers, and users of the security limitations in HTTP/1.0 as described by this document. The discussion does not include definitive solutions to the problems revealed, though it does make some suggestions for reducing security risks.
このセクションはこのドキュメントによって説明されるようにHTTP/1.0におけるセキュリティ制限についてアプリケーション開発者、情報提供者、およびユーザに知らせることになっています。 議論はセキュリティ危険を減少させるためのいくつかの提案をしますが、明らかにされた問題に決定的なソリューションを含んでいません。
12.1 Authentication of Clients
12.1 クライアントの認証
As mentioned in Section 11.1, the Basic authentication scheme is not a secure method of user authentication, nor does it prevent the Entity-Body from being transmitted in clear text across the physical network used as the carrier. HTTP/1.0 does not prevent additional authentication schemes and encryption mechanisms from being employed to increase security.
セクション11.1で言及されるように、Basic認証体系はユーザー認証の安全なメソッドではありません、そして、それはEntity-ボディーがキャリヤーとして使用される物理ネットワークの向こう側にクリアテキストで伝えられるのを防ぎません。 HTTP/1.0は、追加認証体系と暗号化メカニズムがセキュリティを増強するのに使われるのを防ぎません。
12.2 Safe Methods
12.2 安全なメソッド
The writers of client software should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they may take which may have an unexpected significance to themselves or others.
クライアントソフトウェアの作家はソフトウェアにインターネットの上の彼らの相互作用でユーザの代理をして、ユーザがそれらが取るどんな行動も意識しているのを許容するように注意しているべきであるのを意識しているべきです(自分たちか他のものに予期していなかった意味を持っているかもしれません)。
In particular, the convention has been established that the GET and HEAD methods should never have the significance of taking an action other than retrieval. These methods should be considered "safe." This allows user agents to represent other methods, such as POST, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.
特に、GETとHEADメソッドが検索を除いて、訴訟を起こしながら意味を決して持つべきでないコンベンションは設立されました。 これらのメソッドは「安全である」と考えられるべきです。 これで、ユーザエージェントは他のメソッドを表すことができます、ポストなどのように、特別な方法で、ユーザをことによると危険な動きが要求されているという事実を知るようにするように。
Berners-Lee, et al Informational [Page 49] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[49ページ]RFC1945HTTP/1996年5月1日
Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.
当然、サーバが、実行の結果、副作用がGET要求であると生成しないのを保証するのは可能ではありません。 事実上、いくつかのダイナミックなリソースが、それが特徴であると考えます。 ここでの大切な区別はしたがって、副作用を要求しなかったのでそれらについて責任があるようにユーザを保つことができないということです。
12.3 Abuse of Server Log Information
12.3 サーバログ情報の乱用
A server is in the position to save personal data about a user's requests which may identify their reading patterns or subjects of interest. This information is clearly confidential in nature and its handling may be constrained by law in certain countries. People using the HTTP protocol to provide data are responsible for ensuring that such material is not distributed without the permission of any individuals that are identifiable by the published results.
サーバがそれらの興味深い読書パターンか対象を特定するかもしれないユーザの要求に関する個人的なデータを保存する立場にあります。 この情報は明確に現実に秘密です、そして、取り扱いはある一定の国で法で抑制されるかもしれません。 そのような材料がどんな発行された結果で身元保証可能な個人の許可なしでも分配されないのを確実にするのにデータを提供するのにHTTPプロトコルを使用している人々は責任があります。
12.4 Transfer of Sensitive Information
12.4 機密情報の転送
Like any generic data transfer protocol, HTTP cannot regulate the content of the data that is transferred, nor is there any a priori method of determining the sensitivity of any particular piece of information within the context of any given request. Therefore, applications should supply as much control over this information as possible to the provider of that information. Three header fields are worth special mention in this context: Server, Referer and From.
どんなジェネリックデータ転送プロトコルのようにも、HTTPはわたっているデータの内容を規制できません、そして、どんな与えられた要求の文脈の中でもどんな特定の情報の感度も決定する少しの先験的なメソッドもありません。 したがって、アプリケーションはこの情報のその情報のプロバイダーにできるだけ多くのコントロールを供給するべきです。 3つのヘッダーフィールドが特記のこのような関係においては価値があります: そしてサーバ、Referer。
Revealing the specific software version of the server may allow the server machine to become more vulnerable to attacks against software that is known to contain security holes. Implementors should make the Server header field a configurable option.
サーバの特定のソフトウェアバージョンを明らかにすることによって、サーバマシンはセキュリティーホールを含むのが知られているソフトウェアに対する攻撃により被害を受け易くなるかもしれません。 作成者はServerヘッダーフィールドを構成可能なオプションにするべきです。
The Referer field allows reading patterns to be studied and reverse links drawn. Although it can be very useful, its power can be abused if user details are not separated from the information contained in the Referer. Even when the personal information has been removed, the Referer field may indicate a private document's URI whose publication would be inappropriate.
Referer分野で、読書パターンは、研究されて、描かれたリンクを逆にします。 それは非常に役に立つ場合がありますが、ユーザの詳細がRefererに含まれた情報と切り離されないなら、パワーを乱用できます。 個人情報を取り除くときさえ、Referer分野は公表が不適当である個人的なドキュメントのURIを示すかもしれません。
The information sent in the From field might conflict with the user's privacy interests or their site's security policy, and hence it should not be transmitted without the user being able to disable, enable, and modify the contents of the field. The user must be able to set the contents of this field within a user preference or application defaults configuration.
分野のコンテンツを無効にして、可能にして、変更できるユーザなしで、情報は、From分野がユーザのプライバシー利益のためかそれらのサイトの安全保障政策と衝突するかもしれないのを送って、したがって、それを伝えるべきではありません。 ユーザはユーザー選択の中にこの分野のコンテンツを設定できるか、アプリケーションデフォルトが構成であったならそうしなければなりません。
We suggest, though do not require, that a convenient toggle interface be provided for the user to enable or disable the sending of From and Referer information.
もっとも、私たちが、するように提案する、必要でない、ユーザがFromとReferer情報の発信を可能にするか、または無効にするように、便利なトグルインタフェースを提供します。
Berners-Lee, et al Informational [Page 50] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[50ページ]RFC1945HTTP/1996年5月1日
12.5 Attacks Based On File and Path Names
12.5の攻撃がファイルとパス名を基礎づけました。
Implementations of HTTP origin servers should be careful to restrict the documents returned by HTTP requests to be only those that were intended by the server administrators. If an HTTP server translates HTTP URIs directly into file system calls, the server must take special care not to serve files that were not intended to be delivered to HTTP clients. For example, Unix, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one. On such a system, an HTTP server must disallow any such construct in the Request-URI if it would otherwise allow access to a resource outside those intended to be accessible via the HTTP server. Similarly, files intended for reference only internally to the server (such as access control files, configuration files, and script code) must be protected from inappropriate retrieval, since they might contain sensitive information. Experience has shown that minor bugs in such HTTP server implementations have turned into security risks.
HTTP発生源サーバの実装はサーバアドミニストレータによって意図されたものだけであるというHTTP要求で返されたドキュメントを制限するのに慎重であるはずです。 HTTPサーバが直接ファイルシステムコールにHTTP URIを翻訳するなら、サーバは、HTTPクライアントに提供されることを意図しなかったファイルに役立たないように特別に注意を払わなければなりません。 「例えば、Unix、マイクロソフトWindows、および他のオペレーティングシステムが使用する、」 . . 」 現在のものより上でaディレクトリレベルを示す経路コンポーネントとして。 そのようなシステムの上では、別の方法でHTTPサーバでアクセスしやすいことを意図するものの外のリソースへのアクセスを許すなら、HTTPサーバはRequest-URIでどんなそのような構造物も禁じなければなりません。同様に、不適当な検索から参照のために内部的にだけサーバ(アクセス制御ファイルや、構成ファイルや、スクリプトコードなどの)に意図するファイルを保護しなければなりません、機密情報を含むかもしれないので。 経験は、そのようなHTTPサーバ実装における小さい方のバグがセキュリティリスクに変わったのを示しました。
13. Acknowledgments
13. 承認
This specification makes heavy use of the augmented BNF and generic constructs defined by David H. Crocker for RFC 822 [7]. Similarly, it reuses many of the definitions provided by Nathaniel Borenstein and Ned Freed for MIME [5]. We hope that their inclusion in this specification will help reduce past confusion over the relationship between HTTP/1.0 and Internet mail message formats.
この仕様で、デヴィッド・H.クロッカーはRFC822[7]のために増大しているBNFとジェネリック構造物の重い使用を定義します。 同様に、それはナザニエルBorensteinとネッド・フリードによってMIME[5]に提供された定義の多くを再利用します。 この仕様での彼らの包含が、HTTP/1.0とインターネット・メールメッセージ・フォーマットとの関係の上で過去の混乱を抑えるのを助けることを願っています。
The HTTP protocol has evolved considerably over the past four years. It has benefited from a large and active developer community--the many people who have participated on the www-talk mailing list--and it is that community which has been most responsible for the success of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, and Marc VanHeyningen deserve special recognition for their efforts in defining aspects of the protocol for early versions of this specification.
HTTPプロトコルは過去4年間かなり発展しています。 それは大きくて活動的な開発者社会(www-話のメーリングリストに参加した多くの人々)の利益を得ました、そして、一般に、HTTPとWWWの成功に最も責任感が強いその共同体です。 マーク・アンドリーセン、ロバート・カイラウ、ダニエル・W.コノリー、ボブ・デニー、ジャン・フランソワ・グルフ、フィリップ・M.ハラム-ベイカー、Hakon W.Lie、アリLuotonen、ロブMcCool、ルウMontulli、デーヴRaggett、トニーSanders、およびマークVanHeyningenはこの仕様の早めのバージョンのためにプロトコルの局面を定義する際に彼らの取り組みのための特別な認識に値します。
Paul Hoffman contributed sections regarding the informational status of this document and Appendices C and D.
ポール・ホフマンはこのドキュメントとAppendices CとDの情報の状態に関するセクションを寄付しました。
Berners-Lee, et al Informational [Page 51] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[51ページ]RFC1945HTTP/1996年5月1日
This document has benefited greatly from the comments of all those participating in the HTTP-WG. In addition to those already mentioned, the following individuals have contributed to this specification:
このドキュメントは大いにHTTP-WGに参加するすべてのもののコメントの利益を得ました。 既に言及されたものに加えて、以下の個人はこの仕様に貢献しました:
Gary Adams Harald Tveit Alvestrand
Keith Ball Brian Behlendorf
Paul Burchard Maurizio Codogno
Mike Cowlishaw Roman Czyborra
Michael A. Dolan John Franks
Jim Gettys Marc Hedlund
Koen Holtman Alex Hopmann
Bob Jernigan Shel Kaphan
Martijn Koster Dave Kristol
Daniel LaLiberte Paul Leach
Albert Lunde John C. Mallery
Larry Masinter Mitra
Jeffrey Mogul Gavin Nicol
Bill Perry Jeffrey Perry
Owen Rees Luigi Rizzo
David Robinson Marc Salomon
Rich Salz Jim Seidman
Chuck Shotton Eric W. Sink
Simon E. Spero Robert S. Thau
Francois Yergeau Mary Ellen Zurko
Jean-Philippe Martin-Flatin
ゲーリー・アダムス・ハラルド・Tveit Alvestrandキース・Ballブライアン・Behlendorfポール・Burchardマウリジオ・コドーニョマイク・カウリショウRomanのCzyborraのポールリーチアルバートルンデジョンマイケルA.ドランジョンフランクスジムGettysマークヘドランドクンHoltmanアレックスHopmannボブJerniganシェルKaphanマーティンコスターデーヴクリストルダニエルLaLiberte C; MalleryラリーMasinterミトラジェフリー要人ギャヴィンニコルBill Perryジェフリーペリーオーエンレースルーイジリゾーデイビッド・ロビンソンマークソロモンリッシュザルツジムシードマンチャックShottonエリックW.流し台サイモンE.スペロウロバートS.トーフランソアYergeauメアリエレンZurkoジャンフィリップマーチン-Flatin
14. References
14. 参照
[1] Anklesaria, F., McCahill, M., Lindner, P., Johnson, D.,
Torrey, D., and B. Alberti, "The Internet Gopher Protocol: A
Distributed Document Search and Retrieval Protocol", RFC 1436,
University of Minnesota, March 1993.
[1] Anklesaria、F.、McCahill、M.、リントナー、P.、ジョンソン、D.、トーリー、D.、およびB.アルベルティ、「インターネットゴーファーは議定書を作ります」。 「分配されたドキュメント検索と検索は議定書を作る」RFC1436、ミネソタ大学、1993年3月。
[2] 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, CERN, June 1994.
[2] バーナーズ・リー、T.、「WWWの普遍的なリソース識別子:」 「WWWに使用されるNetworkの上のObjectsのNamesとAddressesのExpressionのためのUnifying Syntax」、RFC1630、CERN(1994年6月)
[3] Berners-Lee, T., and D. Connolly, "Hypertext Markup Language -
2.0", RFC 1866, MIT/W3C, November 1995.
[3] バーナーズ・リー、T.、およびD.コノリー、「ハイパーテキストマークアップランゲージ--2インチ、RFC1866、MIT/W3C、1995インチ年11月。
[4] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform
Resource Locators (URL)", RFC 1738, CERN, Xerox PARC,
University of Minnesota, December 1994.
[4] バーナーズ・リーとT.とMasinter、L.とM.McCahill、「Uniform Resource Locator(URL)」、RFC1738、CERN、ゼロックスPARC、ミネソタ大学、1994年12月。
Berners-Lee, et al Informational [Page 52] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[52ページ]RFC1945HTTP/1996年5月1日
[5] Borenstein, N., and N. Freed, "MIME (Multipurpose Internet Mail
Extensions) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies", RFC 1521, Bellcore,
Innosoft, September 1993.
[5] Borenstein、N.、およびN.フリード、「パート1をまねてください(マルチパーパスインターネットメールエクステンション)」 「インターネットメッセージ本体の形式を指定して、説明するためのメカニズム」、RFC1521、Bellcore、Innosoft、1993年9月。
[6] Braden, R., "Requirements for Internet hosts - Application and
Support", STD 3, RFC 1123, IETF, October 1989.
[6] ブレーデンと、R.と、「インターネット・ホスト--アプリケーションのための要件とSupport」、STD3、RFC1123、IETF、10月1989日
[7] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, UDEL, August 1982.
[7] クロッカー、D.、「アルパインターネットテキスト・メッセージの形式の規格」、STD11、RFC822、UDEL、1982年8月。
[8] F. Davis, B. Kahle, H. Morris, J. Salem, T. Shen, R. Wang,
J. Sui, and M. Grinbaum. "WAIS Interface Protocol Prototype
Functional Specification." (v1.5), Thinking Machines
Corporation, April 1990.
[8]F.デイヴィス、B.カーレ、H.モリス、J.礼拝堂、T.シン、R.ワング、J.スイ、およびM.Grinbaum。 「WAISはプロトコルの原型の機能的な仕様を連結します。」 (v1.5), 考えは社、1990年4月を機械加工します。
[9] Fielding, R., "Relative Uniform Resource Locators", RFC 1808,
UC Irvine, June 1995.
[9]フィールディング、R.、「相対的なUniform Resource Locator」、RFC1808、UCアーバイン1995年6月。
[10] Horton, M., and R. Adams, "Standard for interchange of USENET
Messages", RFC 1036 (Obsoletes RFC 850), AT&T Bell
Laboratories, Center for Seismic Studies, December 1987.
[10] ホートン、M.とR.アダムス、「USENET Messagesの置き換えの規格」RFC1036(RFC850を時代遅れにします)、AT&Tベル研究所、Seismic研究(1987年12月)のためのセンター。
[11] Kantor, B., and P. Lapsley, "Network News Transfer Protocol:
A Proposed Standard for the Stream-Based Transmission of News",
RFC 977, UC San Diego, UC Berkeley, February 1986.
[11] カンター、B.、およびP.ラプスリー、「ネットニュースはプロトコルを移します」。 RFC977、UCサンディエゴ、UCバークレー1986年2月の「ニュースの流れのベースの伝達の提案された標準。」
[12] Postel, J., "Simple Mail Transfer Protocol." STD 10, RFC 821,
USC/ISI, August 1982.
[12] ポステル、J.、「簡単なメール転送プロトコル。」 STD10、RFC821、USC/ISI、1982年8月。
[13] Postel, J., "Media Type Registration Procedure." RFC 1590,
USC/ISI, March 1994.
[13] ポステル、J.、「メディアは登録手順をタイプします」。 RFC1590、USC/ISI、1994年3月。
[14] Postel, J., and J. Reynolds, "File Transfer Protocol (FTP)",
STD 9, RFC 959, USC/ISI, October 1985.
[14] ポステル、J.とJ.レイノルズ、「ファイル転送プロトコル(FTP)」、STD9、RFC959、USC/ISI、1985年10月。
[15] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, RFC
1700, USC/ISI, October 1994.
[15] レイノルズ、J.とJ.ポステル、「規定番号」、STD2、RFC1700、USC/ISI、1994年10月。
[16] Sollins, K., and L. Masinter, "Functional Requirements for
Uniform Resource Names", RFC 1737, MIT/LCS, Xerox Corporation,
December 1994.
[16] Sollins、K.とL.Masinter、「一定のリソース名のための機能条件書」RFC1737、MIT/LCS、ゼロックス社、1994年12月。
[17] US-ASCII. Coded Character Set - 7-Bit American Standard Code
for Information Interchange. Standard ANSI X3.4-1986, ANSI,
1986.
[17] 米国-ASCII。 コード化文字集合--7ビットの情報交換用米国標準コード。 標準のANSI X3.4-1986、ANSI、1986。
Berners-Lee, et al Informational [Page 53] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[53ページ]RFC1945HTTP/1996年5月1日
[18] ISO-8859. International Standard -- Information Processing --
8-bit Single-Byte Coded Graphic Character Sets --
Part 1: Latin alphabet No. 1, ISO 8859-1:1987.
Part 2: Latin alphabet No. 2, ISO 8859-2, 1987.
Part 3: Latin alphabet No. 3, ISO 8859-3, 1988.
Part 4: Latin alphabet No. 4, ISO 8859-4, 1988.
Part 5: Latin/Cyrillic alphabet, ISO 8859-5, 1988.
Part 6: Latin/Arabic alphabet, ISO 8859-6, 1987.
Part 7: Latin/Greek alphabet, ISO 8859-7, 1987.
Part 8: Latin/Hebrew alphabet, ISO 8859-8, 1988.
Part 9: Latin alphabet No. 5, ISO 8859-9, 1990.
[18] ISO-8859。 世界規格--情報処理--8ビットの単一のバイトコード化された図形文字セット--第1部: ローマ字No.1、ISO8859-1:1987。 第2部: ローマ字No.2、ISO8859-2、1987。 パート3: ローマ字No.3、ISO8859-3、1988。 パート4: ローマ字No.4、ISO8859-4、1988。 パート5: ラテン/キリル文字、ISO8859-5、1988。 パート6: ラテン/アラビア文字、ISO8859-6、1987。 パート7: ラテン/ギリシャ語アルファベット、ISO8859-7、1987。 パート8: ラテン語の、または、ヘブライのアルファベット、ISO8859-8、1988。 パート9: ローマ字No.5、ISO8859-9、1990。
15. Authors' Addresses
15. 作者のアドレス
Tim Berners-Lee Director, W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A.
正方形のケンブリッジ、MA 02139、WWW協会MITコンピュータサイエンス研究所545Technology米国のティム・バーナーズ・リー指導官
Fax: +1 (617) 258 8682 EMail: timbl@w3.org
Fax: +1(617) 258 8682はメールされます: timbl@w3.org
Roy T. Fielding Department of Information and Computer Science University of California Irvine, CA 92717-3425, U.S.A.
情報の部をさばいているロイT.とカリフォルニア大学アーバイン、コンピュータサイエンスカリフォルニア92717-3425(米国)
Fax: +1 (714) 824-4056 EMail: fielding@ics.uci.edu
Fax: +1 (714) 824-4056 メールしてください: fielding@ics.uci.edu
Henrik Frystyk Nielsen W3 Consortium MIT Laboratory for Computer Science 545 Technology Square Cambridge, MA 02139, U.S.A.
正方形のケンブリッジ、Henrik FrystykニールセンWWW協会MIT Laboratory for Computer Science545Technology MA 02139、米国
Fax: +1 (617) 258 8682 EMail: frystyk@w3.org
Fax: +1(617) 258 8682はメールされます: frystyk@w3.org
Berners-Lee, et al Informational [Page 54] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[54ページ]RFC1945HTTP/1996年5月1日
Appendices
付録
These appendices are provided for informational reasons only -- they do not form a part of the HTTP/1.0 specification.
これらの付録を情報の理由だけに提供します--それらはHTTP/1.0仕様の一部を形成しません。
A. Internet Media Type message/http
A。 インターネットメディアTypeメッセージ/http
In addition to defining the HTTP/1.0 protocol, this document serves as the specification for the Internet media type "message/http". The following is to be registered with IANA [13].
HTTP/1.0プロトコルを定義することに加えて、このドキュメントはインターネットメディアのためのタイプ「メッセージ/http」という仕様として機能します。 以下はIANA[13]に登録されることになっています。
Media Type name: message
メディアTypeは以下を命名します。 メッセージ
Media subtype name: http
メディア「副-タイプ」は以下を命名します。 http
Required parameters: none
必要なパラメタ: なし
Optional parameters: version, msgtype
任意のパラメタ: バージョン、msgtype
version: The HTTP-Version number of the enclosed message
(e.g., "1.0"). If not present, the version can be
determined from the first line of the body.
バージョン: 同封のメッセージのHTTPバージョン番号、(例えば、「1インチ)」 プレゼントでないなら、バージョンはボディーの最初の線から決定できます。
msgtype: The message type -- "request" or "response". If
not present, the type can be determined from the
first line of the body.
msgtype: 「要求」かタイプ--「応答」というメッセージ。 プレゼントでないなら、タイプはボディーの最初の線から決定できます。
Encoding considerations: only "7bit", "8bit", or "binary" are
permitted
問題をコード化します: 「7ビット」、「8ビット」、または「バイナリー」だけ、が受入れられます。
Security considerations: none
セキュリティ問題: なし
B. Tolerant Applications
B。 許容性があるアプリケーション
Although this document specifies the requirements for the generation of HTTP/1.0 messages, not all applications will be correct in their implementation. We therefore recommend that operational applications be tolerant of deviations whenever those deviations can be interpreted unambiguously.
このドキュメントはHTTP/1.0のメッセージの世代単位で要件を指定しますが、すべてのアプリケーションがどんな彼らの実現で正しくなるというわけではないでしょう。 したがって、私たちは、明白にそれらの逸脱を解釈できるときはいつも、操作上のアプリケーションは逸脱において許容性があることを勧めます。
Clients should be tolerant in parsing the Status-Line and servers tolerant when parsing the Request-Line. In particular, they should accept any amount of SP or HT characters between fields, even though only a single SP is required.
Request-線を分析するとき、クライアントはStatus-線とサーバを分析する際に許容性があった状態で許容性があるべきです。 特に、彼らはどんな量のSPかHTキャラクタも分野の間に受け入れるべきです、独身のSPだけが必要ですが。
The line terminator for HTTP-header fields is the sequence CRLF. However, we recommend that applications, when parsing such headers, recognize a single LF as a line terminator and ignore the leading CR.
HTTPヘッダ分野への線ターミネータは系列CRLFです。 しかしながら、私たちは、そのようなヘッダーを分析するとき、アプリケーションが独身のLFが線ターミネータであると認めて、主なCRを無視することを勧めます。
Berners-Lee, et al Informational [Page 55] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[55ページ]RFC1945HTTP/1996年5月1日
C. Relationship to MIME
C。 まねる関係
HTTP/1.0 uses many of the constructs defined for Internet Mail (RFC 822 [7]) and the Multipurpose Internet Mail Extensions (MIME [5]) to allow entities to be transmitted in an open variety of representations and with extensible mechanisms. However, RFC 1521 discusses mail, and HTTP has a few features that are different than those described in RFC 1521. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
実体は開いているバラエティーの表現と広げることができるメカニズムで伝えさせられてください。HTTP/1.0がインターネットメールのために定義された構造物の多くを使用する、(RFC822[7])とマルチパーパスインターネットメールエクステンション、(MIME[5])、HTTPには、しかしながら、RFC1521はメールについて議論して、いくつかのRFC1521で説明されたものと異なった特徴があります。 これらの違いは2進の接続の上の性能を最適化するために慎重に選ばれて、ニューメディアの使用における、よりすばらしい自由を許容するのは、日付の比較をより簡単にして、何人かの早めのHTTPサーバとクライアントの習慣を承認するためにタイプされます。
At the time of this writing, it is expected that RFC 1521 will be revised. The revisions may include some of the practices found in HTTP/1.0 but not in RFC 1521.
この書くこと時点で、RFC1521が改訂されると予想されます。 改正は、HTTP/1.0で見つけられた習慣のいくつかを含んでいますが、RFC1521に含むかもしれないというわけではありません。
This appendix describes specific areas where HTTP differs from RFC 1521. Proxies and gateways to strict MIME environments should be aware of these differences and provide the appropriate conversions where necessary. Proxies and gateways from MIME environments to HTTP also need to be aware of the differences because some conversions may be required.
この付録はHTTPがRFC1521と異なっている特定の領域について説明します。 プロキシと厳しいMIME環境へのゲートウェイは、これらの違いを知って、適切な変換を必要であるところに提供するはずです。 また、プロキシとMIME環境からHTTPへのゲートウェイは、いくつかの変換が必要であるかもしれないので違いを知る必要があります。
C.1 Conversion to Canonical Form
標準形へのC.1変換
RFC 1521 requires that an Internet mail entity be converted to canonical form prior to being transferred, as described in Appendix G of RFC 1521 [5]. Section 3.6.1 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP.
RFC1521は、インターネット・メール実体が移す前に標準形に変換されるのを必要とします、RFC1521[5]のAppendix Gで説明されるように。 この.1通のセクション3.6ドキュメントがHTTPの上に伝えられると「テキスト」メディアタイプの血液型亜型のために許容されたフォームについて説明します。
RFC 1521 requires that content with a Content-Type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content when a message is transmitted over HTTP.
RFC1521は「テキスト」のコンテントタイプがある内容がCRLFとしてラインブレイクを表すのが必要であり、ラインブレイク系列の外でCRかLFの使用を禁じます。 メッセージがHTTPの上に送られるとき、HTTPで、CRLF、むき出しのCR、およびむき出しのLFはテキスト内容の中にラインブレイクを示すことができます。
Where it is possible, a proxy or gateway from HTTP to a strict RFC 1521 environment should translate all line breaks within the text media types described in Section 3.6.1 of this document to the RFC 1521 canonical form of CRLF. Note, however, that this may be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some character sets which do not use octets 13 and 10 to represent CR and LF, as is the case for some multi-byte character sets.
それが可能であるところでは、HTTPから厳しい1521年のRFC環境へのプロキシかゲートウェイがこの.1通のセクション3.6ドキュメントでCRLFのRFC1521標準形に説明されたテキストメディアタイプの中ですべてのラインブレイクを翻訳するはずです。 しかしながら、Content-コード化の存在と八重奏13と10を使用しないいくつかの文字の組の使用がHTTPでCRとLFを表すことができるという事実によってこれが複雑にされるかもしれないことに注意してください、いくつかの多バイト文字セットのためにそうであるように。
Berners-Lee, et al Informational [Page 56] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[56ページ]RFC1945HTTP/1996年5月1日
C.2 Conversion of Date Formats
日付の形式のC.2変換
HTTP/1.0 uses a restricted set of date formats (Section 3.3) to simplify the process of date comparison. Proxies and gateways from other protocols should ensure that any Date header field present in a message conforms to one of the HTTP/1.0 formats and rewrite the date if necessary.
HTTP/1.0は、日付の比較の過程を簡素化するのに、制限されたセットの日付の形式(セクション3.3)を使用します。 他のプロトコルからのプロキシとゲートウェイは、メッセージの現在のどんなDateヘッダーフィールドもHTTP/1.0の形式の1つに従うのを保証して、必要なら、日付を書き直すはずです。
C.3 Introduction of Content-Encoding
内容をコード化していることのC.3導入
RFC 1521 does not include any concept equivalent to HTTP/1.0's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols must either change the value of the Content-Type header field or decode the Entity-Body before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=<content-coding>" to perform an equivalent function as Content-Encoding. However, this parameter is not part of RFC 1521.)
RFC1521はContentをコード化しているHTTP/1.0ヘッダーフィールドに同等などんな概念も含んでいません。 以来、HTTPからMIME対応することのプロトコルへのメディアタイプ、プロキシ、およびゲートウェイの上の修飾語がコンテントタイプヘッダーフィールドの値を変えなければならないか、またはメッセージを転送する前にEntity-ボディーを解読しなければならないとき、これは行動します。 (「メールがメディア型引数を使用したインターネットへのコンテントタイプのいくつかの実験用アプリケーション」 ; コード化を満足させている変換=<>、」 Contentをコード化しているとして同等な機能を実行するために。 しかしながら、このパラメタはRFC1521の一部ではありません。)
C.4 No Content-Transfer-Encoding
C.4のいいえの満足している転送コード化
HTTP does not use the Content-Transfer-Encoding (CTE) field of RFC
1521. Proxies and gateways from MIME-compliant protocols to HTTP must
remove any non-identity CTE ("quoted-printable" or "base64") encoding
prior to delivering the response message to an HTTP client.
HTTPはRFC1521のContent転送コード化(CTE)分野を使用しません。 プロキシとMIME対応することのプロトコルからHTTPへのゲートウェイがどんな非のアイデンティティCTEも取り外さなければならない、(「引用されて印刷可能である」か「base64") HTTPクライアントに応答メッセージを述べる前のコード化」。
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway should label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
プロキシとHTTPからMIME対応することのプロトコルへのゲートウェイはそのプロトコルで安全輸送のための正しい形式にはメッセージがあるのを確実にして、コード化に原因となります。そこでは、「安全輸送」が使用されるプロトコルの制限で定義されます。 そうするならプロキシかゲートウェイが適切なContent転送コード化でデータをラベルするはずであるそのようなものは目的地プロトコルの上の安全輸送の見込みを改良するでしょう。
C.5 HTTP Header Fields in Multipart Body-Parts
複合身体部分のC.5HTTPヘッダ分野
In RFC 1521, most header fields in multipart body-parts are generally ignored unless the field name begins with "Content-". In HTTP/1.0, multipart body-parts may contain any HTTP header fields which are significant to the meaning of that part.
RFC1521では、フィールド名が「内容」で始まらない場合、一般に、複合身体部分のほとんどのヘッダーフィールドが無視されます。 HTTP/1.0では、複合身体部分はどんなその部分の意味に重要なHTTPヘッダ分野も含むかもしれません。
D. Additional Features
D。 付加的な機能
This appendix documents protocol elements used by some existing HTTP implementations, but not consistently and correctly across most HTTP/1.0 applications. Implementors should be aware of these features, but cannot rely upon their presence in, or interoperability
この付録は、ほとんどのHTTP/1.0のアプリケーションの向こう側にいくつかの既存のHTTP実現で使用されるプロトコル要素を記録しますが、一貫して、正しく記録するというわけではありません。 中のそれらの存在、または相互運用性を当てにすることができないのを除いて、作成者はこれらの特徴を知っているべきです。
Berners-Lee, et al Informational [Page 57] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[57ページ]RFC1945HTTP/1996年5月1日
with, other HTTP/1.0 applications.
他のHTTP/1.0のアプリケーション。
D.1 Additional Request Methods
D.1の追加要求方法
D.1.1 PUT
置かれたD.1.1
The PUT method requests that the enclosed entity be stored under the supplied Request-URI. If the Request-URI refers to an already existing resource, the enclosed entity should be considered as a modified version of the one residing on the origin server. If the Request-URI does not point to an existing resource, and that URI is capable of being defined as a new resource by the requesting user agent, the origin server can create the resource with that URI.
PUT方法は、同封の実体が供給されたRequest-URIの下で格納されるよう要求します。 Request-URIが既に既存のリソースを示すなら、同封の実体はものが起源サーバにある変更されたバージョンであるとみなされるべきです。Request-URIが既存のリソースを示さないで、要求しているユーザエージェントが新しいリソースとそのURIが定義できるなら、起源サーバはそのURIでリソースを作成できます。
The fundamental difference between the POST and PUT requests is reflected in the different meaning of the Request-URI. The URI in a POST request identifies the resource that will handle the enclosed entity as data to be processed. That resource may be a data-accepting process, a gateway to some other protocol, or a separate entity that accepts annotations. In contrast, the URI in a PUT request identifies the entity enclosed with the request -- the user agent knows what URI is intended and the server should not apply the request to some other resource.
ポストとPUT要求の基本的な違いはRequest-URIの異なった意味に反映されます。 ポストの要求におけるURIは処理されるためにデータとして同封の実体を扱うリソースを特定します。 そのリソースは、データを受け入れる過程、ある他のプロトコルへのゲートウェイ、または注釈を受け入れる別々の実体であるかもしれません。 対照的に、PUT要求におけるURIは同封の実体を要求と同一視します--ユーザエージェントは、どんなURIが意図するかを知っています、そして、サーバはある他のリソースに要求を適用するべきではありません。
D.1.2 DELETE
D.1.2は削除します。
The DELETE method requests that the origin server delete the resource identified by the Request-URI.
DELETE方法は、起源サーバがRequest-URIによって特定されたリソースを削除するよう要求します。
D.1.3 LINK
D.1.3リンク
The LINK method establishes one or more Link relationships between the existing resource identified by the Request-URI and other existing resources.
LINK方法はRequest-URIによって特定された既存のリソースと他の既存のリソースとの1Linkの関係を確立します。
D.1.4 UNLINK
D.1.4は離れます。
The UNLINK method removes one or more Link relationships from the existing resource identified by the Request-URI.
UNLINK方法はRequest-URIによって特定された既存のリソースから1Linkの関係を取り除きます。
D.2 Additional Header Field Definitions
D.2の追加ヘッダーフィールド定義
D.2.1 Accept
D.2.1は受け入れます。
The Accept request-header field can be used to indicate a list of media ranges which are acceptable as a response to the request. The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes
要求への応答として許容できるメディア範囲のリストを示すのにAccept要求ヘッダーフィールドを使用できます。 「アスタリスク「*」キャラクタはメディアタイプを範囲に分類するのに使用されます、」 */*で」すべてを示す示しているすべてのメディアタイプと「タイプ/*」血液型亜型
Berners-Lee, et al Informational [Page 58] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[58ページ]RFC1945HTTP/1996年5月1日
of that type. The set of ranges given by the client should represent what types are acceptable given the context of the request.
それでは、タイプしてください。 要求の文脈を考えて、クライアントがタイプすることを表すべきであるという範囲当然のことのセットは許容できます。
D.2.2 Accept-Charset
D.2.2、Charsetを受け入れます。
The Accept-Charset request-header field can be used to indicate a list of preferred character sets other than the default US-ASCII and ISO-8859-1. This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server which is capable of representing documents in those character sets.
デフォルトの米国-ASCIIとISO-8859-1以外の都合のよい文字の組のリストを示すのにAccept-Charset要求ヘッダーフィールドを使用できます。 この分野は包括的であるか専用である文字の組がそれらの文字の組でドキュメントを表すことができるサーバにその能力を示すのを理解できるクライアントを許容します。
D.2.3 Accept-Encoding
D.2.3、コード化を受け入れます。
The Accept-Encoding request-header field is similar to Accept, but restricts the content-coding values which are acceptable in the response.
Acceptをコード化している要求ヘッダーフィールドは、Acceptと同様ですが、応答で許容できる内容をコード化する値を制限します。
D.2.4 Accept-Language
D.2.4、言語を受け入れます。
The Accept-Language request-header field is similar to Accept, but restricts the set of natural languages that are preferred as a response to the request.
Accept-言語要求ヘッダーフィールドは、Acceptと同様ですが、応答として好まれる自然言語のセットを要求に制限します。
D.2.5 Content-Language
D.2.5の満足している言語
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this may not be equivalent to all the languages used within the entity.
Content-言語実体ヘッダーフィールドは同封の実体のために対象とする訪問者の自然言語について説明します。 これが実体の中で使用されたすべての言語に同等でないかもしれないことに注意してください。
D.2.6 Link
D.2.6リンク
The Link entity-header field provides a means for describing a relationship between the entity and some other resource. An entity may include multiple Link values. Links at the metainformation level typically indicate relationships like hierarchical structure and navigation paths.
Link実体ヘッダーフィールドは実体とある他のリソースとの関係について説明するための手段を提供します。 実体は複数のLink値を含むかもしれません。 metainformationレベルにおけるリンクは階層構造と通船路のような関係を通常示します。
D.2.7 MIME-Version
D.2.7MIMEバージョン
HTTP messages may include a single MIME-Version general-header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field, as defined by RFC 1521 [5], should indicate that the message is MIME-conformant. Unfortunately, some older HTTP/1.0 servers send it indiscriminately, and thus this field should be ignored.
HTTPメッセージは、MIMEプロトコルのどんなバージョンがメッセージを構成するのに使用されたかを示すためにただ一つのMIMEバージョン一般的なヘッダーフィールドを含むかもしれません。 MIMEバージョンヘッダーフィールドのRFC1521[5]によって定義される使用は、メッセージがMIME-conformantであることを示すべきです。 残念ながら、いくつかの、より古いHTTP/1.0のサーバが無差別にそれを送ります、そして、その結果、この分野は無視されるべきです。
Berners-Lee, et al Informational [Page 59] RFC 1945 HTTP/1.0 May 1996
バーナーズ・リー、他のInformational[59ページ]RFC1945HTTP/1996年5月1日
D.2.8 Retry-After
後のD.2.8再試行
The Retry-After response-header field can be used with a 503 (service unavailable) response to indicate how long the service is expected to be unavailable to the requesting client. The value of this field can be either an HTTP-date or an integer number of seconds (in decimal) after the time of the response.
どれくらい長い間サービスが要求しているクライアントにとって入手できないと予想されるかを示すのに503(入手できないサービス)応答と共に後のRetry応答ヘッダ分野を使用できます。 この分野の値は、応答の時間の後のHTTP日付か整数秒数のどちらかであるかもしれません(小数における)。
D.2.9 Title
D.2.9タイトル
The Title entity-header field indicates the title of the entity.
Title実体ヘッダーフィールドは実体のタイトルを示します。
D.2.10 URI
D.2.10ユリ
The URI entity-header field may contain some or all of the Uniform Resource Identifiers (Section 3.2) by which the Request-URI resource can be identified. There is no guarantee that the resource can be accessed using the URI(s) specified.
URI実体ヘッダーフィールドはRequest-URIリソースを特定できるUniform Resource Identifier(セクション3.2)のいくつかかすべてを含むかもしれません。 (s)が指定したURIを使用することでリソースにアクセスできるという保証が全くありません。
Berners-Lee, et al Informational [Page 60]
バーナーズ・リー、他のInformational[60ページ]
一覧
スポンサーリンク
