[要約] RFC 9309は、サービス所有者がクローラーによるコンテンツのアクセスを制御するための「Robots Exclusion Protocol」を定義し拡張する。プロトコルの定義言語、エラー処理、およびキャッシュの取り扱いに関する指示を追加することを目的としています。
Internet Engineering Task Force (IETF) M. Koster
Request for Comments: 9309
Category: Standards Track G. Illyes
ISSN: 2070-1721 H. Zeller
L. Sassman
Google LLC
September 2022
Robots Exclusion Protocol
ロボット除外プロトコル
Abstract
概要
This document specifies and extends the "Robots Exclusion Protocol" method originally defined by Martijn Koster in 1994 for service owners to control how content served by their services may be accessed, if at all, by automatic clients known as crawlers. Specifically, it adds definition language for the protocol, instructions for handling errors, and instructions for caching.
このドキュメントは、1994年にMartijn Kosterが元々Martijn Kosterによって定義されていた「ロボット除外プロトコル」メソッドを指定して拡張し、サービスが提供するコンテンツにクローラーと呼ばれる自動クライアントがサービスを提供するコンテンツにアクセスする方法を制御します。具体的には、プロトコルの定義言語、エラーの取り扱いの指示、およびキャッシュの指示を追加します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これは、インターネット標準トラックドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9309.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9309で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2022 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、修正されたBSDライセンスで説明されているように保証なしで提供される修正されたBSDライセンステキストを含める必要があります。
Table of Contents
目次
1. Introduction
1.1. Requirements Language
2. Specification
2.1. Protocol Definition
2.2. Formal Syntax
2.2.1. The User-Agent Line
2.2.2. The "Allow" and "Disallow" Lines
2.2.3. Special Characters
2.2.4. Other Records
2.3. Access Method
2.3.1. Access Results
2.3.1.1. Successful Access
2.3.1.2. Redirects
2.3.1.3. "Unavailable" Status
2.3.1.4. "Unreachable" Status
2.3.1.5. Parsing Errors
2.4. Caching
2.5. Limits
3. Security Considerations
4. IANA Considerations
5. Examples
5.1. Simple Example
5.2. Longest Match
6. References
6.1. Normative References
6.2. Informative References
Authors' Addresses
This document applies to services that provide resources that clients can access through URIs as defined in [RFC3986]. For example, in the context of HTTP, a browser is a client that displays the content of a web page.
このドキュメントは、[RFC3986]で定義されているように、クライアントがURIを介してアクセスできるリソースを提供するサービスに適用されます。たとえば、HTTPのコンテキストでは、ブラウザはWebページのコンテンツを表示するクライアントです。
Crawlers are automated clients. Search engines, for instance, have crawlers to recursively traverse links for indexing as defined in [RFC8288].
クローラーは自動化されたクライアントです。たとえば、検索エンジンには、[RFC8288]で定義されているように、インデックスのためにリンクを再帰的に横断するクローラーがあります。
It may be inconvenient for service owners if crawlers visit the entirety of their URI space. This document specifies the rules originally defined by the "Robots Exclusion Protocol" [ROBOTSTXT] that crawlers are requested to honor when accessing URIs.
クローラーがURIスペース全体を訪問した場合、サービスオーナーにとっては不便かもしれません。このドキュメントは、クローラーがURISにアクセスする際に名誉を求めるように要求される「ロボット除外プロトコル」[RobotStxt] [RobotStxt]で元々定義されたルールを指定します。
These rules are not a form of access authorization.
これらのルールは、アクセス許可の一形態ではありません。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The protocol language consists of rule(s) and group(s) that the service makes available in a file named "robots.txt" as described in Section 2.3:
プロトコル言語は、セクション2.3で説明されているように、「robots.txt」という名前のファイルでサービスが利用できるルールとグループで構成されています。
Rule: A line with a key-value pair that defines how a crawler may access URIs. See Section 2.2.2.
ルール：クローラーがURISにアクセスする方法を定義するキー価値ペアのライン。セクション2.2.2を参照してください。
Group: One or more user-agent lines that are followed by one or more rules. The group is terminated by a user-agent line or end of file. See Section 2.2.1. The last group may have no rules, which means it implicitly allows everything.
グループ：1つ以上のルールが続く1つ以上のユーザーエージェント行。グループは、ユーザーエージェント行またはファイルの終了によって終了します。セクション2.2.1を参照してください。最後のグループにはルールがない場合があります。つまり、暗黙的にすべてを許可します。
Below is an Augmented Backus-Naur Form (ABNF) description, as described in [RFC5234].
以下は、[RFC5234]で説明されているように、拡張されたバックスノール形式（ABNF）の説明です。
robotstxt = *(group / emptyline)
group = startgroupline ; We start with a user-agent
; line
*(startgroupline / emptyline) ; ... and possibly more
; user-agent lines
*(rule / emptyline) ; followed by rules relevant
; for the preceding
; user-agent lines
startgroupline = *WS "user-agent" *WS ":" *WS product-token EOL
rule = *WS ("allow" / "disallow") *WS ":"
*WS (path-pattern / empty-pattern) EOL
; parser implementors: define additional lines you need (for ; example, Sitemaps).
;パーサーの実装者：必要な追加の行を定義します（例、SiteMapsなど）。
product-token = identifier / "*"
path-pattern = "/" *UTF8-char-noctl ; valid URI path pattern
empty-pattern = *WS
identifier = 1*(%x2D / %x41-5A / %x5F / %x61-7A)
comment = "#" *(UTF8-char-noctl / WS / "#")
emptyline = EOL
EOL = *WS [comment] NL ; end-of-line may have
; optional trailing comment
NL = %x0D / %x0A / %x0D.0A
WS = %x20 / %x09
; UTF8 derived from RFC 3629, but excluding control characters
;RFC 3629から派生したUTF8ですが、コントロール文字を除く
UTF8-char-noctl = UTF8-1-noctl / UTF8-2 / UTF8-3 / UTF8-4
UTF8-1-noctl = %x21 / %x22 / %x24-7F ; excluding control, space, "#"
UTF8-2 = %xC2-DF UTF8-tail
UTF8-3 = %xE0 %xA0-BF UTF8-tail / %xE1-EC 2UTF8-tail /
%xED %x80-9F UTF8-tail / %xEE-EF 2UTF8-tail
UTF8-4 = %xF0 %x90-BF 2UTF8-tail / %xF1-F3 3UTF8-tail /
%xF4 %x80-8F 2UTF8-tail
UTF8-tail = %x80-BF
Crawlers set their own name, which is called a product token, to find relevant groups. The product token MUST contain only uppercase and lowercase letters ("a-z" and "A-Z"), underscores ("_"), and hyphens ("-"). The product token SHOULD be a substring of the identification string that the crawler sends to the service. For example, in the case of HTTP [RFC9110], the product token SHOULD be a substring in the User-Agent header. The identification string SHOULD describe the purpose of the crawler. Here's an example of a User-Agent HTTP request header with a link pointing to a page describing the purpose of the ExampleBot crawler, which appears as a substring in the User-Agent HTTP header and as a product token in the robots.txt user-agent line:
Crawlersは、関連するグループを見つけるために、製品トークンと呼ばれる独自の名前を設定します。製品トークンには、大文字と小文字（ "a-z" and "a-z"）のみ、アンダースコア（ "_"）、およびハイフン（ " - "）のみを含める必要があります。製品トークンは、クローラーがサービスに送る識別文字列のサブストリングである必要があります。たとえば、HTTP [RFC9110]の場合、製品トークンはユーザーエージェントヘッダーのサブストリングである必要があります。識別文字列は、クローラーの目的を説明する必要があります。ユーザーエージェントHTTPリクエストヘッダーの例は、ユーザーエージェントHTTPヘッダーのサブストリングとして、およびrobots.txtユーザーの製品トークンとして表示される、ExampleBot Crawlerの目的を説明するページを指すリンクを備えた例です。エージェントライン：
+==========================================+========================+
| User-Agent HTTP header | robots.txt user-agent |
| | line |
+==========================================+========================+
| User-Agent: Mozilla/5.0 (compatible; | user-agent: ExampleBot |
| ExampleBot/0.1; | |
| https://www.example.com/bot.html) | |
+------------------------------------------+------------------------+
Figure 1: Example of a User-Agent HTTP header and robots.txt user-agent line for the ExampleBot product token
図1：ユーザーエージェントのhttpヘッダーとrobots.txtの例ボット製品トークンのユーザーエージェントライン
Note that the product token (ExampleBot) is a substring of the User-Agent HTTP header.
製品トークン（ExampleBot）は、ユーザーエージェントHTTPヘッダーのサブストリングであることに注意してください。
Crawlers MUST use case-insensitive matching to find the group that matches the product token and then obey the rules of the group. If there is more than one group matching the user-agent, the matching groups' rules MUST be combined into one group and parsed according to Section 2.2.2.
Crawlersは、Case-Ensensive Matteringを使用して、製品トークンに一致するグループを見つけてから、グループのルールに従う必要があります。ユーザーエージェントに一致する複数のグループがある場合、マッチンググループのルールを1つのグループに組み合わせて、セクション2.2.2に従って解析する必要があります。
+========================================+========================+
| Two groups that match the same product | Merged group |
| token exactly | |
+========================================+========================+
| user-agent: ExampleBot | user-agent: ExampleBot |
| disallow: /foo | disallow: /foo |
| disallow: /bar | disallow: /bar |
| | disallow: /baz |
| user-agent: ExampleBot | |
| disallow: /baz | |
+----------------------------------------+------------------------+
Figure 2: Example of how to merge two robots.txt groups that match the same product token
図2：同じ製品トークンに一致する2つのrobots.txtグループをマージする方法の例
If no matching group exists, crawlers MUST obey the group with a user-agent line with the "*" value, if present.
一致するグループが存在しない場合、クローラーは、存在する場合、「*」値を持つユーザーエージェントラインでグループに従わなければなりません。
+==================================+======================+
| Two groups that don't explicitly | Applicable group for |
| match ExampleBot | ExampleBot |
+==================================+======================+
| user-agent: * | user-agent: * |
| disallow: /foo | disallow: /foo |
| disallow: /bar | disallow: /bar |
| | |
| user-agent: BazBot | |
| disallow: /baz | |
+----------------------------------+----------------------+
Figure 3: Example of no matching groups other than the "*" for the ExampleBot product token
図3：例ボット製品トークンの「*」以外の一致するグループがない例
If no group matches the product token and there is no group with a user-agent line with the "*" value, or no groups are present at all, no rules apply.
製品トークンと一致するグループがなく、「*」値を持つユーザーエージェントラインを持つグループがない場合、またはグループがまったく存在しない場合、ルールは適用されません。
These lines indicate whether accessing a URI that matches the corresponding path is allowed or disallowed.
これらの行は、対応するパスに一致するURIにアクセスするかどうかを示しています。
To evaluate if access to a URI is allowed, a crawler MUST match the paths in "allow" and "disallow" rules against the URI. The matching SHOULD be case sensitive. The matching MUST start with the first octet of the path. The most specific match found MUST be used. The most specific match is the match that has the most octets. Duplicate rules in a group MAY be deduplicated. If an "allow" rule and a "disallow" rule are equivalent, then the "allow" rule SHOULD be used. If no match is found amongst the rules in a group for a matching user-agent or there are no rules in the group, the URI is allowed. The /robots.txt URI is implicitly allowed.
URIへのアクセスが許可されているかどうかを評価するには、クローラーはURIに対する「許可」および「許可」のパスと一致する必要があります。マッチングはケースに敏感でなければなりません。マッチングは、パスの最初のオクテットから開始する必要があります。見つかった最も具体的な一致を使用する必要があります。最も具体的な試合は、オクテットが最も多い試合です。グループ内の複製ルールは重複している場合があります。「許可」ルールと「許可」ルールが同等である場合、「許可」ルールを使用する必要があります。一致するユーザーエージェントのグループのルールの間で一致しない場合、またはグループにルールがない場合、URIは許可されます。/robots.txt uriは暗黙的に許可されています。
Octets in the URI and robots.txt paths outside the range of the ASCII coded character set, and those in the reserved range defined by [RFC3986], MUST be percent-encoded as defined by [RFC3986] prior to comparison.
URIおよびrobots.txtのオクテットは、ASCIIコード化された文字セットの範囲外のパス、および[RFC3986]で定義された予約範囲のパスは、比較前に[RFC3986]によって定義されているようにパーセントエンコードする必要があります。
If a percent-encoded ASCII octet is encountered in the URI, it MUST be unencoded prior to comparison, unless it is a reserved character in the URI as defined by [RFC3986] or the character is outside the unreserved character range. The match evaluates positively if and only if the end of the path from the rule is reached before a difference in octets is encountered.
URIでエンコードされたASCIIオクテットが遭遇した場合、[RFC3986]で定義されているURIの予約されたキャラクターである場合、またはキャラクターが非予定のキャラクター範囲外でない限り、比較前にエンコードされない必要があります。オクテットの差に遭遇する前に、ルールからのパスの終了に到達した場合にのみ、試合は積極的に評価されます。
For example:
例えば：
+==================+=======================+=======================+
| Path | Encoded Path | Path to Match |
+==================+=======================+=======================+
| /foo/bar?baz=quz | /foo/bar?baz=quz | /foo/bar?baz=quz |
+------------------+-----------------------+-----------------------+
| /foo/bar?baz= | /foo/bar?baz= | /foo/bar?baz= |
| https://foo.bar | https%3A%2F%2Ffoo.bar | https%3A%2F%2Ffoo.bar |
+------------------+-----------------------+-----------------------+
| /foo/bar/ | /foo/bar/%E3%83%84 | /foo/bar/%E3%83%84 |
| U+E38384 | | |
+------------------+-----------------------+-----------------------+
| /foo/ | /foo/bar/%E3%83%84 | /foo/bar/%E3%83%84 |
| bar/%E3%83%84 | | |
+------------------+-----------------------+-----------------------+
| /foo/ | /foo/bar/%62%61%7A | /foo/bar/baz |
| bar/%62%61%7A | | |
+------------------+-----------------------+-----------------------+
Figure 4: Examples of matching percent-encoded URI components
図4：マッチングパーセントエンコードURIコンポーネントの例
The crawler SHOULD ignore "disallow" and "allow" rules that are not in any group (for example, any rule that precedes the first user-agent line).
クローラーは、どのグループにもない「禁止」および「許可」ルールを無視する必要があります（たとえば、最初のユーザーエージェント行の前にあるルールなど）。
Implementors MAY bridge encoding mismatches if they detect that the robots.txt file is not UTF-8 encoded.
実装者は、robots.txtファイルがUTF-8エンコードされていないことを検出した場合、エンコードの不一致を橋渡しすることができます。
Crawlers MUST support the following special characters:
クローラーは次の特殊文字をサポートする必要があります。
+===========+===================+==============================+
| Character | Description | Example |
+===========+===================+==============================+
| # | Designates a line | allow: / # comment in line |
| | comment. | |
| | | # comment on its own line |
+-----------+-------------------+------------------------------+
| $ | Designates the | allow: /this/path/exactly$ |
| | end of the match | |
| | pattern. | |
+-----------+-------------------+------------------------------+
| * | Designates 0 or | allow: /this/*/exactly |
| | more instances of | |
| | any character. | |
+-----------+-------------------+------------------------------+
Figure 5: List of special characters in robots.txt files
図5：robots.txtファイルの特殊文字のリスト
If crawlers match special characters verbatim in the URI, crawlers SHOULD use "%" encoding. For example:
クローラーがURIの特殊文字と逐語的に一致する場合、クローラーは「％」エンコードを使用する必要があります。例えば：
+============================+====================================+
| Percent-encoded Pattern | URI |
+============================+====================================+
| /path/file-with-a-%2A.html | https://www.example.com/path/ |
| | file-with-a-*.html |
+----------------------------+------------------------------------+
| /path/foo-%24 | https://www.example.com/path/foo-$ |
+----------------------------+------------------------------------+
Figure 6: Example of percent-encoding
図6：パーセントエンコードの例
Crawlers MAY interpret other records that are not part of the robots.txt protocol -- for example, "Sitemaps" [SITEMAPS]. Crawlers MAY be lenient when interpreting other records. For example, crawlers may accept common misspellings of the record.
クローラーは、robots.txtプロトコルの一部ではない他のレコードを解釈する場合があります。たとえば、「sitemaps」[sitemaps]。クローラーは、他のレコードを解釈するときに寛大になる場合があります。たとえば、クローラーはレコードの一般的なスペルミスを受け入れる場合があります。
Parsing of other records MUST NOT interfere with the parsing of explicitly defined records in Section 2. For example, a "Sitemaps" record MUST NOT terminate a group.
他のレコードの解析は、セクション2の明示的に定義されたレコードの解析を妨害してはなりません。たとえば、「サイトマップ」レコードはグループを終了してはなりません。
The rules MUST be accessible in a file named "/robots.txt" (all lowercase) in the top-level path of the service. The file MUST be UTF-8 encoded (as defined in [RFC3629]) and Internet Media Type "text/plain" (as defined in [RFC2046]).
ルールは、サービスのトップレベルパスにある「/robots.txt」（すべて小文字）という名前のファイルでアクセスできる必要があります。ファイルは、UTF-8エンコード（[RFC3629]で定義されている）およびインターネットメディアタイプ「テキスト/プレーン」（[RFC2046]で定義されている）である必要があります。
As per [RFC3986], the URI of the robots.txt file is:
[RFC3986]によると、robots.txtファイルのURIは次のとおりです。
"scheme:[//authority]/robots.txt"
For example, in the context of HTTP or FTP, the URI is:
たとえば、HTTPまたはFTPのコンテキストでは、URIは次のとおりです。
https://www.example.com/robots.txt
ftp://ftp.example.com/robots.txt
If the crawler successfully downloads the robots.txt file, the crawler MUST follow the parseable rules.
CrawlerがRobots.txtファイルを正常にダウンロードした場合、Crawlerは断続的なルールに従う必要があります。
It's possible that a server responds to a robots.txt fetch request with a redirect, such as HTTP 301 or HTTP 302 in the case of HTTP. The crawlers SHOULD follow at least five consecutive redirects, even across authorities (for example, hosts in the case of HTTP).
サーバーは、HTTPの場合、HTTP 301やHTTP 302などのリダイレクトを使用してRobots.txt Fetchリクエストに応答する可能性があります。クローラーは、当局全体でさえ、少なくとも5つの連続したリダイレクトを追跡する必要があります（たとえば、HTTPの場合はホスト）。
If a robots.txt file is reached within five consecutive redirects, the robots.txt file MUST be fetched, parsed, and its rules followed in the context of the initial authority.
5つの連続したリダイレクト内でrobots.txtファイルに到達した場合、robots.txtファイルをフェッチ、解析し、そのルールは初期の権限のコンテキストで行われなければなりません。
If there are more than five consecutive redirects, crawlers MAY assume that the robots.txt file is unavailable.
5つ以上の連続したリダイレクトがある場合、クローラーはrobots.txtファイルが利用できないと想定する場合があります。
"Unavailable" means the crawler tries to fetch the robots.txt file and the server responds with status codes indicating that the resource in question is unavailable. For example, in the context of HTTP, such status codes are in the 400-499 range.
「利用できない」とは、クローラーがrobots.txtファイルを取得しようとすることを意味し、サーバーは問題のリソースが利用できないことを示すステータスコードで応答します。たとえば、HTTPのコンテキストでは、このようなステータスコードは400〜499の範囲にあります。
If a server status code indicates that the robots.txt file is unavailable to the crawler, then the crawler MAY access any resources on the server.
サーバーステータスコードがrobots.txtファイルがクローラーに利用できないことを示している場合、クローラーはサーバー上の任意のリソースにアクセスできます。
If the robots.txt file is unreachable due to server or network errors, this means the robots.txt file is undefined and the crawler MUST assume complete disallow. For example, in the context of HTTP, server errors are identified by status codes in the 500-599 range.
サーバーまたはネットワークエラーのためにrobots.txtファイルが到達できない場合、これはrobots.txtファイルが未定義であり、クローラーが完全に禁止することを想定する必要があります。たとえば、HTTPのコンテキストでは、500〜599の範囲のステータスコードによってサーバーエラーが識別されます。
If the robots.txt file is undefined for a reasonably long period of time (for example, 30 days), crawlers MAY assume that the robots.txt file is unavailable as defined in Section 2.3.1.3 or continue to use a cached copy.
robots.txtファイルが適度に長期間（たとえば30日間）未定義の場合、クローラーはrobots.txtファイルがセクション2.3.1.3で定義されているように利用できないと仮定するか、キャッシュされたコピーの使用を続けます。
Crawlers MUST try to parse each line of the robots.txt file. Crawlers MUST use the parseable rules.
クローラーは、robots.txtファイルの各行を解析しようとする必要があります。クローラーは、断面可能なルールを使用する必要があります。
Crawlers MAY cache the fetched robots.txt file's contents. Crawlers MAY use standard cache control as defined in [RFC9111]. Crawlers SHOULD NOT use the cached version for more than 24 hours, unless the robots.txt file is unreachable.
クローラーは、Fetched Robots.txtファイルのコンテンツをキャッシュする場合があります。クローラーは、[RFC9111]で定義されているように標準のキャッシュ制御を使用できます。robots.txtファイルが到達不可能でない限り、クローラーは24時間以上キャッシュバージョンを使用しないでください。
Crawlers SHOULD impose a parsing limit to protect their systems; see Section 3. The parsing limit MUST be at least 500 kibibytes [KiB].
クローラーは、システムを保護するために解析制限を課す必要があります。セクション3を参照してください。解析制限は、少なくとも500キビバイト[KIB]でなければなりません。
The Robots Exclusion Protocol is not a substitute for valid content security measures. Listing paths in the robots.txt file exposes them publicly and thus makes the paths discoverable. To control access to the URI paths in a robots.txt file, users of the protocol should employ a valid security measure relevant to the application layer on which the robots.txt file is served -- for example, in the case of HTTP, HTTP Authentication as defined in [RFC9110].
ロボット除外プロトコルは、有効なコンテンツセキュリティ対策に代わるものではありません。robots.txtファイルのリストパスは公開され、パスを発見できるようにします。robots.txtファイル内のURIパスへのアクセスを制御するには、プロトコルのユーザーは、robots.txtファイルが提供されるアプリケーションレイヤーに関連する有効なセキュリティ測定を使用する必要があります。たとえば、httpの場合、httpの場合、[RFC9110]で定義されている認証。
To protect against attacks against their system, implementors of robots.txt parsing and matching logic should take the following considerations into account:
システムに対する攻撃から保護するために、robots.txtの解析と一致するロジックの実装者は、次の考慮事項を考慮に入れる必要があります。
Memory management: Section 2.5 defines the lower limit of bytes that must be processed, which inherently also protects the parser from out-of-memory scenarios.
メモリ管理：セクション2.5は、処理する必要があるバイトの下限を定義します。これは、本質的にメモリのシナリオからパーサーを保護します。
Invalid characters: Section 2.2 defines a set of characters that parsers and matchers can expect in robots.txt files. Out-of-bound characters should be rejected as invalid, which limits the available attack vectors that attempt to compromise the system.
無効な文字：セクション2.2では、パーサーとマッチャーがrobots.txtファイルで期待できる文字のセットを定義しています。バインドされていない文字は無効として拒否されるべきであり、システムを妥協しようとする利用可能な攻撃ベクトルを制限します。
Untrusted content: Implementors should treat the content of a robots.txt file as untrusted content, as defined by the specification of the application layer used. For example, in the context of HTTP, implementors should follow the Security Considerations section of [RFC9110].
信頼されていないコンテンツ：実装者は、使用されるアプリケーションレイヤーの仕様で定義されているように、Robots.txtファイルのコンテンツを信頼されていないコンテンツとして扱う必要があります。たとえば、HTTPのコンテキストでは、実装者は[RFC9110]のセキュリティに関する考慮事項セクションに従う必要があります。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
The following example shows:
次の例を示します。
*: A group that's relevant to all user agents that don't have an explicitly defined matching group. It allows access to the URLs with the /publications/ path prefix, and it restricts access to the URLs with the /example/ path prefix and to all URLs with a .gif suffix. The "*" character designates any character, including the otherwise-required forward slash; see Section 2.2.
*：明示的に定義されたマッチンググループを持たないすべてのユーザーエージェントに関連するグループ。/ Publications / Pathプレフィックスを備えたURLへのアクセスを可能にし、 /例 /パスプレフィックスを使用してURLへのアクセスを制限します。「*」キャラクターは、それ以外の要請されたフォワードスラッシュを含む、あらゆるキャラクターを指定します。セクション2.2を参照してください。
foobot: A regular case. A single user agent followed by rules. The crawler only has access to two URL path prefixes on the site -- /example/page.html and /example/allowed.gif. The rules of the group are missing the optional space character, which is acceptable as defined in Section 2.2.
Foobot：通常のケース。単一のユーザーエージェントに続いてルールが続きます。クローラーは、サイト上の2つのURLパスプレフィックス（ /example/page.htmlおよび /example/allowed.gifにのみアクセスできます。グループのルールには、セクション2.2で定義されているように許容されるオプションのスペース文字がありません。
barbot and bazbot: A group that's relevant for more than one user agent. The crawlers are not allowed to access the URLs with the /example/page.html path prefix but otherwise have unrestricted access to the rest of the URLs on the site.
Barbot and Bazbot：複数のユーザーエージェントに関連するグループ。クローラーは、 /example/page.htmlパスプレフィックスでURLにアクセスすることは許可されていませんが、サイト上の残りのURLへの無制限のアクセスがあります。
quxbot: An empty group at the end of the file. The crawler has unrestricted access to the URLs on the site.
quxbot：ファイルの最後にある空のグループ。クローラーは、サイト上のURLへの無制限のアクセスを持っています。
User-Agent: *
Disallow: *.gif$
Disallow: /example/
Allow: /publications/
User-Agent: foobot
Disallow:/
Allow:/example/page.html
Allow:/example/allowed.gif
User-Agent: barbot
User-Agent: bazbot
Disallow: /example/page.html
User-Agent: quxbot
ユーザーエージェント：quxbot
EOF
EOF
The following example shows that in the case of two rules, the longest one is used for matching. In the following case, /example/page/disallowed.gif MUST be used for the URI example.com/example/page/disallow.gif.
次の例は、2つのルールの場合、一致に最も長いルールが使用されることを示しています。次の場合、/example/page/disallowed.gifは、uri example.com/example/page/disallow.gifに使用する必要があります。
User-Agent: foobot
Allow: /example/page/
Disallow: /example/page/disallowed.gif
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, DOI 10.17487/RFC2046, November 1996, <https://www.rfc-editor.org/info/rfc2046>.
[RFC2046] Freed、N。およびN. Borenstein、「多目的インターネットメール拡張機能（MIME）パート2：メディアタイプ」、RFC 2046、DOI 10.17487/RFC2046、1996年11月、<https://www.rfc-editor.orgg/info/rfc2046>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487/RFC2119、1997年3月、<https://www.rfc-editor.org/info/RFC2119>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] Yergeau、F。、「UTF-8、ISO 10646の変換形式」、STD 63、RFC 3629、DOI 10.17487/RFC3629、2003年11月、<https://www.rfc-editor.org/info/RFC3629>。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、Std 66、RFC 3986、DOI 10.17487/RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ed。P. Overell、「構文仕様のためのBNFの増強：ABNF：STD 68、RFC 5234、DOI 10.17487/RFC5234、2008年1月、<https://www.rfc-editor.org/info/rfc5234>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「RFC 2119キーワードの大文字と小文字のあいまいさ」、BCP 14、RFC 8174、DOI 10.17487/RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487/RFC8288、2017年10月、<https://www.rfc-editor.org/info/rfc8288>。
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, <https://www.rfc-editor.org/info/rfc9110>.
[RFC9110] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "HTTP Semantics"、Std 97、RFC 9110、DOI 10.17487/RFC9110、2022年6月、<https：//www.rfc-editor.org/info/rfc9110>。
[RFC9111] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., "HTTP Caching", STD 98, RFC 9111, DOI 10.17487/RFC9111, June 2022, <https://www.rfc-editor.org/info/rfc9111>.
[RFC9111] Fielding、R.、Ed。、Ed。、Nottingham、M.、Ed。、およびJ. Reschke、ed。、 "Http Caching"、Std 98、RFC 9111、DOI 10.17487/RFC9111、2022年6月、<https：//www.rfc-editor.org/info/rfc9111>。
[KiB] "Kibibyte", Simple English Wikipedia, the free encyclopedia, 17 September 2020, <https://simple.wikipedia.org/wiki/Kibibyte>.
[kib] "kibibyte"、シンプルな英語ウィキペディア、無料百科事典、2020年9月17日、<https://simple.wikipedia.org/wiki/kibyte>。
[ROBOTSTXT] "The Web Robots Pages (including /robots.txt)", 2007, <https://www.robotstxt.org/>.
[RobotStxt]「Web Robots Pages（/robots.txtを含む）」、2007、<https://www.robotstxt.org/>。
[SITEMAPS] "What are Sitemaps? (Sitemap protocol)", April 2020, <https://www.sitemaps.org/index.html>.
[SiteMaps]「SiteMapsとは？（SiteMap Protocol）」、2020年4月、<https://www.sitemaps.org/index.html>。
Authors' Addresses
著者のアドレス
Martijn Koster Stalworthy Manor Farm Suton Lane Wymondham, Norfolk NR18 9JG United Kingdom Email: m.koster@greenhills.co.uk
Martijn Koster Stalworthy Manor Farm Suton Lane Wymondham、Norfolk NR18 9JG United Kingdom Email：m.koster@greenhills.co.uk
Gary Illyes Google LLC Brandschenkestrasse 110 CH-8002 Zürich Switzerland Email: garyillyes@google.com
Gary Illyes Google LLC Brandschenkestrasse 110 CH-8002ZürichSwitzerlandメール：garyillyes@google.com
Henner Zeller Google LLC 1600 Amphitheatre Pkwy Mountain View, CA 94043 United States of America Email: henner@google.com
Henner Zeller Google LLC 1600 Amphitheater Pkwy Mountain View、CA 94043アメリカ合衆国電子メール：henner@google.com
Lizzi Sassman Google LLC Brandschenkestrasse 110 CH-8002 Zürich Switzerland Email: lizzi@google.com
Lizzi Sassman Google LLC Brandschenkestrasse 110 CH-8002ZürichSwitzerlandメール：lizzi@google.com