http-semantics-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 9110 — HTTP Semantics （日本語訳）</title>

<link rel="stylesheet" href="common.css" type="text/css">
<link rel="stylesheet" href="http-common.css" type="text/css">

<script src="common0.js"></script>
<script src="http-common.js"></script>
<script src="common1.js" async></script>

<script type="text/plain" id="_source_data">

●●options

spec_title:HTTP Semantics
	spec_date:2022-06-06
trans_update:2023-11-08
source_checked:220606
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc9110.html
abbr_url:HTTPinfra
spec_status:IETFSTD
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2019-11-22

●●class_map

●●tag_map

●●original_id_map

●●mdn_urls
field.trailer:HTTP/Headers/Trailer
field.date:HTTP/Headers/Date

●●link_map

h.Access-Control-Request-Method:~FETCH#http-access-control-request-method
h.*:~HTTPinfra#field.asterisk

p.example-list-elmt:~HTTPinfra#p.example-list-elmt
p.example-list:~HTTPinfra#p.example-list

p.Content-Length:~HTTPsem#p.Content-Length
p.Content-Type:~HTTPsem#p.Content-Type
p.Date:~HTTPinfra#p.Date
p.Location:~HTTPsem#p.Location
p.Trailer:~HTTPinfra#p.Trailer
	P.NUL

c.bytes:~HTTPsem#_bytes
c.none:~HTTPsem#range-none
c.q:~HTTPsem#c.q
c.trailers:~HTTPsem#_trailers-token

sdir.must-understand:~HTTPcache#cache-response-directive.must-understand

役割:~HTTPinfra#role
接続:~HTTPinfra#connection
	参加者:~HTTPinfra#participant
加速器:~HTTPinfra#accelerator

絶対~形:#p.absolute-URI

~scheme:~HTTPinfra#p.scheme
~host:~HTTPinfra#p.host
~port:~HTTPinfra#p.port

生成元:~HTTPinfra#uri-origin

権限的:~HTTPinfra#authoritative
権限的な応答:~HTTPinfra#authoritative
	権限的な~access:~HTTPinfra#authoritative.access

複-部位t:~HTTPsem#multipart

要請~密入~攻撃:~HTTPv1#request.smuggling
鮮度~維持期間:~HTTPcache#freshness-lifetime

cite.~URI~scheme~registry:~IANA-a/uri-schemes/
cite.~HTTP~field名~registry:~IANA-a/http-fields
	:~IANA-a/http-fields/
cite.内容~符号法~registry:~IANA-a/http-parameters#content-coding
cite.~HTTP範囲~単位~registry:~IANA-a/http-parameters#range-units
cite.~HTTP~method~registry:~IANA-a/http-methods
cite.~HTTP状態s~code~registry:~IANA-a/http-status-codes
cite.~HTTP認証~scheme~registry:~IANA-a/http-authschemes
cite.~HTTP~Upgrade~token~registry:~IANA-a/http-upgrade-tokens
cite.~service名と~transport~protocol~port番号~registry:~IANA-a/service-names-port-numbers

禁止~要請~header:~FETCH#forbidden-request-header
~sf文字列:~STRUCTURED-FIELDS#sf-string

能力~URL:~CAPABILITY-URLS#dfn-capability-urls

	●rq/rs
sdir.private:~HTTPcache#cache-response-directive.private


	●§
著作者の~address:~HTTPinfra#rfc.authors

1:~HTTPinfra#introduction
1.1:~HTTPinfra#purpose
1.2:~HTTPinfra#history.and.evolution
1.3:~HTTPinfra#core.semantics
1.4:~HTTPinfra#specifications.obsoleted.by.this.document
2:~HTTPinfra#conformance
2.1:~HTTPinfra#notation
2.2:~HTTPinfra#requirements.notation
2.3:~HTTPinfra#length.requirements
2.4:~HTTPinfra#error.handling
2.5:~HTTPinfra#protocol.version
3:~HTTPinfra#terminology
3.1:~HTTPinfra#resources
3.2:~HTTPinfra#representations
3.3:~HTTPinfra#connections
3.4:~HTTPinfra#messages
3.5:~HTTPinfra#user.agent
3.6:~HTTPinfra#origin.server
3.7:~HTTPinfra#intermediaries
3.8:~HTTPinfra#caches
3.9:~HTTPinfra#example
4:~HTTPinfra#uri
4.1:~HTTPinfra#uri.references
4.2:~HTTPinfra#uri.schemes
4.2.1:~HTTPinfra#http.uri
4.2.2:~HTTPinfra#https.uri
4.2.3:~HTTPinfra#uri.comparison
4.2.4:~HTTPinfra#http.userinfo
4.2.5:~HTTPinfra#uri.fragment.identifiers
4.3:~HTTPinfra#authoritative.access
4.3.1:~HTTPinfra#origin
4.3.2:~HTTPinfra#http.origin
4.3.3:~HTTPinfra#https.origin
4.3.4:~HTTPinfra#https.verify
4.3.5:~HTTPinfra#https.ip-id

5.1:~HTTPinfra#fields.names
5.2:~HTTPinfra#field.lines
5.3:~HTTPinfra#fields.order
5.4:~HTTPinfra#fields.limits
5.5:~HTTPinfra#fields.values
5.6:~HTTPinfra#fields.components
5.6.1:~HTTPinfra#abnf.extension
5.6.1.1:~HTTPinfra#abnf.extension.sender
5.6.1.2:~HTTPinfra#abnf.extension.recipient
5.6.2:~HTTPinfra#tokens
5.6.3:~HTTPinfra#whitespace
5.6.4:~HTTPinfra#quoted.strings
5.6.5:~HTTPinfra#comments
5.6.6:~HTTPinfra#parameter
5.6.7:~HTTPinfra#http.date
6:~HTTPinfra#message.abstraction
6.1:~HTTPinfra#message.framing
6.2:~HTTPinfra#message.control.data
6.3:~HTTPinfra#header.fields
6.4:~HTTPinfra#content
6.4.1:~HTTPinfra#content.semantics
6.4.2:~HTTPinfra#identifying.content
6.5:~HTTPinfra#trailer.fields
6.5.1:~HTTPinfra#trailers.limitations
6.5.2:~HTTPinfra#trailers.processing
6.6:~HTTPinfra#message.metadata
6.6.1:~HTTPinfra#field.date
6.6.2:~HTTPinfra#field.trailer

7:~HTTPsem#routing
7.1:~HTTPsem#target.resource
7.2:~HTTPsem#field.host
7.3:~HTTPsem#routing.inbound
7.3.1:~HTTPsem#routing.cache
7.3.2:~HTTPsem#routing.proxy
7.3.3:~HTTPsem#routing.origin
7.4:~HTTPsem#routing.reject
7.5:~HTTPsem#response.correlation
7.6:~HTTPsem#message.forwarding
7.6.1:~HTTPsem#field.connection
7.6.2:~HTTPsem#field.max-forwards
7.6.3:~HTTPsem#field.via
7.7:~HTTPsem#message.transformations
7.8:~HTTPsem#field.upgrade
8:~HTTPsem#representation.data.and.metadata
8.1:~HTTPsem#representation.data
8.2:~HTTPsem#representation.metadata
8.3:~HTTPsem#field.content-type
8.3.1:~HTTPsem#media.type
8.3.2:~HTTPsem#charset
8.3.3:~HTTPsem#multipart.types
8.4:~HTTPsem#field.content-encoding
8.4.1:~HTTPsem#content.codings
8.4.1.1:~HTTPsem#compress.coding
8.4.1.2:~HTTPsem#deflate.coding
8.4.1.3:~HTTPsem#gzip.coding
8.5:~HTTPsem#field.content-language
8.5.1:~HTTPsem#language.tags
8.6:~HTTPsem#field.content-length
8.7:~HTTPsem#field.content-location
8.8:~HTTPsem#response.validator
8.8.1:~HTTPsem#weak.and.strong.validators
8.8.2:~HTTPsem#field.last-modified
8.8.2.1:~HTTPsem#lastmod.generation
8.8.2.2:~HTTPsem#lastmod.comparison
8.8.3:~HTTPsem#field.etag
8.8.3.1:~HTTPsem#entity.tag.generation
8.8.3.2:~HTTPsem#entity.tag.comparison
8.8.3.3:~HTTPsem#example.entity.tag.vs.conneg
9:~HTTPsem#methods
9.1:~HTTPsem#method.overview
9.2:~HTTPsem#method.properties
9.2.1:~HTTPsem#safe.methods
9.2.2:~HTTPsem#idempotent.methods
9.2.3:~HTTPsem#cacheable.methods
9.3:~HTTPsem#method.definitions
9.3.1:~HTTPsem#GET
9.3.2:~HTTPsem#HEAD
9.3.3:~HTTPsem#POST
9.3.4:~HTTPsem#PUT
9.3.5:~HTTPsem#DELETE
9.3.6:~HTTPsem#CONNECT
9.3.7:~HTTPsem#OPTIONS
9.3.8:~HTTPsem#TRACE
10:~HTTPsem#context
10.1:~HTTPsem#request.context
10.1.1:~HTTPsem#field.expect
10.1.2:~HTTPsem#field.from
10.1.3:~HTTPsem#field.referer
10.1.4:~HTTPsem#field.te
10.1.5:~HTTPsem#field.user-agent
10.2:~HTTPsem#response.context
10.2.1:~HTTPsem#field.allow
10.2.2:~HTTPsem#field.location
10.2.3:~HTTPsem#field.retry-after
10.2.4:~HTTPsem#field.server
11:~HTTPsem#authentication
11.1:~HTTPsem#auth.scheme
11.2:~HTTPsem#auth.params
11.3:~HTTPsem#challenge.and.response
11.4:~HTTPsem#credentials
11.5:~HTTPsem#protection.space
11.6:~HTTPsem#auth.user.origin.server
11.6.1:~HTTPsem#field.www-authenticate
11.6.2:~HTTPsem#field.authorization
11.6.3:~HTTPsem#field.authentication-info
11.7:~HTTPsem#auth.client.proxy
11.7.1:~HTTPsem#field.proxy-authenticate
11.7.2:~HTTPsem#field.proxy-authorization
11.7.3:~HTTPsem#field.proxy-authentication-info
12:~HTTPsem#content.negotiation
12.1:~HTTPsem#proactive.negotiation
12.2:~HTTPsem#reactive.negotiation
12.3:~HTTPsem#request.content.negotiation
12.4:~HTTPsem#conneg.features
12.4.1:~HTTPsem#conneg.absent
12.4.2:~HTTPsem#quality.values
12.4.3:~HTTPsem#wildcard.values
12.5:~HTTPsem#conneg.fields
12.5.1:~HTTPsem#field.accept
12.5.2:~HTTPsem#field.accept-charset
12.5.3:~HTTPsem#field.accept-encoding
12.5.4:~HTTPsem#field.accept-language
12.5.5:~HTTPsem#field.vary
13:~HTTPsem#conditional.requests
13.1:~HTTPsem#preconditions
13.1.1:~HTTPsem#field.if-match
13.1.2:~HTTPsem#field.if-none-match
13.1.3:~HTTPsem#field.if-modified-since
13.1.4:~HTTPsem#field.if-unmodified-since
13.1.5:~HTTPsem#field.if-range
13.2:~HTTPsem#evaluation
13.2.1:~HTTPsem#when.to.evaluate
13.2.2:~HTTPsem#precedence
14:~HTTPsem#range.requests
14.1:~HTTPsem#range.units
14.1.1:~HTTPsem#range.specifiers
14.1.2:~HTTPsem#byte.ranges
14.2:~HTTPsem#field.range
14.3:~HTTPsem#field.accept-ranges
14.4:~HTTPsem#field.content-range
14.5:~HTTPsem#partial.PUT
14.6:~HTTPsem#multipart.byteranges
15:~HTTPsem#status.codes
15.1:~HTTPsem#overview.of.status.codes
15.2:~HTTPsem#status.1xx
15.2.1:~HTTPsem#status.100
15.2.2:~HTTPsem#status.101
15.3:~HTTPsem#status.2xx
15.3.1:~HTTPsem#status.200
15.3.2:~HTTPsem#status.201
15.3.3:~HTTPsem#status.202
15.3.4:~HTTPsem#status.203
15.3.5:~HTTPsem#status.204
15.3.6:~HTTPsem#status.205
15.3.7:~HTTPsem#status.206
15.3.7.1:~HTTPsem#partial.single
15.3.7.2:~HTTPsem#partial.multipart
15.3.7.3:~HTTPsem#combining.byte.ranges
15.4:~HTTPsem#status.3xx
15.4.1:~HTTPsem#status.300
15.4.2:~HTTPsem#status.301
15.4.3:~HTTPsem#status.302
15.4.4:~HTTPsem#status.303
15.4.5:~HTTPsem#status.304
15.4.6:~HTTPsem#status.305
15.4.7:~HTTPsem#status.306
15.4.8:~HTTPsem#status.307
15.4.9:~HTTPsem#status.308
15.5:~HTTPsem#status.4xx
15.5.1:~HTTPsem#status.400
15.5.2:~HTTPsem#status.401
15.5.3:~HTTPsem#status.402
15.5.4:~HTTPsem#status.403
15.5.5:~HTTPsem#status.404
15.5.6:~HTTPsem#status.405
15.5.7:~HTTPsem#status.406
15.5.8:~HTTPsem#status.407
15.5.9:~HTTPsem#status.408
15.5.10:~HTTPsem#status.409
15.5.11:~HTTPsem#status.410
15.5.12:~HTTPsem#status.411
15.5.13:~HTTPsem#status.412
15.5.14:~HTTPsem#status.413
15.5.15:~HTTPsem#status.414
15.5.16:~HTTPsem#status.415
15.5.17:~HTTPsem#status.416
15.5.18:~HTTPsem#status.417
15.5.19:~HTTPsem#status.418
15.5.20:~HTTPsem#status.421
15.5.21:~HTTPsem#status.422
15.5.22:~HTTPsem#status.426
15.6:~HTTPsem#status.5xx
15.6.1:~HTTPsem#status.500
15.6.2:~HTTPsem#status.501
15.6.3:~HTTPsem#status.502
15.6.4:~HTTPsem#status.503
15.6.5:~HTTPsem#status.504
15.6.6:~HTTPsem#status.505

16:~HTTPinfra#extending
16.1:~HTTPinfra#method.extensibility
16.1.1:~HTTPinfra#method.registry
16.1.2:~HTTPinfra#considerations.for.new.methods
16.2:~HTTPinfra#status.code.extensibility
16.2.1:~HTTPinfra#status.code.registry
16.2.2:~HTTPinfra#considerations.for.new.status.codes
16.3:~HTTPinfra#fields.extensibility
16.3.1:~HTTPinfra#fields.registry
16.3.2:~HTTPinfra#considerations.for.new.fields
16.3.2.1:~HTTPinfra#considerations.for.new.field.names
16.3.2.2:~HTTPinfra#considerations.for.new.field.values
16.4:~HTTPinfra#auth.scheme.extensibility
16.4.1:~HTTPinfra#auth.scheme.registry
16.4.2:~HTTPinfra#considerations.for.new.auth.schemes
16.5:~HTTPinfra#range.unit.extensibility
16.5.1:~HTTPinfra#range.unit.registry
16.5.2:~HTTPinfra#considerations.for.new.range.units
16.6:~HTTPinfra#content.coding.extensibility
16.6.1:~HTTPinfra#content.coding.registry
16.6.2:~HTTPinfra#considerations.for.new.content.codings
16.7:~HTTPinfra#upgrade.token.registry
17:~HTTPinfra#security.considerations
17.1:~HTTPinfra#establishing.authority
17.2:~HTTPinfra#risks.intermediaries
17.3:~HTTPinfra#attack.pathname
17.4:~HTTPinfra#attack.injection
17.5:~HTTPinfra#attack.protocol.element.length
17.6:~HTTPinfra#compression.attacks
17.7:~HTTPinfra#personal.information
17.8:~HTTPinfra#privacy.of.server.log.information
17.9:~HTTPinfra#sensitive.information.in.uris
17.10:~HTTPinfra#underscore.in.fields
17.11:~HTTPinfra#fragment.disclosure
17.12:~HTTPinfra#disclosure.product.information
17.13:~HTTPinfra#fingerprinting
17.14:~HTTPinfra#security.validators
17.15:~HTTPinfra#overlapping.ranges
17.16:~HTTPinfra#security.auth
17.16.1:~HTTPinfra#confidentiality.of.credentials
17.16.2:~HTTPinfra#auth.credentials.and.idle.clients
17.16.3:~HTTPinfra#protection.spaces
17.16.4:~HTTPinfra#security.auth.add.resp
18:~HTTPinfra#IANA.considerations
18.1:~HTTPinfra#uri.scheme.registration
18.2:~HTTPinfra#method.registration
18.3:~HTTPinfra#status.code.registration
18.4:~HTTPinfra#field.name.registration
18.5:~HTTPinfra#auth.scheme.registration
18.6:~HTTPinfra#content.coding.registration
18.7:~HTTPinfra#range.unit.registration
18.8:~HTTPinfra#media.type.reg
18.9:~HTTPinfra#port.reg
18.10:~HTTPinfra#upgrade.token.registration
19:~HTTPinfra#rfc.references
19.1:~HTTPinfra#rfc.references.1
19.2:~HTTPinfra#rfc.references.2
A:~HTTPinfra#collected.abnf
B:~HTTPinfra#changes.from.previous.rfcs
B.1:~HTTPinfra#changes.from.rfc.2818
B.2:~HTTPinfra#changes.from.rfc.7230
B.3:~HTTPinfra#changes.from.rfc.7231
B.4:~HTTPinfra#changes.from.rfc.7232
B.5:~HTTPinfra#changes.from.rfc.7233
B.6:~HTTPinfra#changes.from.rfc.7235
B.7:~HTTPinfra#changes.from.rfc.7538
B.8:~HTTPinfra#changes.from.rfc.7615
B.9:~HTTPinfra#changes.from.rfc.7694

	#acks
	#rfc.index
	#rfc.authors

uri.2.1:~RFCx/rfc3986#section-2.1
uri.2.2:~RFCx/rfc3986#section-2.2
uri.3.2:~RFCx/rfc3986#section-3.2
uri.3.2.1:~RFCx/rfc3986#section-3.2.1
uri.3.2.2:~RFCx/rfc3986#section-3.2.2
uri.3.2.3:~RFCx/rfc3986#section-3.2.3
uri.3.3:~RFCx/rfc3986#section-3.3
uri.3.4:~RFCx/rfc3986#section-3.4
uri.3.5:~RFCx/rfc3986#section-3.5
uri.4.1:~RFCx/rfc3986#section-4.1
uri.4.2:~RFCx/rfc3986#section-4.2
uri.4.3:~RFCx/rfc3986#section-4.3
uri.6:~RFCx/rfc3986#section-6
uri.6.2:~RFCx/rfc3986#section-6.2
uri.6.2.2:~RFCx/rfc3986#section-6.2.2
uri.6.2.3:~RFCx/rfc3986#section-6.2.3
uri.7:~RFCx/rfc3986#section-7


●●words_table1
CAPABILITY-URLS:capability-urls-ja.html
RFC7231:RFC7231-ja.html

●●words_table

	●network／環境
UNIX:
IP:
DNS:
HTTP-to-HTTP:
HTTP2:HTTP/2
HTTP3:HTTP/3
HTTP09:HTTP/0.9
	~web~site:website
NTP:
UDP:
QUIC:
HPACK:
CDN:
CN-ID:
IP-ID:
DNS-ID:
CGI:
hostname::::ホスト名
	~frame法:framing
multicast::::マルチキャスト
broadcast::::ブロードキャスト
off-line::::オフライン
worldwide:
	^en:peer
区割り:partitioning:~
負荷分散-:load balance::~
負荷分散:load balancing::~
消費:consumption:~
多重化-:multiplex::~
局地的:regional::~
配布:distribution:~
	World Wide Web
	通過-:pass through
portal::::ポータル
隣接点:neighbor::~
外向けの:outgoing:~

	●構文
US-ASCII:
underscore::::アンダースコア
period::::ピリオド
エスケープ:quote::~
空白列:linear whitespace::~
印字可能:visual:~
小数点:decimal point:~
英字:letter:~
数量-:numeric:~
丸括弧:parentheses:~
正規:normal::~
構成-:compose:~
英数字:alphanumeric character:~
封入-:enclose:~
省かれ:elideされ:~
後続-:follow:~
sf:<sub>sf-</sub>
収まる:fitする:~
剥取る:stripする:剥ぎ取る
書込n:write::書き込み
折返し:folding::~

	固定的な長さ:fixed-length
	前後:around
	引用符~無し:unquoted
	引用符~付き:quoted
	引用符の有無:unquoted
	wildcard^p:wildcard
	文字大小区別で:case-sensitive manner

	●処理一般
background::::バックグラウンド
維持期間:lifetime::~
	維持期間:time
listener::::リスナ
流れる:flowする:~
切落して:truncateして:切り落として
稼働時:run-time:~
延長-:extend:~
増やさ:incrementさ:~
増分的:incremental:~
再組成:recomposition:~
時間的:temporal:~
処理命令:processing instructions:~
上書-:overwrite::上書き
走査-:scan:~
checksum::::チェックサム
等価性:equivalence:~
一掃-:purge:~

	●保安
phishing::::フィッシング
罠:pitfall:落とし穴
反射攻撃:replay attack::~
密入:smuggling::~
真正性:authenticity::~
能動的:active::~
証明書:certificate::~
識別情報:identity::~
不特定多数の:multitude:~
銘柄:branding:~
流出:publish:~
本物の:realな:~
集めら:gatherさ:~
危険:dangerous:~
匿名化:anonymization:~
疑似匿名:pseudonymous:~
	~~感受性が~~高い:susceptible
overflow::::オーバーフロー
予防策:precaution:~
個人識別可能:personally-identifiable:~
厄介な:annoying:~
民族:ethnic group:~
防ぐ:prevent する:~
防護:guard::~
製品:product::~
維持:retention:~
未保護:unprotected::~
秘密鍵:private key::~
鍵:key::~
監査:audit:~
不用意:accidental:~
証明:proof:~
権威ある:definitiveな:~
帰属-:attribute:~
冗長性:redundancy::~
SQL:
採取-:harvest:~
隠蔽-:obscure:~
欠陥:flaw:~
盗聴:theft:~

	信用に価する:trustworthy
	晒され:-
	~~無防備に:leaves 〜 open
	~secure化され:secured
	~secure化されていない:unsecured
	誤って~directされ:misdirected
	なりすます:impersonation


	●仕様
誤誘導:mislead:~
場当的:ad hoc:場当たり的
scale::::スケール
	~scale能:scalability
mailing-list:mailing list:::メーリングリスト
確認:confirmation:~
行動様式:reading pattern:~
関心事:subjects of interest:~
確立:establishment::~
無視r:disregard:無視することに
動詞:verb:~
代表者:delegate:~
任命-:appoint:~
指名-:designate:~
専門家:expert:~
助言:advice:~:::アドバイス
暫定的:provisional:~
協議:consultation:~
規制:regulations:~
法律:laws:~
発展-:evolve:~
発展:evolution:~
甚しい:egregiousな:~
拒否-:refuse:~
時事的:topical:~
論題:topic:~
解決s:solve:解決
	成員であること:membership
補助的:auxiliary:~
事実調査:research:~
限定-:confine:~
推定-:infer:~
矛盾-:contradict:~
解釈器:interpreter:~
指示書き:instruction:~
指示命令:instruction:~
必要最小限:minimal:~
過剰:superfluous:~
俗に:colloquialに:~
超越-:transcend:~
揃える:alignする:~
拡げら:expandさ:~
拡げる:expandする:~
人為的:artificial:~
手配-:arrange:~
	予め手配-:prearrange
機能:function:~
地点:point:~
復旧-:restore::~
参照r:refer:参照
進展-:progress:~
成長-:grow:~
些細:trivial:~
独立性:independence:~
邪魔-:hinder:~
馴染み:familiar:~
noise::::ノイズ
非推奨化:deprecation:~
裁量:discretion:~
賢明:smart:~
質問:question:~
焼付ける:bakeする:焼き付ける
収容能:capacity:~
流儀:fashion:~
模倣-:emulate:~
全般的な:overall:~
働得る:workし得る:働き得る
防御的:defensive:~
拙く:poorに:~
妨げる:inhibitする:~
惑わす:confuseする:~
拙く:poorに:~
直交的:orthogonal:~
誤解釈-:misinterpret:~
見合う:reasonableな:~
策:strategy:~
権利:right:~
明白:obvious:~
責任-:responsible::~
連絡:contact:~
総意:consensus:~
素朴:naive:~
不作為:inadvertent:~
根幹:fundamental:~
廃用d:obsoleted:廃用
根拠:evidence:~
参考:informational:~
過度:excessive:~
direction::::ダイレクション
	~directionの下で:at the direction of
周知:well-known:~
	よく知られた:well-known

	~~再構成-:refactor
	~~再構成-:reconstitute
	IESG
	^en:standards track
	実効:effective
	読み易く:readability を improve
	引き換え:commission
	~~明らか:apparent
	~~見かけの:apparent
	見かけ:look
	必要十分でない:inadequate
	~~簡単に:readily
	〜に~~適した:readily
	関知しない:no awareness
	受け持つ:partake／-
	~~無関心に:without regard to
	親切さ:-friendliness
	遂げられ:carried out
	~~講じる:take
	~~究極の~privacy~~保護措置:extreme privacy measure
	~~順調:nicely
	より~~適化する:optimistic
	~~最善:at best
	~~最悪:at worst
	勧める:advised to
	立場にある:privy
	立場に:position
	成せる~~立場にある:situated for
	~~帰属:vesting
	〜とも呼ばれる:a.k.a
	当を得た選択〜right choice
	~~高度:high degree of
	~~総称される:collectively referred to as
	ごく ありふれている:extremely common
	そのため:To that end
	無用:needless／:needlessly
	独り占め:squatting
	失敗した所:in the event of 〜 failure
	限定的に利用される:limited-use
	略語:abbreviation
	~~頭字語:abbreviation
	Foo
	Application
	Description
	よって:hence
	イミを成し得る:sensible
	問わず:regardless
	アリ性:possibility
	~~可能性:potential
	~~可能性もある:potentially
	〜としても:potential
	なり得る:potential
	くつがえす:unmade
	必要がある:will necessarily
	とても:very
	最小でも:at a minimum
	少なくとも〜に足る:sufficient minimum
	少なくとも:minimum
	そのため、:and consequently
	〜は別として:aside from
	優先-:take precedence
	踏んで:take
	今や:now
	~~緩め:loosen
	好ましい:preferably
	に特有なそれ:specifics of
	区別:distinctions
	有用さ:usefulness
	何者か:whomever
	ごく:very
	そうであっても:nevertheless
	用意はない:unwilling
	その結果:in turn
	等しく責を負う:equally responsible
	割愛する:leaves out
	避けれない:unavoidable
	~~恒久的に居残る:stays forever
	窓口:point of
	予め〜と見做される資源:presumed
	~~前提:presume
	始まった:began
	誤って:erroneously
	際どい:edge-
	調べる:looking at
	等しくみなされがち:being equated with
	考えに囚われがち:misled into thinking
	資質からして:in nature
	力点を置く傾向に:tend to focus on
	~~仕向ける:telling
	環境設定-能:configurability
	まず予期しない:least expected
	賢明でない:unwise
	特に関心を引くもの:of particular interest
	単純にするため:for simplicity
	-:fashion
	依存しない:independent
	判別-不能:indistinguishable
	期待されるもの:expectation
	再度〜促す:re-prompt
	多種多様:wide variety of
	僅か:tiny
	~~事前の:advance
	~~適用する:target
	もたらす／原因になる:cause
	経る中で:over the course of
	し続ける:continue
	~~多岐に~~渡る:vary widely
	目立つ様に:prominently
	繋がる:becomes an avenue
	~~補強-:aid
	誰も:anyone
	~~生じさせた:resulted in
	束縛される:bound to
	場を占める:take place
	仕様~化が要求される:Specification Required
	草案~化:drafting
	助力-:help:~
	課して:impose
	抗して:against
	得るために:sake
	適合する:conformant
	〜し易く:easier
	よって:hence
	自身が認識しない:unrecognized
	他と線引きされ:delineate
	大概は:presumably
	用途:use
	反例:counter-example
	〜所まで:extent
	〜以外は期待しない下で:with only marginal expectations that 〜
	向こう側で独立に動作する者:independent actor on the other side
	その場を占める:take the place of
	手引き:help guide
	許容する必要がある:cannot disallow
	正確aに〜しない:inaccurate
	他の適合性に反しない限り:while remaining conformant to
	該当する実装:the implementations at fault:
	〜に価する:deserve
	各個人:individual
	とは別に:aside form
	どちらなのかは:to disambiguate
	にも見える:seemingly
	と称され:titled
	旧-:old
	それは〜転じる:In turn,

	●事例
加速器:accelerator::~::アクセラレータ
巡る:crawlする:~
広告塔:billboard screens:~
家電:household appliance:~
	home appliance
電球:light bulb:~
firmware::::ファームウェア
計測機器:scale:~
交通camera:traffic camera:交通カメラ
real-time::::リアルタイム
広告選定器:ad selector::~
住宅用自動化設備:home automation unit:~
事務機械:office machine:OA 機器
自律的:autonomous:~
robot::::ロボット
news-feed:news feed:::ニュースフィード
	ad selectors:
動画配信:video-on-demand::動画配信::ビデオ配信
mobile::::モバイル
国別:national:~
分析:analysis:~
spider::::スパイダー
command-line::::コマンドライン
point::::ポイント
	~access~point
multi-tenant::::マルチテナント
logout::::ログアウト
commit:
directory::::ディレクトリ
subscription:
display::::ディスプレイ
企業:corporate:~

	各用紙に刷られる:added to templates
	~sizeや形状が様々な:in a multitude of shapes and sizes
	富士山:Laguna Beach
	天気:weather
	気象情報:weather report

	●未分類
Upgrade:
検索:lookup::~
透過的:transparent::~
digital::::デジタル
	その~code化:coding
単線:linear:~
形状:shape:~
中間:intermediation:~
仮想:virtual::~
未登録:unregistered:~
	傾向:tendency
	傾向に:tendに

文0:statement::文
時間帯:zone::~
遅い:slowな:~
変形-:transform::~
固定的:fixed:~
完全さ:completeness:~
計量:metrics:~
人気:popular:~
窓:window:~
連合-:federate:~
算術的:arithmetic:~
meta-::::メタ
	~meta-変数:meta-variable
瞬間:moment:~
分解-:decompose:~
p-s-r-r-t:pages, sections, records, rows, time:::ページ, セクション, レコード, 行, 時区間

	:begin
	始めの方:beginning
	通過中:in transit
	通過中:during transit
	失われ:lost
	組:triple
	-:lookup table
	個数:cardinality
	0 〜 1 個の／ 0 個以上の:potential
	encryption
	Microsoft Windows
	渡-:pass
	~~大文字頭字:capitalization
	~~前身:predecessor
	~~グリニッジ~~平均時
	？:conclude
	~webを辿っている:web-traversing
	〜列:sequence of
	列:sequence

	●言い換え
	依存-:dependent
	参照を解く:dereference
	環境設定:configuration setting
	伝送路~上の:on-wire
	伝送-:transmission
	運用~上の:operational
	期間は〜不定:indefinitely
	期間:time period
	転送~符号法:transfer-codings
	何らかの型の:some type(s)
	結合し直:recombine
	暗号化されてない:unencrypted
	拘束されない:unconstrained
	労力:effort required
	中核を成す:core
	識別-用:identifying
	現れる:appear
	当の:the respective
	まず〜ない:least
	~frame化:framing
	一握り:small percentage
	時刻がずれる:somewhat different times
	改善:improve
	準備-:preparation
	までの~version:and earlier
	一連の:sequence of
	単数~field:fields with a singleton value
	単数~field:single value is anticipated
	発見-:discovery
	全-範囲の:full range of
	それにつきまとう:the associated
	複数の:different
	`RFC5322$r:Internet Message Format
	ある構文-代替:at least one alternative
	複-部位t:multipart

	●他の語
	^i:ORIGIN
	どんなものでも:anything
	早く:early
	位置:position
	順不同:out of order
	^en:auditing
	^en:fraud control
	`DQUOTE$P:double-quote mark
	message回送:message-forwarding
	渡り歩く:travel
	一連の:sequence
	~~多量ではない:not so much
	~~多量:large amounts
	通り抜けられるようにする:satisfy〜through
	~~長大:very long
	~~長過ぎる:too long
	~~伝える:tell
	際限なく続く:unbounded
	あらゆるもの:everything
	文字大小の正規化:case-normalization
	抗-:against
	短い:short
	大方:mostly
	最終的に:ultimately
	ゆくゆくは:eventually
	他よりずっと:by far the most
	の近くに:closer
	置く:placing
	〜までは:〜and earlier
	各部:parts
	低-:low-
	待時間が長い:high-latency
	次に:next
	より高い:higher
	最も高い:highest
	より高い:greater
	より広:greater
	より広い:larger
	より広く:broader
	広く:widely
	広範:wide range of
	とは限らない:not all
	~~各部:portions
	多大な:great
	~~直前:just before
	~~現在時:current instant
	旧い:old
	旧い:older
	に属する:fall under

●●section_map
	#rfc.abstract:SECTION
	#rfc.note.1:SECTION
	#rfc.status:SECTION
	#rfc.copyrightnotice:SECTION

	謝辞:~HTTPsem#acks:
	index:~HTTPsem#rfc.index
	著作者:~HTTPsem#rfc.authors

●●ref_data
RFC7541=副            syucream.github.io/hpack-spec-ja/rfc7541-ja.html
RFC6585=副            ~/http-status-code-428-429-431-511-ja.html
RFC8246=副            ~/http-immutable-response-ja.html
RFC7694=副            ~/http-accept-encoding-response-header-ja.html
SNIFFING=副           ~/mimesniff-ja.html

●●ref_key_map
TCP:RFC793
TLS13:RFC8446
ALTSVC:RFC7838
HPACK:RFC7541
HTTP10:RFC1945
WEBDAV:RFC4918
BCP13:RFC6838
BCP35:RFC7595
BCP178:RFC6648

●●ref_normative

[CACHING]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP Caching＞, STD 98, ~RFC9111, June 2022
    URL: https://httpwg.org/specs/rfc9111.html
[RFC1950]
    Deutsch, P. and J-L. Gailly, ＜ZLIB Compressed Data Format Specification version 3.3＞, ~RFC1950, May 1996
[RFC1951]
    Deutsch, P., ＜DEFLATE Compressed Data Format Specification version 1.3＞, ~RFC1951, May 1996
[RFC1952]
    Deutsch, P., ＜GZIP file format specification version 4.3＞, ~RFC1952, May 1996
[RFC2046]
    Freed, N. and N. Borenstein, ＜Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types＞, ~RFC2046, November 1996
[RFC2119]
    Bradner, S., ＜Key words for use in RFCs to Indicate Requirement Levels＞, BCP 14, ~RFC2119, March 1997
[RFC4647]
    Phillips, A., Ed. and M. Davis, Ed., ＜Matching of Language Tags＞, BCP 47, ~RFC4647, September 2006
[RFC4648]
    Josefsson, S., ＜The Base16, Base32, and Base64 Data Encodings＞, ~RFC4648, October 2006
[RFC5234]
    Crocker, D., Ed. and P. Overell, ＜Augmented BNF for Syntax Specifications: ABNF＞, STD 68, ~RFC5234, January 2008
[RFC5280]
    Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, ＜Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile＞, ~RFC5280, May 2008
[RFC5322]
    Resnick, P., Ed., ＜Internet Message Format＞, ~RFC5322, October 2008
[RFC5646]
    Phillips, A., Ed. and M. Davis, Ed., ＜Tags for Identifying Languages＞, BCP 47, ~RFC5646, September 2009
[RFC6125]
    Saint-Andre, P. and J. Hodges, ＜Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)＞, ~RFC6125, March 2011
[RFC6365]
    Hoffman, P. and J. Klensin, ＜Terminology Used in Internationalization in the IETF＞, BCP 166, ~RFC6365, September 2011
[RFC7405]
    Kyzivat, P., ＜Case-Sensitive String Support in ABNF＞, ~RFC7405, December 2014
[RFC8174]
    Leiba, B., ＜Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words＞, BCP 14, ~RFC8174, May 2017
[TCP]
    Postel, J., ＜Transmission Control Protocol＞, STD 7, ~RFC793, September 1981
[TLS13]
    Rescorla, E., ＜The Transport Layer Security (TLS) Protocol Version 1.3＞, ~RFC8446, August 2018
[URI]
    Berners-Lee, T., Fielding, R., and L. Masinter, ＜Uniform Resource Identifier (URI): Generic Syntax＞, STD 66, ~RFC3986, January 2005
[USASCII]
    American National Standards Institute, ＜Coded Character Set -- 7-bit American Standard Code for Information Interchange＞, ANSI X3.4, 1986.
[Welch]
    Welch, T., ＜A Technique for High-Performance Data Compression＞, IEEE Computer 17(6), June 1984
    URL: https://ieeexplore.ieee.org/document/1659158/

●●ref_informative

[ALTSVC]
    Nottingham, M., McManus, P., and J. Reschke, ＜HTTP Alternative Services＞, ~RFC7838, April 2016
[BCP13]
    Freed, N. and J. Klensin, ＜Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures＞, BCP 13, ~RFC4289, December 2005.
    Freed, N., Klensin, J., and T. Hansen, ＜Media Type Specifications and Registration Procedures＞, BCP 13, ~RFC6838, January 2013
    URL: https://www.rfc-editor.org/info/bcp13
[BCP178]
    Saint-Andre, P., Crocker, D., and M. Nottingham, ＜Deprecating the "X-" Prefix and Similar Constructs in Application Protocols＞, BCP 178, ~RFC6648, June 2012
    URL: https://www.rfc-editor.org/info/bcp178
[BCP35]
    Thaler, D., Ed., Hansen, T., and T. Hardie, ＜Guidelines and Registration Procedures for URI Schemes＞, BCP 35, ~RFC7595, June 2015
    URL: https://www.rfc-editor.org/info/bcp35
[BREACH]
    Gluck, Y., Harris, N., and A. Prado, ＜BREACH: Reviving the CRIME Attack＞, July 2013, URL: http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
[Bujlow]
    Bujlow, T., Carela-Español, V., Solé-Pareta, J., and P. Barlet-Ros, ＜A Survey on Web Tracking: Mechanisms, Implications, and Defenses＞, Proceedings of the IEEE 105(8), August 2017.
    URL: http://dx.doi.org/10.1109/JPROC.2016.2637878
[COOKIE]
    Barth, A., ＜HTTP State Management Mechanism＞, ~RFC6265, April 2011
[Err1912]
    RFC Errata, ＜Erratum ID 1912＞, RFC 2978, URL: https://www.rfc-editor.org/errata/eid1912
[Err5433]
    RFC Errata, ＜Erratum ID 5433＞, RFC 2978, URL: https://www.rfc-editor.org/errata/eid5433
[Georgiev]
    Georgiev, M., Iyengar, S., Jana, S., Anubhai, R., Boneh, D., and V. Shmatikov, ＜The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software＞, DOI 10.1145/2382196.2382204, In Proceedings of the 2012 ACM Conference on Computer and Communications Security (CCS '12), pp. 38-49, October 2012. URL: http://dx.doi.org/10.1145/2382196.2382204
[HPACK]
    Peon, R. and H. Ruellan, ＜HPACK: Header Compression for HTTP/2＞, ~RFC7541, May 2015
[HTTP/1.0]
    Berners-Lee, T., Fielding, R., and H. Frystyk, ＜Hypertext Transfer Protocol -- HTTP/1.0＞, ~RFC1945, May 1996
[HTTP/1.1]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜HTTP/1.1＞, STD 99, ~RFC9112
    URL: https://httpwg.org/specs/rfc9112.html
[HTTP/2]
    Thomson, M., Ed. and C. Benfield, Ed., ＜HTTP/2＞, ~RFC9113, June 2022
    URL: https://httpwg.org/specs/rfc9113.html
[HTTP/3]
    Bishop, M., Ed., ＜HTTP/3＞, ~RFC9114, June 2022.
    URL: https://httpwg.org/specs/rfc9114.html
[ISO-8859-1]
    International Organization for Standardization, ＜Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1＞, ISO/IEC 8859-1:1998, 1998. 
[Kri2001]
    Kristol, D., ＜HTTP Cookies: Standards, Privacy, and Politics＞, ACM Transactions on Internet Technology 1(2), November 2001, URL: http://arxiv.org/abs/cs.SE/0105018
[OWASP]
    ＜The Open Web Application Security Project＞, URL: https://www.owasp.org/
[REST]
    Fielding, R., ＜Architectural Styles and the Design of Network-based Software Architectures＞, Doctoral Dissertation, University of California, Irvine, September 2000, URL: https://roy.gbiv.com/pubs/dissertation/top.htm
[RFC1919]
    Chatel, M., ＜Classical versus Transparent IP Proxies＞, ~RFC1919, March 1996
[RFC2047]
    Moore, K., ＜MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text＞, ~RFC2047, November 1996
[RFC2068]
    Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, ＜Hypertext Transfer Protocol -- HTTP/1.1＞, ~RFC2068, January 1997
[RFC2145]
    Mogul, J., Fielding, R., Gettys, J., and H. Frystyk, ＜Use and Interpretation of HTTP Version Numbers＞, ~RFC2145, May 1997
[RFC2295]
    Holtman, K. and A. Mutz, ＜Transparent Content Negotiation in HTTP＞, ~RFC2295, March 1998
[RFC2324]
    Masinter, L., ＜Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)＞, ~RFC2324, April 1998
[RFC2557]
    Palme, J., Hopmann, A., and N. Shelness, ＜MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)＞, ~RFC2557, March 1999
[RFC2616]
    Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, ＜Hypertext Transfer Protocol -- HTTP/1.1＞, ~RFC2616, June 1999
[RFC2617]
    Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, ＜HTTP Authentication: Basic and Digest Access Authentication＞, ~RFC2617, June 1999
[RFC2774]
    Nielsen, H., Leach, P., and S. Lawrence, ＜An HTTP Extension Framework＞, ~RFC2774, February 2000
[RFC2818]
    Rescorla, E., ＜HTTP Over TLS＞, ~RFC2818, May 2000
[RFC2978]
    Freed, N. and J. Postel, ＜IANA Charset Registration Procedures＞, BCP 19, ~RFC2978, October 2000
[RFC3040]
    Cooper, I., Melve, I., and G. Tomlinson, ＜Internet Web Replication and Caching Taxonomy＞, ~RFC3040, January 2001
[RFC3864]
    Klyne, G., Nottingham, M., and J. Mogul, ＜Registration Procedures for Message Header Fields＞, BCP 90, ~RFC3864, September 2004
[RFC3875]
    Robinson, D. and K. Coar, ＜The Common Gateway Interface (CGI) Version 1.1＞, ~RFC3875, October 2004
[RFC4033]
    Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, ＜DNS Security Introduction and Requirements＞, ~RFC4033, March 2005
[RFC4559]
    Jaganathan, K., Zhu, L., and J. Brezak, ＜SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows＞, ~RFC4559, June 2006
[RFC5789]
    Dusseault, L. and J. Snell, ＜PATCH Method for HTTP＞, ~RFC5789, March 2010
[RFC5905]
    Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, ＜Network Time Protocol Version 4: Protocol and Algorithms Specification＞, ~RFC5905, June 2010
[RFC6454]
    Barth, A., ＜The Web Origin Concept＞, ~RFC6454, December 2011
[RFC6585]
    Nottingham, M. and R. Fielding, ＜Additional HTTP Status Codes＞, ~RFC6585, April 2012
[RFC7230]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing＞, ~RFC7230, June 2014
[RFC7231]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content＞, ~RFC7231, June 2014
[RFC7232]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests＞, ~RFC7232, June 2014
[RFC7233]
    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Range Requests＞, ~RFC7233, June 2014
[RFC7234]
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Caching＞, ~RFC7234, June 2014
[RFC7235]
    Fielding, R., Ed. and J. Reschke, Ed., ＜Hypertext Transfer Protocol (HTTP/1.1): Authentication＞, ~RFC7235, June 2014
[RFC7538]
    Reschke, J., ＜The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)＞, ~RFC7538, April 2015
[RFC7540]
    Belshe, M., Peon, R., and M. Thomson, Ed., ＜Hypertext Transfer Protocol Version 2 (HTTP/2)＞, ~RFC7540
[RFC7578]
    Masinter, L., ＜Returning Values from Forms: multipart/form-data＞, ~RFC7578, July 2015
[RFC7615]
    Reschke, J., ＜HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields＞, ~RFC7615, September 2015
[RFC7616]
    Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, ＜HTTP Digest Access Authentication＞, ~RFC7616, September 2015
[RFC7617]
    Reschke, J., ＜The 'Basic' HTTP Authentication Scheme＞, ~RFC7617, September 2015
[RFC7694]
    Reschke, J., ＜Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding＞, ~RFC7694,November 2015
[RFC8126]
    Cotton, M., Leiba, B., and T. Narten, ＜Guidelines for Writing an IANA Considerations Section in RFCs＞, BCP 26, ~RFC8126, June 2017
[RFC8187]
    Reschke, J., ＜Indicating Character Encoding and Language for HTTP Header Field Parameters＞, ~RFC8187, September 2017
[RFC8246]
    McManus, P., ＜HTTP Immutable Responses＞, ~RFC8246, September 2017
[RFC8288]
    Nottingham, M., ＜Web Linking＞, ~RFC8288, October 2017
[RFC8336]
    Nottingham, M. and E. Nygren, ＜The ORIGIN HTTP/2 Frame＞, ~RFC8336, March 2018
[RFC8615]
    Nottingham, M., ＜Well-Known Uniform Resource Identifiers (URIs)＞, ~RFC8615, May 2019
[RFC8941]
    Nottingham, M. and P-H. Kamp, ＜Structured Field Values for HTTP＞, ~RFC8941, February 2021
[Sniffing]
    WHATWG, ＜MIME Sniffing＞, URL: https://mimesniff.spec.whatwg.org
[WEBDAV]
    Dusseault, L., Ed., ＜HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)＞, ~RFC4918, June 2007

●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により Internet Standard として公表された，
<a href="~SPEC_URL">HTTP Semantics</a> （RFC 9110）
を日本語に翻訳したものです（ §7 〜 §15 は別ページ）。
~PUB
</p>

●●spec_metadata
公表者
	Internet Engineering Task Force (IETF)
RFC
	9110
廃用
	<a href="#RFC7230">7230</a>, <a href="#RFC7231">7231</a>, <a href="#RFC7232">7232</a>, <a href="#RFC7233">7233</a>, <a href="#RFC7235">7235</a>, <a href="#RFC7538">7538</a>, <a href="#RFC7615">7615</a>, <a href="#RFC7694">7694</a>
更新
	<a href="#RFC3864">3864</a>
分類
	Standards Track
日付
	2022 年 6 月
編集
	R. Fielding, Editor (Adobe)
	M. Nottingham, Editor (Fastly)
	J. Reschke, Editor (greenbytes)
履歴
	https://datatracker.ietf.org/doc/rfc9110/
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc9110
	（この訳には 2023-09-08 時点までの正誤表の内容（ Rejected 以外）も含めている）
</script>

</head>
<body>

<header>
	<hgroup>
<h1>HTTP 意味論（共通基盤）</h1>
<p>RFC 9110 — HTTP Semantics</p>
	</hgroup>
</header>

<div id="MAIN" hidden>

<p class="trans-note">【
この~pageでは、
~HTTP意味論を成す内容のうち，
`7 〜 15＠~HTTPsem§
以外を成す部分
（概ね、個別の［
~field／~method／状態s~code
］には関わらない部分）
を述べる。
】</p>

	<section id="rfc.abstract">
◎要約

<div class="p">
<p>
~HTTP（ `Hypertext Transfer Protocol^en ）は、
分散型の協調的な~hypertext情報~system用の，`~stateless$な応用~levelの~protocolである。
この文書は、
この~protocolの：
</p>
<ul>
	<li>
全般的な~architectureについて述べる。
</li>
	<li>
共通な各種用語を確立する。
</li>
	<li>
次に挙げるものを~~含む，~HTTPのすべての~versionから共有される側面を定義する
⇒＃
中核を成す~protocol要素,
拡張能の仕組み,
"`http$c" および "`https$c" ~URI~scheme,
</li>
</ul>
◎
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document describes the overall architecture of HTTP, establishes common terminology, and defines aspects of the protocol that are shared by all versions. In this definition are core protocol elements, extensibility mechanisms, and the "http" and "https" Uniform Resource Identifier (URI) schemes.
</div>

<p>
この文書は、
`RFC3864$r を更新し，次を廃用にする
⇒＃
`RFC2818$r,
`RFC7231$r,
`RFC7232$r,
`RFC7233$r,
`RFC7235$r,
`RFC7538$r,
`RFC7615$r,
`RFC7694$r,
`RFC7230$r を成すいくつかの部位
◎
This document updates RFC 3864 and obsoletes RFCs 2818, 7231, 7232, 7233, 7235, 7538, 7615, 7694, and portions of 7230.
</p>

	</section>
	<section id="rfc.status">
<h2 title="Status of This Memo">このメモの位置付け</h2>

<p class="trans-note">【
この節の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#status$に移譲。
】</p>

	</section>
	<section id="rfc.copyrightnotice">
<h2 title="Copyright Notice">著作権の告知</h2>

<p lang="en">
Copyright (c) 2022 IETF Trust and the persons identified as the document authors. All rights reserved.
</p>

<p class="trans-note">【
以下、
この節の他の内容は
`~IETF日本語訳 共通~page＠~IETFcommon#copyright-notice$に移譲。
】</p>

	</section>

<main id="MAIN0">
	<section id="introduction">
<h2 title="Introduction">1. 序論</h2>

		<section id="purpose">
<h3 title="Purpose">1.1. 目的</h3>

<p>
~HTTP（ `Hypertext Transfer Protocol^en ）は、
`~stateless$な応用~levelの［
要請／応答
］~protocolたちが成す族である
— それらは、［
~networkに基づく，~hypertext情報~system
］と柔軟にヤリトリするために［
汎用な~interface,
拡張-可能な意味論,
`自己-記述的$な~message
］を共有する。
◎
The Hypertext Transfer Protocol (HTTP) is a family of stateless, application-level, request/response protocols that share a generic interface, extensible semantics, and self-descriptive messages to enable flexible interaction with network-based hypertext information systems.
</p>

<p>
~HTTPは、
`~client$向けに［
供される`資源$の型に依存しない，統一的な~interface
］を呈示することにより，~serviceがどう実装されるかについての詳細を隠す。
同様に、
`~server$も，各~clientの目的について自覚する必要はない
— 要請は、［
特定の型の~client／予め決定された手続きを適用すること
］に結付けられずに，他から隔離して考慮できる。
このことは、
次を許容する
⇒＃
多くの異なる文脈で一般用~実装を効果的に利用する／
相互作用による複階性を抑制する／
時と伴に独立な発展を可能化する
◎
HTTP hides the details of how a service is implemented by presenting a uniform interface to clients that is independent of the types of resources provided. Likewise, servers do not need to be aware of each client's purpose: a request can be considered in isolation rather than being associated with a specific type of client or a predetermined sequence of application steps. This allows＼
general-purpose implementations to be used effectively in many different contexts,＼
reduces interaction complexity,＼
and enables independent evolution over time.
</p>

<p>
~HTTPはまた、
中間~protocolとしての利用-用にも設計されている
— `~proxy$や`~gateway$が，非~HTTP情報~systemを より汎用な~interfaceの中へ翻訳できるような。
◎
HTTP is also designed for use as an intermediation protocol, wherein proxies and gateways can translate non-HTTP information systems into a more generic interface.
</p>

<div class="p">
<p>
この柔軟性による帰結の一つは、
~interfaceの背後で生じるものからは，~protocolを定義し得ないことである。
代わりに，次を定義することに制限される
⇒＃
通信の構文／
受信された通信の意図／
`受信者$に期待される挙動
◎
One consequence of this flexibility is that the protocol cannot be defined in terms of what occurs behind the interface. Instead, we are limited to defining＼
the syntax of communication,＼
the intent of received communication, and＼
the expected behavior of recipients.＼
</p>

<p>
各~通信を他から隔離して考慮するならば、
成功裡に終わる動作に対応する変化は，
`~server$が供する観測-可能な~interfaceを通して反映される~OUGHT。
しかしながら、［
複数の~clientが，並列的に かつ~~大体は違う目的で動作する
］であろうから，［
そのような変化が，単独の応答の視野を超えて観測-可能になる
］ことは要求できない。
◎
If the communication is considered in isolation, then successful actions ought to be reflected in corresponding changes to the observable interface provided by servers. However, since multiple clients might act in parallel and perhaps at cross-purposes, we cannot require that such changes be observable beyond the scope of a single response.
</p>
</div>

		</section>
		<section id="history.and.evolution">
<h3 title="History and Evolution">1.2. 歴史と発展</h3>

<p>
~HTTPは、
1990 年の導入~以来， World Wide Web 用の首な情報~転送~protocolであり続けている。
それは、［
所与の~pathnameで識別され，予め~hypertext文書と見做される資源
］の転送を要請するために，
単独の~method（ `GET$m ）を伴う低-待時間な要請~用の些細な仕組みとして始まった。
~Webが成長する伴い、
~HTTPは次を行えるよう拡張され，
最終的には~HTTP09, ~HTTP10として定義された
（ `HTTP/1.0$r を見よ）
⇒＃
~messageの中に要請や応答を封入する／
~MIMEの様な~media型【`~MIME型$】を利用して，任意な~data形式を転送する／
`媒介者$を通して要請を~routeする
◎
HTTP has been the primary information transfer protocol for the World Wide Web since its introduction in 1990. It began as a trivial mechanism for low-latency requests, with a single method (GET) to request transfer of a presumed hypertext document identified by a given pathname. As the Web grew, HTTP was extended to＼
enclose requests and responses within messages,＼
transfer arbitrary data formats using MIME-like media types,＼
and route requests through intermediaries.＼
These protocols were eventually defined as HTTP/0.9 and HTTP/1.0 (see [HTTP/1.0]).
</p>

<p>
~HTTP11は、
既存の［
~textに基づく~message法~構文
］との互換性は維持しながら，~protocolの各種~特能を精緻化して、
~Internetにまたがる その［
相互運用能, ~scale能, 堅牢性
］を改善するべく設計された。
これには、
次に挙げるものが含められた：
◎
HTTP/1.1 was designed to refine the protocol's features while retaining compatibility with the existing text-based messaging syntax, improving its interoperability, scalability, and robustness across the Internet. This included＼
</p>
<ul>
	<li>
［
固定的な／（~chunkedによる）動的な
］`内容$用の長さに基づく~data区切子
◎
length-based data delimiters for both fixed and dynamic (chunked) content,＼
</li>
	<li>
`内容~折衝$用の一貫した~framework
◎
a consistent framework for content negotiation,＼
</li>
	<li>
`条件付き要請$~用の不透明な`検証子$
◎
opaque validators for conditional requests,＼
</li>
	<li>
~cacheの一貫性をより良くするための~cache制御
◎
cache controls for better cache consistency,＼
</li>
	<li>
部分的な更新~用の`範囲~要請$
◎
range requests for partial updates,＼
</li>
	<li>
既定の持続的な接続
◎
and default persistent connections.＼
</li>
</ul>

<p>
~HTTP11は、
1995 年に導入された
— それは
⇒＃
1997 年には `Standards Track^en にて `RFC2068$r として公表され,
1999 年には `RFC2616$r に改訂され,
2014 年には `RFC7230$r 〜 `RFC7235$r に再び改訂された
◎
HTTP/1.1 was introduced in 1995 and published on the Standards Track in 1997 [RFC2068], revised in 1999 [RFC2616], and revised again in 2014 ([RFC7230] through [RFC7235]).
</p>

<p>
~HTTP2（ `HTTP/2$r ）は、
複数の~HTTP~messageを同時並行に交換するため，既存の［
~TLS, ~TCP
］~protocolの上層に多重化された~session層を導入した
— 効率的な~field圧縮と~server~pushも伴って。
~HTTP3（ `HTTP/3$r ）は、
~QUICを［
~TCP越しに代えて，~UDP越しの~secureな多重化された~transport
］として利用することにより，同時並行な~message用に より高い独立性を供する。
◎
HTTP/2 ([HTTP/2]) introduced a multiplexed session layer on top of the existing TLS and TCP protocols for exchanging concurrent HTTP messages with efficient field compression and server push. HTTP/3 ([HTTP/3]) provides greater independence for concurrent messages by using QUIC as a secure multiplexed transport over UDP instead of TCP.
</p>

<p>
これら~HTTPの 3 つの`~major~version$は、
この文書に定義される意味論に依拠する。
それらは、
互いに他を廃用にすることはない
— それぞれには、
利用される文脈に依存して，特有な便益や制限があるので。
実装には、
自身の特定0の文脈~用に最も適切な［
~transport, ~message法~構文
］を選ぶことが期待される。
◎
All three major versions of HTTP rely on the semantics defined by this document. They have not obsoleted each other because each one has specific benefits and limitations depending on the context of use. Implementations are expected to choose the most appropriate transport and messaging syntax for their particular context.
</p>

<p>
~HTTPのこの改訂は、
現在の~HTTP11の~message法~構文（ `HTTP/1.1$r ）から［
意味論の定義（この文書）と~cache法（ `CACHING$r ）
］を分離して，~majorな各~protocol~versionが［
同じ中核~意味論を参照rしながら，独立に進展する
］ことを許容する。
◎
This revision of HTTP separates the definition of semantics (this document) and caching ([CACHING]) from the current HTTP/1.1 messaging syntax ([HTTP/1.1]) to allow each major protocol version to progress independently while referring to the same core semantics.
</p>

		</section>
		<section id="core.semantics">
<h3 title="Core Semantics">1.3. 中核~意味論</h3>

<p>
~HTTPは、
`資源$とヤリトリするための統一的な~interfaceを
— 資源の［
型, 資質, 実装
］を問わず —
当の資源の`表現$を［
操作する／転送する
］~messageを送信することにより供する。
◎
HTTP provides a uniform interface for interacting with a resource (Section 3.1) -- regardless of its type, nature, or implementation -- by sending messages that manipulate or transfer representations (Section 3.2).
</p>

<div class="p">
<p>
各~messageは、
要請, 応答のどちらかになる：
◎
Each message is either a request or a response.＼
</p>
<ol>
	<li>
`~client$は、
自身の意図nを通信する`要請~message$を構築して，
識別された`生成元~server$へ向けて~messageを~routeする。
◎
A client constructs request messages that communicate its intentions and routes those messages toward an identified origin server.＼
</li>
	<li>
`~server$は、
要請を~listenして，
受信した各~messageを構文解析して，
識別された`~target資源$に関係する~message意味論を解釈して，
その要請に対し 1 個~以上の`応答~message$で応答する。
◎
A server listens for requests, parses each message received, interprets the message semantics in relation to the identified target resource, and responds to that request with one or more response messages.＼
</li>
	<li>
`~client$は、
自身の意図nが遂げられたどうか見るために受信した応答を精査して，
受信した［
`状態s~code$, `内容$
］に基づいて 次に何を行うか決定する。
◎
The client examines received responses to see if its intentions were carried out, determining what to do next based on the status codes and content received.
</li>
</ol>
</div>

<div class="p">
<p>
~HTTP意味論は、
次を含む：
◎
HTTP semantics include＼
</p>
<ul>
	<li>
各種 `要請~method$が定義する意図n
◎
the intentions defined by each request method (Section 9),＼
</li>
	<li>
各種 要請~headerにて述べ得るような，それら【要請~method】の意味論に対する拡張
◎
extensions to those semantics that might be described in request header fields,＼
</li>
	<li>
応答について述べる各種 `状態s~code$
◎
status codes that describe the response (Section 15),＼
</li>
	<li>
各種 応答~fieldにて与え得る，他の［
制御~data／資源~metadata
］
◎
and other control data and resource metadata that might be given in response fields.
</li>
</ul>
</div>

<div class="p">
<p>
意味論は、
次も含む：
◎
Semantics also include＼
</p>
<ul>
	<li>
次について述べる，`表現~metadata$
⇒
`内容$は、
受信者からは，どう解釈されるものと意図されているか
◎
representation metadata that describe how content is intended to be interpreted by a recipient,＼
</li>
	<li>
`内容$の選定に波及し得る，要請~header
◎
request header fields that might influence content selection,＼
</li>
	<li>
<dfn>`内容~折衝$</dfn>
と~~総称される，様々な選定~algo
◎
and the various selection algorithms that are collectively referred to as "content negotiation" (Section 12).
</li>
</ul>
</div>

		</section>
		<section id="specifications.obsoleted.by.this.document">
<h3 title="Specifications Obsoleted by This Document">1.4. この文書により廃用にされる仕様</h3>

<p>
この文書により廃用にされる仕様は
（括弧内に挙げる変更点も見よ）
⇒＃
`HTTP Over TLS^cite `RFC2818$r（ `B.1§ ）,
`HTTP/1.1 Message Syntax and Routing^cite `RFC7230$r（ `B.2§ ）†,
`HTTP/1.1 Semantics and Content^cite `RFC7231$r（ `B.3§ ）,
`HTTP/1.1 Conditional Requests^cite `RFC7232$r（ `B.4§ ）,
`HTTP/1.1 Range Requests^cite `RFC7233$r（ `B.5§ ）,
`HTTP/1.1 Authentication^cite `RFC7235$r（ `B.6§ ）,
`HTTP Status Code 308 (Permanent Redirect)^cite `RFC7538$r（ `B.7§ ）,
`HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields^cite `RFC7615$r（ `B.8§ ）,
`HTTP Client-Initiated Content-Encoding^cite `RFC7694$r（ `B.9§ ）,
◎
Table 1
Title 	Reference 	See

HTTP Over TLS｜[RFC2818]｜B.1
HTTP/1.1 Message Syntax and Routing [*]｜[RFC7230]｜B.2
HTTP/1.1 Semantics and Content｜[RFC7231]｜B.3
HTTP/1.1 Conditional Requests｜[RFC7232]｜B.4
HTTP/1.1 Range Requests｜[RFC7233]｜B.5
HTTP/1.1 Authentication｜[RFC7235]｜B.6
HTTP Status Code 308 (Permanent Redirect)｜[RFC7538]｜B.7
HTTP Authentication-Info and Proxy-Authentication-Info Response Header Fields｜[RFC7615]｜B.8
HTTP Client-Initiated Content-Encoding｜[RFC7694]｜B.9
</p>

<p>†
この文書が廃用にするのは、
`RFC7230$r を成す，~HTTP11の［
~message法~構文／接続~管理
］に依存しない部位に限られる。
`RFC7230$r を成す他の部分は、
`HTTP/1.1$r により廃用にされた。
◎
[*] This document only obsoletes the portions of RFC 7230 that are independent of the HTTP/1.1 messaging syntax and connection management; the remaining bits of RFC 7230 are obsoleted by "HTTP/1.1" [HTTP/1.1].
</p>

		</section>
	</section>
	<section id="conformance">
<h2 title="Conformance">2. 適合性</h2>

		<section id="notation">
<h3 title="Syntax Notation">2.1. 構文の表記法</h3>

<p class="trans-note">【
この節の他の内容は、
`~HTTP日本語訳 共通~page＠~HTTPcommon#syntax-notation$
に移譲。
】</p>

<p>
`A§ にて、
すべての~list演算子を標準な~ABNF表記法に展開した，総集的な文法を示す。
◎
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234], extended with the notation for case-sensitivity in strings defined in [RFC7405].
◎
It also uses a list extension, defined in Section 5.6.1, that allows for compact definition of comma-separated lists using a "#" operator (similar to how the "*" operator indicates repetition). Appendix A shows the collected grammar with all list operators expanded to standard ABNF notation.
◎
As a convention, ABNF rule names prefixed with "obs-" denote obsolete grammar rules that appear for historical reasons.
◎
The following core rules are included by reference, as defined in Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote), HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed), OCTET (any 8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII character).
</p>

<p>
`5.6§ にて、
`~field値$用の汎用な構文-成分をいくつか定義する。
◎
Section 5.6 defines some generic syntactic components for field values.
◎
This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].
</p>

		</section>
		<section id="requirements.notation">
<h3 title="Requirements Notation">2.2. 要件の表記法</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
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.
</p>

<p>
この仕様は、
~HTTP通信における参加者の
`役割@
（ `role^en ）
に則って，適合性の判定基準を~~適用する。
よって，要件は、
それにより拘束される挙動に依存して，次に挙げる`役割$に設置される
⇒＃
`送信者$,
`受信者$,
`~client$,
`~server$,
`~UA$,
`媒介者$,
`生成元~server$,
`~proxy$,
`~gateway$,
`~cache$
◎
This specification targets conformance criteria according to the role of a participant in HTTP communication. Hence, requirements are placed on senders, recipients, clients, servers, user agents, intermediaries, origin servers, proxies, gateways, or caches, depending on what behavior is being constrained by the requirement.＼
</p>

<p>
また，［
単独の通信の視野を超えて適用される
］ときには、
追加的な要件が，［
実装／資源~所有者／~protocol要素~登録
］に設置されることもある。
◎
Additional requirements are placed on implementations, resource owners, and protocol element registrations when they apply beyond the scope of a single communication.
</p>

<p>
要件のうち，~protocol要素に対し動詞
“`生成-@（する, された, 等々）”
を（ “送信-…” に代えて）利用しているものは、
当の要素を作成した実装に限り，適用される
— 受信したそれを`下流$へ回送する実装には~~課されない。
◎
The verb "generate" is used instead of "send" where a requirement applies only to implementations that create the protocol element, rather than an implementation that forwards a received element downstream.
</p>

<p>
実装は、［
~HTTPにおいて自身が受け持つ各`役割$に結付けられた，すべての要件
］に準拠するならば，
適合すると見なされる。
◎
An implementation is considered conformant if it complies with all of the requirements associated with the roles it partakes in HTTP.
</p>

<p>
`送信者$は、［
対応する~ABNF規則により定義される文法に合致しない~protocol要素
］を`生成-$してはナラナイ。
`送信者$は、
~messageの中に［
他の`役割$（すなわち，当の~messageに対し送信者が受け持たない`役割$）を受け持つ参加者にしか`生成-$することが許容されていない［
~protocol要素／構文~代替
］］を`生成-$してはナラナイ。
◎
A sender MUST NOT generate protocol elements that do not match the grammar defined by the corresponding ABNF rules.＼
Within a given message, a sender MUST NOT generate protocol elements or syntax alternatives that are only allowed to be generated by participants in other roles (i.e., a role that the sender does not have for that message).
</p>

<p>
~HTTPへの適合性は、［
利用-中にある`~protocol~version$の特定0の~message法~構文への適合性
］, ［
送信される~protocol要素の意味論への適合性
］どちらも含む。
例えば，~HTTP11への適合性を主張する`~client$は、［
~HTTP11受信者に要求される特能を認識する
］ことに失敗した場合，［
そのような主張に則って自身の応答を調整する`~server$と相互運用する
］ことに失敗することになる。
利用者の選択を反映する特能
— `内容~折衝$や利用者が選定した拡張など —
は、［
~protocol~streamを超える，応用の挙動
］に影響iし得る。
利用者の選択を正確aに反映しない~protocol要素を送信すると、［
利用者を惑わす／選択を妨げる
］ことになる。
◎
Conformance to HTTP includes both conformance to the particular messaging syntax of the protocol version in use and conformance to the semantics of protocol elements sent. For example, a client that claims conformance to HTTP/1.1 but fails to recognize the features required of HTTP/1.1 recipients will fail to interoperate with servers that adjust their responses in accordance with those claims. Features that reflect user choices, such as content negotiation and user-selected extensions, can impact application behavior beyond the protocol stream; sending protocol elements that inaccurately reflect a user's choices will confuse the user and inhibit choice.
</p>

<p>
ある実装が意味論上の適合性に失敗するとき、
その実装の~messageの受信者たちは，ゆくゆくは［
それに則って，自身の挙動を調整するような対処法
］を開発することになる。
`受信者$は、
そのような対処法を
— 該当する実装に制限する, かつ この~protocolの他の適合性に反しない限り —
使役してもヨイ。
例えば，［
`~server$／`~UA$
］は、［
既知な~bugや拙く選ばれた既定に関して，自前の挙動を調整する
］ために［
`User-Agent$h ／ `Server$h
］`~field値$の~~各部を走査することが多い。
◎
When an implementation fails semantic conformance, recipients of that implementation's messages will eventually develop workarounds to adjust their behavior accordingly. A recipient MAY employ such workarounds while remaining conformant to this protocol if the workarounds are limited to the implementations at fault. For example, servers often scan portions of the User-Agent field value, and user agents often scan the Server field value, to adjust their own behavior with respect to known bugs or poorly chosen defaults.
</p>

		</section>
		<section id="length.requirements">
<h3 title="Length Requirements">2.3. 長さ要件</h3>

<p>
`受信者$は、
受信した~protocol要素を防御的に
— すなわち，当の要素が［
~ABNF文法に適合する, かつ
適度な~buffer~sizeの中に収まる
］こと以外は期待しない下で —
構文解析するベキである。
◎
A recipient SHOULD parse a received protocol element defensively, with only marginal expectations that the element will conform to its ABNF grammar and fit within a reasonable buffer size.
</p>

<p>
~HTTPにおける多くの~protocol要素は，特定の長さ制限を設けていない
— 何故なら，［
適切になるであろう長さ
］は、
実装の［
配備~文脈や目的
］に依存して，~~多岐に~~渡るので。
よって，［
`送信者$と`受信者$との間の相互運用能
］は、［
各種~protocol要素に見合う長さに関して，共有されている期待
］に依存する。
更には，一部の~protocol要素に対しては、［
何が，それに見合う長さになるものと共通して理解されているか
］は，過去 30 年にわたる~HTTPの利用を経る中で変化しており、
将来にも変化し続けるものと予期されている。
◎
HTTP does not have specific length limitations for many of its protocol elements because the lengths that might be appropriate will vary widely, depending on the deployment context and purpose of the implementation. Hence, interoperability between senders and recipients depends on shared expectations regarding what is a reasonable length for each protocol element. Furthermore, what is commonly understood to be a reasonable length for some protocol elements has changed over the course of the past three decades of HTTP use and is expected to continue changing in the future.
</p>

<p>
`受信者$は、
最小でも［［
他の~message内の同じ~protocol要素
］に対し，自身が`生成-$し得る値の長さ
］以上の長さの~protocol要素を，構文解析して処理できなければナラナイ。
例えば，`生成元~server$は、［
自前の`資源$に対し，~~長大な`~URI参照$を公表する
］ならば，［
`~target~URI$として受信した，同じ参照
］を構文解析して処理できる必要がある。
◎
At a minimum, a recipient MUST be able to parse and process protocol element lengths that are at least as long as the values that it generates for those same protocol elements in other messages. For example, an origin server that publishes very long URI references to its own resources needs to be able to parse and process those same references when received as a target URI.
</p>

<p>
受信される多くの~protocol要素は、
それを識別して`下流$へ回送するために必要yな所までに限り，構文解析される。
例えば，`媒介者$は、
受信した各`~field$を［
`~field名$, `~field値$
］成分までは構文解析しつつ，`~field値$の内側までは構文解析することなく回送することもある。
◎
Many received protocol elements are only parsed to the extent necessary to identify and forward that element downstream. For example, an intermediary might parse a received field into its field name and field value components, but then forward the field without further parsing inside the field value.
</p>

		</section>
		<section id="error.handling">
<h3 title="Error Handling">2.4. ~errorの取扱い</h3>

<p>
`受信者$は、
受信した~protocol要素を［
この仕様がそれ用に定義する意味論
］に則って解釈しなければナラナイ
— この仕様に対する拡張【による~protocol要素】も含めて。
ただし、
受信者が［
送信者が，それらの意味論に含意されるものを不正に実装している
］ものと（経験または環境設定を通して）決定できたときは除く。
例えば，`生成元~server$は、［
`User-Agent$h ~headerの検分
］により［［
ある種の`内容~符号法$の受領に際し失敗する
］と既知である，特定の実装~version
］が指示されたときには，［
受信した `Accept-Encoding$h ~headerの内容
］を無視rするかもしれない。
◎
A recipient MUST interpret a received protocol element according to the semantics defined for it by this specification, including extensions to this specification, unless the recipient has determined (through experience or configuration) that the sender incorrectly implements what is implied by those semantics. For example, an origin server might disregard the contents of a received Accept-Encoding header field if inspection of the User-Agent header field indicates a specific implementation version that is known to fail on receipt of certain content codings.
</p>

<p>
他が注記されない限り，`受信者$は、［
妥当でない構成子から，利用-可能な~protocol要素を回復する
］よう試みてもヨイ。
~HTTPは、［
~securityに対し直な影響iがあるとき
］を除いて，［
~errorを取扱う特定の仕組み
］を定義しない
— ~errorを取扱うにあたって要求される策は、
~protocolの応用ごとに異なり得るので。
例えば、
~Web~browserは［
応答の `Location$h ~headerを~ABNFに則って構文解析できないときには，
透過的な回復を望む
］かもしれないが，
~system制御~clientは［
いかなる形の~error回復も，危険と見なす
］かもしれない。
◎
Unless noted otherwise, a recipient MAY attempt to recover a usable protocol element from an invalid construct. HTTP does not define specific error handling mechanisms except when they have a direct impact on security, since different applications of the protocol require different error handling strategies. For example, a Web browser might wish to transparently recover from a response where the Location header field doesn't parse according to the ABNF, whereas a systems control client might consider any form of error recovery to be dangerous.
</p>

<p>
一部の要請は、
下層の接続が失敗した所で，~clientにより自動的に再試行され得る
— `冪等~method§にて述べられるとおり。
◎
Some requests can be automatically retried by a client in the event of an underlying connection failure, as described in Section 9.2.2.
</p>

		</section>
		<section id="protocol.version">
<h3 title="Protocol Version">2.5. ~protocol~version</h3>

<div class="p">
<p>
~HTTPの
`~version番号^dfn
は、［
"." （~period／小数点）で分離される 2 個の~decimal桁（ `DIGIT$P ）
］からなる：
◎
HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).＼
</p>
<ul>
	<li>
1 個目の桁は、
`~major~version@
（ `major version^en ）と称され，
~message法~構文を指示する。
◎
The first digit (major version) indicates the messaging syntax,＼
</li>
	<li>
2 個目の桁は、
`~minor~version@
（ `minor version^en ）と称され，
次を満たす最も高い~minor~versionを指示する
⇒
1 個目の桁による`~major~version$の下で，
`送信者$が適合する（かつ，未来の通信においても解せる）
◎
whereas the second digit (minor version) indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication).
</li>
</ul>
</div>

<p>
~HTTPの中核を成す意味論は，［
~protocol~version間で変化しないが，
それらが “伝送路~上” でどう表出されるかは変化し得る
］ので、
伝送路~形式に対し互換でない変更が為されたときには，~HTTP~version番号は変化する。
加えて，~HTTPは、
定義-済みな拡張~地点（ `16§ ）の利用を通して，
~protocolに対し［
~versionを変更することなく，増分的に後方-互換な変更を為す
］ことを許容する。
◎
While HTTP's core semantics don't change between protocol versions, their expression "on the wire" can change, and so the HTTP version number changes when incompatible changes are made to the wire format. Additionally, HTTP allows incremental, backwards-compatible changes to be made to the protocol without changing its version through the use of defined extension points (Section 16).
</p>

<p>
~protocol~versionは、
それ一体【`~major~version$, `~minor~version$が成す組み】として，［［
その~versionに対応する各~仕様
］にて挙げられた要件たちが成す集合に，`送信者$が適合している
］ことを指示する。
例えば，~version "`HTTP/1.1^c" は、［
この文書, `CACHING$r, `HTTP/1.1$r
］を組合せた仕様により定義される。
◎
The protocol version as a whole indicates the sender's conformance with the set of requirements laid out in that version's corresponding specification(s). For example, the version "HTTP/1.1" is defined by the combined specifications of this document, "HTTP Caching" [CACHING], and "HTTP/1.1" [HTTP/1.1].
</p>

<p>
`~major~version$番号は、［
互換でない~message構文が導入される場合
］に増やされる。
`~minor~version$番号は、［
~protocolに為された変更により［
~message意味論が追加される／`送信者$に追加的な能力が含意される
］場合
］に増やされる。
◎
HTTP's major version number is incremented when an incompatible message syntax is introduced. The minor number is incremented when changes made to the protocol have the effect of adding to the message semantics or implying additional capabilities of the sender.
</p>

<p>
`~minor~version$は、
`送信者$が まだ［
当の~protocolを成す後方-互換な下位集合
］しか利用していないときでも，送信者の通信~能力を広告する
— それにより、［［
（`~server$による）応答／（`~client$による）未来の要請
］において，より高度な特能も利用できる
］ことを受信者に知らせる。
◎
The minor version advertises the sender's communication capabilities even when the sender is only using a backwards-compatible subset of the protocol, thereby letting the recipient know that more advanced features can be used in response (by servers) or in future requests (by clients).
</p>

<p>
~HTTPの`~major~version$が`~minor~version$を定義しない場合、
その暗黙な`~minor~version$は， "`0^c" とする。
"`0^c" は、［
~minor~version識別子が要求される~protocol要素
］の中で，そのような~protocolを参照rするために利用される。
◎
When a major version of HTTP does not define any minor versions, the minor version "0" is implied. The "0" is used when referring to that protocol within elements that require a minor version identifier.
</p>

		</section>
	</section>
	<section id="terminology">
<h2 title="Terminology and Core Concepts">3. 各種用語と中核~概念</h2>
<p>
~HTTPは、
World Wide Web（ WWW ）~architecture用に作成され，［
~worldwide~hypertext~systemにおける~scale能の必要性
］を~supportするために，時と伴に発展してきた。
その~architectureの多くは、
~HTTPを定義するために利用される各種用語に反映されている。
◎
HTTP was created for the World Wide Web (WWW) architecture and has evolved over time to support the scalability needs of a worldwide hypertext system. Much of that architecture is reflected in the terminology used to define HTTP.
</p>

		<section id="resources">
<h3 title="Resources">3.1. 資源</h3>

<p>
~HTTP要請の~targetは、
`資源@
（ `resource^en ）と呼ばれる。
~HTTPは、
資源の資質を制限しない
— 単に，資源とヤリトリするために利用できる~interfaceを定義するに過ぎない。
ほとんどの資源は、
`~URI$により識別される。
◎
The target of an HTTP request is called a "resource". HTTP does not limit the nature of a resource; it merely defines an interface that might be used to interact with resources. Most resources are identified by a Uniform Resource Identifier (URI), as described in Section 4.
</p>

<p>
~HTTPの設計~目標の一つは、
`資源$の識別を要請の意味論から分離することである
— それは、
要請の意味論を［
`要請~method$, および 要請を改変する少数の要請~header
］に~~帰属させることにより，アリになる。
資源は、
要請を その~methodの意味論と整合でない方式で扱うことはできない。
例えば，資源の`~URI$が安全でない意味論を含意していたとしても、
`~client$は，［
当の資源に対し，`安全$な~methodを伴う要請が処理されるときは、
安全でない動作は避けられる
］ものと期待できる（ `9.2.1§ 【の最後の段落】を見よ）
◎
One design goal of HTTP is to separate resource identification from request semantics, which is made possible by vesting the request semantics in the request method (Section 9) and a few request-modifying header fields. A resource cannot treat a request in a manner inconsistent with the semantics of the method of the request. For example, though the URI of a resource might imply semantics that are not safe, a client can expect the resource to avoid actions that are unsafe when processing a request with a safe method (see Section 9.2.1).
</p>

<p>
~HTTPは、［
`~target資源$, 資源~間の関係性
］を指示するために，
~URI標準 `URI$r
に依拠する。
◎
HTTP relies upon the Uniform Resource Identifier (URI) standard [URI] to indicate the target resource (Section 7.1) and relationships between resources.
</p>

		</section>
		<section id="representations">
<h3 title="Representations">3.2. 表現</h3>

<p>
`表現@
（ `representation^en ）とは、［
所与の`資源$の［
過去の／現在の／欲される
］状態を反映する
］よう意図された［
~protocolを介して通信するに~~適した形式
］による情報である。
各`表現$は、
次の 2 つからなる
⇒＃
`表現~metadata$たちが成す集合,
`表現~data$を成す~stream（際限なく続くものにもなり得る）
◎
A "representation" is information that is intended to reflect a past, current, or desired state of a given resource, in a format that can be readily communicated via the protocol. A representation consists of a set of representation metadata and a potentially unbounded stream of representation data (Section 8).
</p>

<p>
~HTTPは、
統一的な~interfaceの背後に “情報を隠す” ことを許容する
— `資源$自体を転送するのではなく，通信を［
当の資源の状態を成す転送-可能な表現
］に関するよう定義することにより。
これは、［
どんなものでも，~URIにより識別される資源になり得る
］ことを許容する
— “富士山における現在の天気” の様な，［
~messageが`生成-$された時点に，その資源を表現する情報
］を供する時間的な関数も含めて。
`REST$r
◎
HTTP allows "information hiding" behind its uniform interface by defining communication with respect to a transferable representation of the resource state, rather than transferring the resource itself. This allows the resource identified by a URI to be anything, including temporal functions like "the current weather in Laguna Beach", while potentially providing information that represents that resource at the time a message is generated [REST].
</p>

<p>
統一的な~interfaceは、
窓のようなものである
— ［
その窓の向こう側で独立に動作する者
］と~messageを通信することを通してのみ，
何かモノを観測して, 動作できるような。
通信において［
現在の状態【すなわち，`応答$】,
欲される状態【すなわち，`要請$】
］を表現する（ “その場を占める” ）ためには、
共有される抽象-化が必要になる。
表現が~hypertextであるならば、
それは，［
資源~状態を成す表現,
未来における受信者とのヤリトリを手引きするような処理命令
］どちらも供し得る。
◎
The uniform interface is similar to a window through which one can observe and act upon a thing only through the communication of messages to an independent actor on the other side. A shared abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. When a representation is hypertext, it can provide both a representation of the resource state and processing instructions that help guide the recipient's future interactions.
</p>

<p>
`~target資源$は、
複数の表現
— それぞれが，当の`資源$の現在の状態を反映するよう意図されたそれら —
を［
伴って供される／`生成-$する能力を有する
］こともある。
それらの表現のうち，所与の要請に最も適用-可能な一つを選定するため、
ある~algoが利用される
— 通例的に，`内容~折衝$に基づくような。
そのように一つに
`選定された表現@
（ `selected representation^en ）が、
次を行うための［
~data, ~metadata
］を供するために利用される：
◎
A target resource might be provided with, or be capable of generating, multiple representations that are each intended to reflect the resource's current state. An algorithm, usually based on content negotiation (Section 12), would be used to select one of those representations as being most applicable to a given request. This "selected representation" provides the data and metadata for＼
</p>
<ul>
	<li>
`条件付き要請$を評価する
◎
evaluating conditional requests (Section 13) and＼
</li>
	<li>
`GET$m に対する［
`200$st ／ `206$st ／ `304$st
］応答の`内容$を構築する
◎
constructing the content for 200 (OK), 206 (Partial Content), and 304 (Not Modified) responses to GET (Section 9.3.1).
</li>
</ul>

		</section>
		<section id="connections">
<h3 title="Connections, Clients, and Servers">3.3. 接続, ~client, ~server</h3>

<p>
~HTTPは、
依拠-可能な［
~transport層または~session層
］の
`接続@
（ `connection^en ）越しに運用される［
`~client$／`~server$
］~protocolである。
◎
HTTP is a client/server protocol that operates over a reliable transport- or session-layer "connection".
</p>

<p>
~HTTP
`~client@
（ `client^en ）とは、
1 個~以上の~HTTP要請を送信する目的で，`~server$への接続を確立する~programである。
◎
An HTTP "client" is a program that establishes a connection to a server for the purpose of sending one or more HTTP requests.＼
</p>

<p>
~HTTP
`~server@
（ `server^en ）とは、
~HTTP要請に対し，その接続を受容し、
`~client$への~serviceとして，~HTTP応答を送信する~programである。
◎
An HTTP "server" is a program that accepts connections in order to service HTTP requests by sending HTTP responses.
</p>

<p>
用語［
`~client$／`~server$
］が指すのは、［
特定0の接続~用に，これらの~programが遂行する`役割$
］に限られる。
同じ~programが、
ある接続~上では~clientになると~~同時に，
他の接続~上では~serverとして動作し得る。
◎
The terms client and server refer only to the roles that these programs perform for a particular connection. The same program might act as a client on some connections and a server on others.
</p>

<p class="trans-note">【
接続は、
~messageの経路~全体（接続の`連鎖$）ではなく，
隣接する ある 2 つの参加者（連鎖に属する~node）間の接続を指すことに注意
（個々の参加者から直に見えるのは，隣の参加者だけなので）。
】</p>

<p>
~HTTPは、
`~stateless@
（ `stateless^en ）な~protocolとして定義されている
— すなわち、［
各`要請~message$の意味論は，互いに隔離されても解せる【`自己-記述的$である】
］かつ［
各~接続と接続~上の各~messageとの関係性は、
~messageの解釈には影響iしない
］ことを意味する。
例えば，［
`CONNECT$m 要請, `Upgrade$h ~headerを伴う要請
］どちらも、
接続~上の最初の~messageに限らず，いつでも生じ得る。
多くの実装は、［
~proxyされた接続を再利用する／
複数の~serverにまたがって，要請たちを動的に負荷分散する
］ときに，［
~HTTPの~statelessな設計
］に依存する。
◎
HTTP is defined as a stateless protocol, meaning that each request message's semantics can be understood in isolation, and that the relationship between connections and messages on them has no impact on the interpretation of those messages. For example, a CONNECT request (Section 9.3.6) or a request with the Upgrade header field (Section 7.8) can occur at any time, not just in the first message on a connection. Many implementations depend on HTTP's stateless design in order to reuse proxied connections or dynamically load balance requests across multiple servers.
</p>

<p>
よって，`~server$は、［
同じ接続~上の 2 つの要請
］を同じ`~UA$から来たものと見做してはナラナイ
— その接続が［
`~secure化$されていて，その~UAに特有である
］場合を除き。
一部の非~標準な~HTTP拡張（例： `RFC4559$r）は、
この要件に違反していることが既知であり，
~security, および相互運用能の問題を起こす。
◎
As a result, a server MUST NOT assume that two requests on the same connection are from the same user agent unless the connection is secured and specific to that agent. Some non-standard HTTP extensions (e.g., [RFC4559]) have been known to violate this requirement, resulting in security and interoperability problems.
</p>

		</section>
		<section id="messages">
<h3 title="Messages">3.4. ~message</h3>

<p>
~HTTPは、
接続にまたがって
<dfn>`~message$</dfn>
を交換するための，`~stateless$な［
要請, 応答
］~protocolである。
◎
HTTP is a stateless request/response protocol for exchanging "messages" across a connection.＼
</p>

<p>
用語［
`送信者@
（ `sender^en ）／
`受信者@
（ `recipient^en ）
］は、
所与の~messageを［
送信する／受信する
］任意の実装を指す。
◎
The terms "sender" and "recipient" refer to any implementation that sends or receives a given message, respectively.
</p>

<div class="p">
<p>
`~client$は、
要請を
`要請~message@
（ `request message^en, 略して `request^en ）
の形で`~server$へ送信する。
それは、［
`~method$, `要請~target$
］を伴い，次に挙げるものも包含し得る：
◎
A client sends requests to a server in the form of a "request" message with a method (Section 9) and request target (Section 7.1). The request might also contain＼
</p>
<ul>
	<li>
次に挙げるもの用の，一群の`~header$
⇒＃
要請の改変子【`要請~method$の意味論を改変するもの】／
`~client$情報／
`表現~metadata$
◎
header fields (Section 6.3) for request modifiers, client information, and representation metadata,＼
</li>
	<li>
~methodに則って処理するものと意図される，`内容$。
◎
content (Section 6.4) intended for processing in accordance with the method,＼
</li>
	<li>
`内容$を送信している間に収集された情報を通信するための，一群の`~trailer$。
◎
and trailer fields (Section 6.5) to communicate information collected while sending the content.
</li>
</ul>
</div>

<div class="p">
<p>
`~server$は、
`~client$からの要請に対し，
1 個~以上の
`応答~message@
（ `response message^en, 略して `response^en ）
【 0 個以上の`非最終-応答$, 1 個の`最終-応答$】
を送信して応答する。
各~応答は、
`状態s~code$を伴い，次に挙げるものも包含し得る：
◎
A server responds to a client's request by sending one or more "response" messages, each including a status code (Section 15). The response might also contain＼
</p>
<ul>
	<li>
次に挙げるもの用の，一群の`~header$
⇒＃
~server情報／
資源~metadata／
`表現~metadata$
◎
header fields for server information, resource metadata, and representation metadata,＼
</li>
	<li>
`状態s~code$に則って解釈されることになる，`内容$。
◎
content to be interpreted in accordance with the status code,＼
</li>
	<li>
`内容$を送信している間に収集された情報を通信するための，一群の`~trailer$。
◎
and trailer fields to communicate information collected while sending the content.
</li>
</ul>
</div>

		</section>
		<section id="user.agent">
<h3 title="User Agents">3.5. ~UA</h3>

<p>
用語
`~UA@
（ `user agent^en ）は、［
要請を起動する任意の`~client$~program
］を指す
◎
The term "user agent" refers to any of the various client programs that initiate a request.
</p>

<p>
最も馴染みな~UAは，一般用~Web~browserであるが、
そのような形をとる実装は，一握りに限られる。
共通的な~UAには、
他にも次に挙げるものがある
⇒＃
~spider（~webを辿っている~robot）,
~command-line~tool,
広告塔,
家電,
計測機器,
電球,
~firmware更新~script,
~mobile~app,
~sizeや形状が様々な通信~機器,
◎
The most familiar form of user agent is the general-purpose Web browser, but that's only a small percentage of implementations. Other common user agents include spiders (web-traversing robots), command-line tools, billboard screens, household appliances, scales, light bulbs, firmware update scripts, mobile apps, and communication devices in a multitude of shapes and sizes.
</p>

<p>
~UAであることは、
要請の時点に［
~software~agentと直にヤリトリしているヒト利用者が居る
］ことを含意するわけではない。
多くの事例で、
~UAは~backgroundにて稼働するよう［
~installされて／環境設定されて
］いて，その結果を
（あるいは、
その中の［
関心がある部分や誤りがありそうな部分
］に限り）
今後の検分~用に保存する。
例えば，~spiderは、
概して，［
所与の~URIから開始して、
~Webを~hypertext~graphとして巡る間，一定の挙動に従う
］よう環境設定される。
◎
Being a user agent does not imply that there is a human user directly interacting with the software agent at the time of a request. In many cases, a user agent is installed or configured to run in the background and save its results for later inspection (or save only a subset of those results that might be interesting or erroneous). Spiders, for example, are typically given a start URI and configured to follow certain behavior while crawling the Web as a hypertext graph.
</p>

<p>
多くの~UAは、［
利用者に向けて対話的に何かを示唆する／
~securityや~privacyに関する懸念のために必要十分な警告を供する
］ことはできないか，それをしないことを選ぶ。
この仕様が［
利用者~向けに~errorを報告する
］ことを要求する，少数の事例では、
そのような報告が［
~error~consoleや~log~fileに限り，観測-可能になる
］ことも受容-可能である。
同様に，自動化された動作についても、［
続行する前に利用者による確認を要する
］ような要件は，［
~~事前の環境設定の選択,
稼働時~option,
安全でない動作に対する単純な回避法
］などを介して~~満たされ得る
— 確認は、
利用者がすでにその選択を済ませていた場合には，いかなる［
特定の利用者~interface／通常~処理の中断
］も含意しない。
◎
Many user agents cannot, or choose not to, make interactive suggestions to their user or provide adequate warning for security or privacy concerns. In the few cases where this specification requires reporting of errors to the user, it is acceptable for such reporting to only be observable in an error console or log file. Likewise, requirements that an automated action be confirmed by the user before proceeding might be met via advance configuration choices, run-time options, or simple avoidance of the unsafe action; confirmation does not imply any specific user interface or interruption of normal processing if the user has already made that choice.
</p>

		</section>
		<section id="origin.server">
<h3 title="Origin Server">3.6. 生成元~server</h3>

<p>
用語
`生成元~server@
（ `origin server^en ）は、［
所与の`~target資源$に対する`権限的な応答$
］を出生できる~programを指す。
◎
The term "origin server" refers to a program that can originate authoritative responses for a given target resource.
</p>

<p>
最も馴染みな生成元~serverは、
巨大な公共~web~siteの形をとる。
~UAが~browserと等しくみなされがちなのと同様、
すべての生成元~serverは，そのような~siteである考えに囚われがちだが、
生成元~serverには，次に挙げるものも共通的にある
⇒＃
住宅用自動化設備,
環境設定-可能な~network用~component,
事務機械,
自律的な~robot,
~news-feed,
交通camera,
~real-time広告選定器,
動画配信~platform
◎
The most familiar form of origin server are large public websites. However, like user agents being equated with browsers, it is easy to be misled into thinking that all origin servers are alike. Common origin servers also include home automation units, configurable networking components, office machines, autonomous robots, news feeds, traffic cameras, real-time ad selectors, and video-on-demand platforms.
</p>

<p>
ほとんどの~HTTP通信は、［
`~URI$により識別される何らかの`資源$
］の`表現$に対する，検索取得 要請（ `GET$m ）からなる。
最も単純な事例では、
これは，［
`~UA$（ %UA ）と`生成元~server$（ %O ）の間の，単独の双方向-接続（ `===^c ）
］を介して成遂げられるであろう：
◎
Most HTTP communication consists of a retrieval request (GET) for a representation of some resource identified by a URI. In the simplest case, this might be accomplished via a single bidirectional connection (===) between the user agent (UA) and the origin server (O).
</p>

<pre class="presentation">
       要請   &gt;
  %UA ======================================= %O
                              &lt;   応答
</pre>

		</section>
		<section id="intermediaries">
<h3 title="Intermediaries">3.7. 媒介者</h3>

<p>
~HTTPは、
要請が接続の
`連鎖@
（ `chain^en ）を通り抜けられるようにするため，
`媒介者@
（ `intermediary^en ）の利用も可能化する。
~HTTP媒介者には、
3 種の共通な形［
`~proxy$,
`~gateway$,
`~tunnel$
］がある。
一部の事例では、
単独の媒介者が，各~要請の資質に基づいて 自身の挙動を［
`生成元~server$,
`~proxy$,
`~gateway$,
`~tunnel$
］のいずれかに切替えながら動作することもある。
◎
HTTP enables the use of intermediaries to satisfy requests through a chain of connections. There are three common forms of HTTP "intermediary": proxy, gateway, and tunnel. In some cases, a single intermediary might act as an origin server, proxy, gateway, or tunnel, switching behavior based on the nature of each request.
</p>

<pre class="presentation">
       &gt;             &gt;             &gt;             &gt;
  %UA =========== %A =========== %B =========== %C =========== %O
             &lt;             &lt;             &lt;             &lt;
</pre>

<div class="p">
<p>
上の図は、
`~UA$（ %UA ）と `生成元~server$（ %O ）の間に挟まれた，
3 つの`媒介者$（ %A, %B, %C ）を示している。
`連鎖$の端から端まで届けられる［
要請／応答
］~messageは、
4 つの別々な接続を通過するよう渡り歩くことになる。
~HTTP通信~optionには、
次のいずれかに適用されるものもある：
◎
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 will pass through four separate connections. Some HTTP communication options might apply＼
</p>
<ul>
	<li>
最も近い, `~tunnel$でない隣接点との接続のみ
【 `隣点間@（ `hop-by-hop^en ） 】
◎
only to the connection with the nearest, non-tunnel neighbor,＼
</li>
	<li>
連鎖の両
`端点@
（ `endpoint^en ）
にのみ
◎
only to the endpoints of the chain, or＼
</li>
	<li>
連鎖~沿いにある すべての接続
【 `端点間@（ `end-to-end^en ）】
◎
to all connections along the chain.＼
</li>
</ul>

<p>
また，上の図式は単線だが、
各~参加者は，同時に複数の通信に携わることもある。
例えば %B は、
%A からの要請を取扱うと同時に，［
%A 以外の多数の~clientからの要請を受信していたり,
%C 以外の`~server$向けの要請を回送している
］こともあり得る。
同様に，今後の要請が、
異なる経路による接続
— 多くの場合、
負荷分散~用の動的~環境設定に基づく —
を通して送信されることもあり得る。
◎
Although the diagram is linear, each participant might be engaged in multiple, simultaneous communications. For example, B might 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. Likewise, later requests might be sent through a different path of connections, often based on dynamic configuration for load balancing.
</p>
</div>

<p>
用語
`上流@
（ `upstream^en ）／
`下流@
（ `downstream^en ）は、［
~messageが流れる方向
］に関係して，要件を述べるときに利用される
— すべての~messageは、
上流から下流へ流れる。
用語
`内方@
（ `inbound^en ）／
`外方@
（ `outbound^en ）は、［
要請が~routeされる方向
］に関係して，要件を述べるときに利用される
— 内方は “`生成元~server$へ向かう” こと,
外方は “`~UA$へ向かう” ことを意味する。
◎
The terms "upstream" and "downstream" are used to describe directional requirements in relation to the message flow: all messages flow from upstream to downstream. The terms "inbound" and "outbound" are used to describe directional requirements in relation to the request route: inbound means "toward the origin server", whereas outbound means "toward the user agent".
</p>

<p class="trans-note">【
~messageが応答ならば［
上流／下流
］は［
内方／外方
］と同義になり、
要請ならば，その逆になる。
】</p>

<p>
`~proxy@
（ `proxy^en ）は、［
何らかの型の絶対~URIへ向けた要請を受信したときには、［
~HTTP~interfaceを通した翻訳
］を介して，その要請を満足しようと試みる
］ような，~message回送~agentであり、
通例的に，`~client$により
— ~clientの局所的な環境設定~規則を介して —
選ばれる。
翻訳には、［
"`http$c" ~URIへ向けた~proxy要請のような必要最小限なもの
］もある一方，［
全面的に異なる［
応用~levelの~protocol
］への／からの翻訳を要する要請
］もあり得る。
`~proxy$は、［
~security~service／注釈~service†／共用~caching
］の~~目的で，［
組織~内の~HTTP要請を，共通な`媒介者$を通して~group分けする
］ために利用されることが多い。
一部の`~proxy$は、
~messageを回送する際に，選定された［
~message／`内容$
］に`形式変換$を適用するよう設計されている。
◎
A "proxy" is a message-forwarding agent that is chosen by the client, usually via local configuration rules, to receive requests for some type(s) of absolute URI and attempt to satisfy those requests via translation through the HTTP interface. Some translations are minimal, such as for proxy requests for "http" URIs, whereas other requests might require translation to and from entirely different application-level protocols. Proxies are often used to group an organization's HTTP requests through a common intermediary for the sake of security services, annotation services, or shared caching. Some proxies are designed to apply transformations to selected messages or content while they are being forwarded, as described in Section 7.7.
</p>

<p class="trans-note">【
語 “~proxy” は、
以下に述べる他種の~proxyも含めた総称として利用されることもあり，多義性を孕む。
それらと区別するため、
上で述べた種別の~proxyは，
`回送-~proxy@
（ `forward proxy^en ）と呼ばれることもある
（この~RFCには現れないが）。
】【†
元の~dataに~~注釈情報（ `annotation^en ）を付加する（例：用語に~linkを補完する）ような~serviceを意味すると思われる。
】</p>

<div class="p">
<p>
`~gateway@
（ `gateway^en ）
（いわゆる
`逆~proxy@
（ `reverse proxy^en ））
は，`媒介者$の一種であり、
`外方$への接続に対しては`生成元~server$として動作しつつ，
受信した要請を翻訳して `内方$にある別の`~server$たちへ回送する。
~gatewayは、
次のために利用されることが多い：
◎
A "gateway" (a.k.a. "reverse proxy") is an intermediary that acts as an origin server for the outbound connection but translates received requests and forwards them inbound to another server or servers. Gateways are often used＼
</p>
<ul>
	<li>
旧来の, あるいは信用できない情報~serviceを~capsule化する。
◎
to encapsulate legacy or untrusted information services,＼
</li>
	<li>
~cachingによる
`加速器@
（ `accelerator^en ）を通して~server処理能を改善する。
◎
to improve server performance through "accelerator" caching, and＼
</li>
	<li>
複数の~machineにまたがる［
~HTTP~serviceの区割りや負荷分散
］を可能化する。
◎
to enable partitioning or load balancing of HTTP services across multiple machines.
</li>
</ul>
</div>

<p>
`生成元~server$に適用-可能な，すべての~HTTP要件は、
`~gateway$の`外方$への通信にも適用される。
`~gateway$は、
自身が欲する任意の~protocol
— この仕様の視野から外れる，~HTTPに対する私的~拡張も含む —
を利用して，`内方$にある`~server$と通信する。
しかしながら，［
第三者-主体の~HTTP~serverと相互運用するよう望む~HTTP-to-HTTP`~gateway$
］は、［
~gatewayの`内方$への接続
］に課される`~UA$要件にも適合する必要がある。
◎
All HTTP requirements applicable to an origin server also apply to the outbound communication of a gateway. A gateway communicates with inbound servers using any protocol that it desires, including private extensions to HTTP that are outside the scope of this specification. However, an HTTP-to-HTTP gateway that wishes to interoperate with third-party HTTP servers needs to conform to user agent requirements on the gateway's inbound connection.
</p>

<p>
`~tunnel@
（ `tunnel^en ）は、
~messageを変更することなく，
2 つの接続の間を盲目的に中継するように動作する。
いったん作動中になった~tunnelは、
それが~HTTP要請により起動されたとしても，~HTTP通信の主体とは見なされない。
~tunnelが存在し得るのは、［
中継された接続の両~端
］が~closeされるまでである。
~tunnelは、
`媒介者$を通した仮想~接続を拡張するために利用される
— 共用~firewall~proxyを通した機密的な通信を確立するために，
~TLS（ `Transport Layer Security^en, `TLS13$r）が利用されるときなど。
◎
A "tunnel" acts as a blind relay between two connections without changing the messages. Once active, a tunnel is not considered a party to the HTTP communication, though the tunnel might have been initiated by an HTTP request. A tunnel ceases to exist when both ends of the relayed connection are closed. Tunnels are used to extend a virtual connection through an intermediary, such as when Transport Layer Security (TLS, [TLS13]) is used to establish confidential communication through a shared firewall proxy.
</p>

<p>
上述した`媒介者$用の類別は、［
~HTTP通信における参加者
］として動作しているものしか考慮しない。
媒介者には、［
~network~protocol~stackを成す より低~層
］で動作して，［
~message送信者についての知識や許可
］を伴わずに［
~HTTP流通を~filterしたり~redirectする
］ものもある。
~network媒介者は，（~protocol~levelでは）経路上の攻撃者†かどうか判別-不能なので、［
~HTTP意味論を誤解して違反することに因る，~securityの欠陥や相互運用能の問題
］が導入されることも多い。
【† `on-path attacker^en — 旧称 `man-in-the-middle^en （~~中間者）】
◎
The above categories for intermediary only consider those acting as participants in the HTTP communication. There are also intermediaries that can act on lower layers of the network protocol stack, filtering or redirecting HTTP traffic without the knowledge or permission of message senders. Network intermediaries are indistinguishable (at a protocol level) from an on-path attacker, often introducing security flaws or interoperability problems due to mistakenly violating HTTP semantics.
</p>

<p>
例えば，
`横取n~proxy@
（ `interception proxy^en ）
`RFC3040$r
（
`透過的~proxy@
（ `transparent proxy^en ）
`RFC1919$r としても共通的に知られる）
は、
~clientにより選ばれるものではない点で，~HTTP`~proxy$とは相違する。
代わりに，横取n~proxyは、［
外向けの~TCP~port 80 ~packet
］を（ときには、他の共通的な~port上の流通も），~filterしたり~redirectする。
横取n~proxyは、
公共~network~access~pointで［
局所的でない~Internet~serviceの利用を許容するに先立って，
~account~subscriptionを施行するための手段
］として, あるいは企業~firewallの中で［
~network利用e~施策を施行するため
］として，共通的に見出される
◎
For example, an "interception proxy" [RFC3040] (also commonly known as a "transparent proxy" [RFC1919]) differs from an HTTP proxy because it is not chosen by the client. Instead, an interception proxy filters or redirects outgoing TCP port 80 packets (and occasionally other common port traffic). Interception proxies are commonly found on public network access points, as a means of enforcing account subscription prior to allowing use of non-local Internet services, and within corporate firewalls to enforce network usage policies.
</p>

		</section>
		<section id="caches">
<h3 title="Caches">3.8. ~cache</h3>

<p>
`~cache@
（ `cache^en ）とは、
以前に受信した`応答~message$たちが成す局所的な格納域であり，それらの~messageの［
~storage, 検索取得, 削除
］を制御する下位~systemである。
~cacheは、
`~cache可能$な応答を，未来の等価な要請に要する［
応答~時間／~network帯域幅の消費
］を抑制するために格納する。
どの［
`~client$／`~server$
］も，~cacheを使役してヨイ
— `~tunnel$として動作している間は、
~cacheを利用し得ないが。
◎
A "cache" is a local store of previous response messages and the subsystem that controls its message storage, retrieval, and deletion. A cache stores cacheable responses in order to reduce the response time and network bandwidth consumption on future, equivalent requests. Any client or server MAY employ a cache, though a cache cannot be used while acting as a tunnel.
</p>

<p>
~cacheによる効果は、［
要請／応答
］の連鎖が
— ［
`連鎖$沿いにある いずれかの参加者
］が［
その要請に適用-可能な ~cache済み応答
］を有するときには —
短縮されることである。
次の図に、
ある要請に対し，参加者 %B が~cache済み複製
— それは［
~~以前に
【ある~UAによる，その要請と等価な要請に対し，生成元~server】
%O から（ %C を介して）返された応答
］の複製であり，［
%UA や %A には まだ~cacheされていない
］とする —
を有しているときの結果を示す：
◎
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 cached copy of an earlier response from O (via C) for a request that has not been cached by UA or A.
</p>

<pre class="presentation">
          &gt;             &gt;
     %UA =========== %A =========== %B - - - - - - %C - - - - - - %O
                &lt;             &lt;
</pre>

<p>
`応答~message$は、［
後続な要請に対する回答に利用するためとして，複製を~cacheに格納することが許容される
］とき，
`~cache可能@
（ `cacheable^en ）であるという。
応答が~cache可能であるとしても、［
特定0の要請に対し，~cache済み応答が いつ利用できるか
］について，［
`~client$や`生成元~server$により，追加的な拘束が設置される
］こともある。
［
~cacheの挙動, および
~cache可能な応答
］に課される~HTTP要件は、
`CACHING$r にて定義される。
◎
A response is "cacheable" if a cache is allowed to store a copy of the response message for use in answering subsequent requests. Even when a response is cacheable, there might be additional constraints placed by the client or by the origin server on when that cached response can be used for a particular request. HTTP requirements for cache behavior and cacheable responses are defined in [CACHING].
</p>

<p>
World Wide Webや, 巨大な組織の内側にまたがって配備されている~cacheには、
多種多様な~architectureや環境設定がある。
これらには、
次に挙げるものなども含まれる
⇒＃
帯域幅を節約して待時間を抑制するための，~proxy~cacheの国別~階層／
~gateway~cache法を利用して人気~siteの局地的, および大域的な配布を最適化する，~CDN（ `content delivery network^en（内容~送達~network））／
~cache~entryを~broadcastしたり~multicastする，協調的な~system／
~off-lineや待時間が長い環境で利用するために事前fetchされた，~cache~entryの~archive
◎
There is a wide variety of architectures and configurations of caches deployed across the World Wide Web and inside large organizations. These include national hierarchies of proxy caches to save bandwidth and reduce latency, content delivery networks that use gateway caching to optimize regional and global distribution of popular sites, collaborative systems that broadcast or multicast cache entries, archives of pre-fetched cache entries for use in off-line or high-latency environments, and so on.
</p>

		</section>
		<section id="example">
<h3 title="Example Message Exchange">3.9. ~message交換の例</h3>

<div class="example">
<p>
代表的な例として、
~URI
"`http://www.example.com/hello.txt^c"
へ向けた `GET$m 要請における，~HTTP11~message交換の様子を次に示す：
◎
The following example illustrates a typical HTTP/1.1 message exchange for a GET request (Section 9.3.1) on the URI "http://www.example.com/hello.txt":
</p>

<p>
~clientによる要請：
◎
Client request:
</p>

<pre class="lang-http">
GET /hello.txt HTTP/1.1
User-Agent: curl/7.64.1
Host: www.example.com
Accept-Language: en, mi
</pre>

<p>
~serverからの応答：
◎
Server response:
</p>

<pre class="lang-http">
HTTP/1.1 200 OK
Date: Mon, 27 Jul 2009 12:28:53 GMT
Server: Apache
Last-Modified: Wed, 22 Jul 2009 19:15:56 GMT
ETag: "34aa387-d-1568eb00"
Accept-Ranges: bytes
Content-Length: 51
Vary: Accept-Encoding
Content-Type: text/plain

Hello World! My content includes a trailing CRLF.
</pre>
</div>

		</section>
	</section>
	<section id="uri">
<h2 title="Identifiers in HTTP">4. ~HTTPにおける識別子</h2>
<p>
~HTTP~~全体に渡り、
`~URI^dfn
（ `Uniform Resource Identifiers^en `URI$r — 統一的~資源~識別子）
が，`資源$を識別するための手段に利用される。
◎
Uniform Resource Identifiers (URIs) [URI] are used throughout HTTP as the means for identifying resources (Section 3.1).
</p>

		<section id="uri.references">
<h3 title="URI References">4.1. ~URI参照</h3>

<p>
`~URI参照@
（ `URI-reference$p ）は、［
`要請~target$を与える／~redirectを指示する／関係性を定義する
］ために利用される。
◎
URI references are used to target requests, indicate redirects, and define relationships.
</p>

<div>
<p>
次に挙げる各種~定義は、
~URIの汎用~構文から採用されている【 ";" 以下の~commentは訳者補足】：
</p>

<pre class="bnf">
`URI-reference@p
	= &lt;URI-reference, `URI$r `4.1§uri&gt; ; `~URI参照^com
`absolute-URI@p
	= &lt;absolute-URI, `URI$r `4.3§uri&gt; ; `絶対~URI^com
`relative-part@p
	= &lt;relative-part, `URI$r `4.2§uri&gt; ; `相対~URI（~query以下を除く）^com
`authority@p
	= &lt;authority, `URI$r `3.2§uri&gt; ; `権限^com
`uri-host@p
	= &lt;`host@p, `URI$r `3.2.2§uri&gt; ; `~host^com
`port@p
	= &lt;port, `URI$r `3.2.3§uri&gt; ; `~port^com
`path-abempty@p
	= &lt;path-abempty, `URI$r `3.3§uri&gt; ; `~path（空もあり）^com
`segment@p
	= &lt;segment, `URI$r `3.3§uri&gt; ; `~pathの一階層^com
`query@p
	= &lt;query, `URI$r `3.4§uri&gt; ; `~query^com
</pre>

<p class="trans-note">【
その他、
原文には［
`scheme@p （~scheme）,
`path@p （~path）,
`fragment@p （素片~識別子）
］も現れる。
これらが［
`URI$r に定義される~protocol要素,
それが表現する概念
］のどちらを表すかは、
明確に線引きできず，両義的に解釈できる箇所もある。
`host$p （~host）, `port$p （~port）についても同様。
】</p>

<p>
加えて，次の規則も定義される：
</p>

<pre class="bnf">
`absolute-path@p
	= 1*( "/" `segment$p )
`partial-URI@p
	= `relative-part$p [ "?" `query$p ]
</pre>

<p>
`absolute-path$p 規則は、［
空でない `path$p 成分を包含し得る~protocol要素
］用に定義される。
（この規則は、
`URI$r の［
`path-abempty^p ／ `path-absolute^p
］規則から少し相違する
— 前者は空な `path^p を許容する ／
後者は "`//^c" から始まる `path^p を許容しない
。）
</p>

<p>
`partial-URI$p 規則は、［
相対~URIを包含できるが，その中に `fragment$p 成分は包含できない
］ような~protocol要素~用に定義される。
</p>

◎
The definitions of "URI-reference", "absolute-URI", "relative-part", "authority", "port", "host", "path-abempty", "segment", and "query" are adopted from the URI generic syntax.＼
An "absolute-path" rule is defined for protocol elements that can contain a non-empty path component. (This rule differs slightly from the path-abempty rule of RFC 3986, which allows for an empty path, and path-absolute rule, which does not allow paths that begin with "//".)＼
A "partial-URI" rule is defined for protocol elements that can contain a relative URI but not a fragment component.


  URI-reference = &lt;URI-reference, see [URI], Section 4.1&gt;
  absolute-URI  = &lt;absolute-URI, see [URI], Section 4.3&gt;
  relative-part = &lt;relative-part, see [URI], Section 4.2&gt;
  authority     = &lt;authority, see [URI], Section 3.2&gt;
  uri-host      = &lt;host, see [URI], Section 3.2.2&gt;
  port          = &lt;port, see [URI], Section 3.2.3&gt;
  path-abempty  = &lt;path-abempty, see [URI], Section 3.3&gt;
  segment       = &lt;segment, see [URI], Section 3.3&gt;
  query         = &lt;query, see [URI], Section 3.4&gt;
  
  absolute-path = 1*( "/" segment )
  partial-URI   = relative-part [ "?" query ]
</div>

<div class="p">
<p>
~HTTPにおける［
`~URI参照$を許容する各~protocol要素
］では、
その~ABNF生成規則により，［
次に挙げるどれが，当の要素に許容されるか
］を指示することになる：
◎
Each protocol element in HTTP that allows a URI reference will indicate in its ABNF production whether the element allows＼
</p>
<ul>
	<li>
任意の形による参照（ `URI-reference$p ）
◎
any form of reference (URI-reference),＼
</li>
	<li>
絶対~形（ `absolute-URI$p ）による~URIのみ
◎
only a URI in absolute form (absolute-URI),＼
</li>
	<li>
`path$p 成分と省略可能な `query$p 成分のみ（ `partial-URI$p ）
◎
only the path and optional query components (partial-URI),＼
</li>
	<li>
前項と前前項の組合n
◎
or some combination of the above.＼
</li>
</ul>

<p>
他が指示されない限り、
`~URI参照$は，`~target~URI$に相対的に構文解析される。
◎
Unless otherwise indicated, URI references are parsed relative to the target URI (Section 7.1).
</p>
</div>

<p>
すべての［
`送信者$／`受信者$
］は、
~protocol要素の長さにおいて，
最小でも 8000 個以上の~octetからなる~URIを~supportすることが`推奨される^2119。
このことは、
次が必要yなことを含意することに注意
⇒
一部の事例では、
何らかの構造と その伝送路~上の表現
（例えば、
~HTTP11における `request-line＠~HTTPv1#p.request-line$p ）
をより大きくする
◎
It is RECOMMENDED that all senders and recipients support, at a minimum, URIs with lengths of 8000 octets in protocol elements. Note that this implies some structures and on-wire representations (for example, the request line in HTTP/1.1) will necessarily be larger in some cases.
</p>

		</section>
		<section id="uri.schemes">
<h3 title="HTTP-Related URI Schemes">4.2. ~HTTPに関係する~URI~scheme</h3>

<p id="uri.scheme.table">
~IANAは、
`~URI~scheme~registry$cite `BCP35$r
を保守する。
どの~URI`~scheme$も`要請~target$を成し得るが、
次に挙げる~schemeは，~HTTP~serverに内来的である
⇒＃
`http$c,
`https$c
◎
IANA maintains the registry of URI Schemes [BCP35] at &lt;https://www.iana.org/assignments/uri-schemes/&gt;. Although requests might target any URI scheme, the following schemes are inherent to HTTP servers:
◎
↓ § 18.2
Table 2
URI Scheme｜Description｜Section

http｜Hypertext Transfer Protocol｜4.2.1
https｜Hypertext Transfer Protocol Secure｜4.2.2
</p>

<p>
［
"`http$c" ／ "`https$c"
］~URIが在ることが［
~URIで識別される`生成元$に，接続を~listenしている~HTTP`~server$が常に在る
］ことを含意することにはならないことに注意。
［
~serverが存在するかどうか,
~serverが現在 その識別子をある資源に対応付けているかどうか
］を問わず、
~URIは誰もが創出できる。
登録-済みな名前と~IP~addressは、
委任される資質があり，連合された名前空間を作成する
— そこに~HTTP~serverが在ろうが無かろうが。
◎
Note that the presence of an "http" or "https" URI does not imply that there is always an HTTP server at the identified origin listening for connections. Anyone can mint a URI, whether or not a server exists and whether or not that server currently maps that identifier to a resource. The delegated nature of registered names and IP addresses creates a federated namespace whether or not an HTTP server is present.
</p>

			<section id="http.uri">
<h4 title="http URI Scheme">4.2.1. `http^c ~URI~scheme</h4>

<p>
"`http^c" ~URI`~scheme$は、［
所与の`~port$上で~TCP （ `TCP$r ）接続を~listenする~~可能性がある~HTTP`生成元~server$
］により統治される階層的な名前空間の中で，【`資源$の】識別子を創出するためとして、
ここに定義される。
◎
The "http" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential HTTP origin server listening for TCP ([TCP]) connections on a given port.
</p>

<pre class="bnf">
`http-URI@p
	= "http" "://" `authority$p `path-abempty$p [ "?" `query$p ]
</pre>

<p>
"`http^c" ~URI用の`生成元~server$は、
`authority$p 成分により識別される
— それは、［
`host$p 識別子（ `URI$r `3.2.2§uri ）, および
省略可能な~TCP `port$p 番号（ `URI$r `3.2.3§uri ）
］を内包する。
`port$p 下位成分が［
空な場合／与えられていない場合
］の既定の~TCP~portは、
80 （ WWW ~service用に予約された~port）とする。
`生成元$は、［
識別される`資源$を~targetにする要請に対し，誰が`権限的$に応答する権利を有するか
］を
— `4.3.2§ にて定義されるとおりに —
決定する。
◎
The origin server for an "http" URI is identified by the authority component, which includes a host identifier ([URI], Section 3.2.2) and optional port number ([URI], Section 3.2.3). If the port subcomponent is empty or not given, TCP port 80 (the reserved port for WWW services) is the default. The origin determines who has the right to respond authoritatively to requests that target the identified resource, as defined in Section 4.3.2.
</p>

<p>
`送信者$は、［
`host$p 識別子が空にされた "`http^c" ~URI
］を`生成-$してはナラナイ。
そのような`~URI参照$を処理する`受信者$は、
それを妥当でないものとして却下しなければナラナイ。
◎
A sender MUST NOT generate an "http" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
</p>

<p>
［
階層的な `path$p, 省略可能な `query$p
］成分は、［
その`生成元~server$の名前空間の中で，`~target資源$になるもの
］を識別する。
◎
The hierarchical path component and optional query component identify the target resource within that origin server's namespace.
</p>

			</section>
			<section id="https.uri">
<h4 title="https URI Scheme">4.2.2. `https^c ~URI~scheme</h4>

<p>
"`https^c" ~URI`~scheme$は、［
所与の`~port$上で~TCP（ `TCP$r ）接続を~listenする~~可能性がある`生成元~server$
］のうち［
~HTTP通信~用に`~secure化$された~TLS `TLS13$r 接続を確立する能力があるもの
］により統治される階層的な名前空間の中で，【資源の】識別子を創出するためとして、
ここに定義される。
この文脈における
`~secure化@
されている（ `secured^en ）とは、
特定的に次を意味する
⇒
~serverは，識別された権限に利するよう動作しているものとして認証されていて、
~serverとのすべての~HTTP通信における機密性と完全性の保護は，［
`~client$, `~server$
］どちらからも受容-可能である
◎
The "https" URI scheme is hereby defined for minting identifiers within the hierarchical namespace governed by a potential origin server listening for TCP connections on a given port and capable of establishing a TLS ([TLS13]) connection that has been secured for HTTP communication. In this context, "secured" specifically means that the server has been authenticated as acting on behalf of the identified authority and all HTTP communication with that server has confidentiality and integrity protection that is acceptable to both client and server.
</p>

<pre class="bnf">
`https-URI@p
	= "https" "://" `authority$p `path-abempty$p [ "?" `query$p ]
</pre>

<p>
"`https^c" ~URI用の`生成元~server$は、
`authority$p 成分により識別される
— それは、［
`host$p 識別子（ `URI$r `3.2.2§uri ）, および
省略可能な~TCP `port$p 番号（ `URI$r `3.2.3§uri ）
］を内包する。
`port$p 下位成分が［
空な場合／与えられていない場合
］の既定の~TCP~portは、
443 （~TLS越しの~HTTP用に予約された~port）とする。
`生成元$は、［
識別される`資源$を~targetにする要請に対し，誰が`権限的$に応答する権利を有するか
］を
— `4.3.3§ にて定義されるとおりに —
決定する。
◎
The origin server for an "https" URI is identified by the authority component, which includes a host identifier ([URI], Section 3.2.2) and optional port number ([URI], Section 3.2.3). If the port subcomponent is empty or not given, TCP port 443 (the reserved port for HTTP over TLS) is the default. The origin determines who has the right to respond authoritatively to requests that target the identified resource, as defined in Section 4.3.3.
</p>

<p>
`送信者$は、［
`host$p 識別子が空にされた "`https^c" ~URI
］を`生成-$してはナラナイ。
そのような`~URI参照$を処理する`受信者$は、
それを妥当でないものとして却下しなければナラナイ。
◎
A sender MUST NOT generate an "https" URI with an empty host identifier. A recipient that processes such a URI reference MUST reject it as invalid.
</p>

<p>
［
階層的な `path$p,
省略可能な `query$p
］成分は、［
その`生成元~server$の名前空間の中で，`~target資源$になるもの
］を識別する。
◎
The hierarchical path component and optional query component identify the target resource within that origin server's namespace.
</p>

<p>
`~client$は、
自身による［
"`https^c" 資源への~HTTP要請
］に対し，次を確保しなければナラナイ
⇒＃
通信されるに先立って，要請は`~secure化$されること／
要請に対する応答は，`~secure化$されたものに限り受容すること
◎
A client MUST ensure that its HTTP requests for an "https" resource are secured, prior to being communicated, and that it only accepts secured responses to those requests.＼
</p>

<p>
［
`~client$, `~server$
］にとって，暗号用の仕組みとして何が受容-可能になるかは、
通例的に折衝されるものであり，その定義は時を経れば変化し得ることに注意。
◎
Note that the definition of what cryptographic mechanisms are acceptable to client and server are usually negotiated and can change over time.
</p>

<p>
"`https^c" `~scheme$を介して可用にされた`資源$は、
"`http$c" `~scheme$を伴うものとは，同一性を共有しない
— それらは、
別個な名前空間を伴う，別個な`生成元$と見なされる。
しかしながら，~HTTPに対する拡張のうち［
同じ~hostに属する すべての`生成元$に適用されるように定義されたもの
］
— ~Cookie~protocol `COOKIE$r など —
は、［
ある~serviceから設定された情報
］による［
~host~domainに合致する~groupに属する他の~service
］との通信への影響iを許容する。
そのような拡張は、［
`~secure化$された接続から得された情報が，
~secure化されていない文脈の中で不作為に交換される
］ことを防止するよう，多大な~careの下で設計される~OUGHT。
◎
Resources made available via the "https" scheme have no shared identity with the "http" scheme. They are distinct origins with separate namespaces. However, extensions to HTTP that are defined as applying to all origins with the same host, such as the Cookie protocol [COOKIE], allow information set by one service to impact communication with other services within a matching group of host domains. Such extensions ought to be designed with great care to prevent information obtained from a secured connection being inadvertently exchanged within an unsecured context.
</p>

			</section>
			<section id="uri.comparison">
<h4 title="http(s) Normalization and Comparison">4.2.3. `http^c／`https^c ~URI の正規化と比較</h4>

<p>
［
"`http$c" ／ "`https$c"
］~schemeを伴う~URIは、
`URI$r `6§uri に定義される手法に則って
— 上で述べた，各~schemeに対する既定を利用して —
正規化され，比較される。
◎
URIs with an "http" or "https" scheme are normalized and compared according to the methods defined in Section 6 of [URI], using the defaults described above for each scheme.
</p>

<p>
~HTTPは、
等価性を決定するために特定の手法を利用することは要求しない。
例えば，ある~cache~keyは、［
構文に基づく正規化【 `URI$r `6.2.2§uri 】／~schemeに基づく正規化
］の後に，単純な文字列として比較されるかもしれない。
◎
HTTP does not require the use of a specific method for determining equivalence. For example, a cache key might be compared as a simple string, after syntax-based normalization, or after scheme-based normalization.
</p>

<p>
~schemeに基づく正規化（ `URI$r `6.2.3§uri ）は、［
"`http$c" ／ "`https$c"
］~URIに対しては，次に挙げる追加的な規則を孕む：
◎
Scheme-based normalization (Section 6.2.3 of [URI]) of "http" and "https" URIs involves the following additional rules:
</p>
<ul>
	<li>
`port$p が `scheme$p 用の既定の~portに等しい場合、
`port$p 下位成分は省略するのが正規な形とする。
◎
If the port is equal to the default port for a scheme, the normal form is to omit the port subcomponent.
</li>
	<li>
空な `path$p 成分は
— `OPTIONS$m 要請の~targetとして利用されている場合を除き —
絶対~path "`/^c" と等価になるので，
代わりに "`/^c" を~pathとして供するのが正規な形とする。
◎
When not being used as the target of an OPTIONS request, an empty path component is equivalent to an absolute path of "/", so the normal form is to provide a path of "/" instead.
</li>
	<li>
`scheme$p, `host$p は文字大小無視であり、
通常は小文字で供される。
他の成分は、
どれも文字大小区別で比較される。
◎
The scheme and host are case-insensitive and normally provided in lowercase; all other components are compared in a case-sensitive manner.
</li>
	<li>
“予約-済み” 集合【 `reserved^p 】に属さない文字は、
~percent符号化した~octet列と等価になる。
それらは、
符号化しないのが正規な形とする
（ `URI$r `2.1§uri, `2.2§uri を見よ）。
◎
Characters other than those in the "reserved" set are equivalent to their percent-encoded octets: the normal form is to not encode them (see Sections 2.1 and 2.2 of [URI]).
</li>
</ul>

<div class="example">
<p>
例えば、
次の 3 つの~URIは，等価になる：
◎
For example, the following three URIs are equivalent:
</p>

<pre>
http://example.com:80/~smith/home.html
http://EXAMPLE.com/`%7Esmith^/home.html
http://EXAMPLE.com:/`%7esmith^/home.html
</pre>
</div>

<p>
（利用する手法は問わず）
正規化の後に等価になる 2 つの~HTTP~URIは、
同じ資源を識別するものと見做せる
— 正規化を遂行するのは、
どの~HTTP~componentでもヨイ。
したがって，
（ `URI$r `6.2§uri に定義される手法を利用して）
正規化した結果が等価になる 2 つの~HTTP~URIは、
別個な資源を識別するベキでない。
◎
Two HTTP URIs that are equivalent after normalization (using any method) can be assumed to identify the same resource, and any HTTP component MAY perform normalization. As a result, distinct resources SHOULD NOT be identified by HTTP URIs that are equivalent after normalization (using any method defined in Section 6.2 of [URI]).
</p>

			</section>
			<section id="http.userinfo">
<h4 title="Deprecation of userinfo in http(s) URIs">4.2.4. `http^c／`https^c ~URIにおける `userinfo^p の非推奨化</h4>

<p>
［
`authority$p （権限）用の~URIの汎用~構文
］には、［
利用者~認証~情報を~URI内に内包するための
`userinfo@p
下位成分（ `URI$r `3.2.1§uri ）
］も含まれている。
そのような下位成分においては、
"`user:password^c" 形式の利用は非推奨にされた。
【 ~passwordが無いもの（ "`:^c" を含まないもの）は非推奨にされていない。】
◎
The URI generic syntax for authority also includes a userinfo subcomponent ([URI], Section 3.2.1) for including user authentication information in the URI. In that subcomponent, the use of the format "user:password" is deprecated.
</p>

<p>
一部の実装は、
`userinfo^p 成分を，認証~情報の内部~環境設定
— ［
~command呼出nの~option,
環境設定~file,
~bookmark~list
］などの中など —
に用立てる
— そのような用法が［
利用者~識別子や~password
］を公開するかもしれないとしても。
◎
Some implementations make use of the userinfo component for internal configuration of authentication information, such as within command invocation options, configuration files, or bookmark lists, even though such usage might expose a user identifier or password.
</p>

<p>
`送信者$は、［
"`http^c" ／ "`https^c"
］`~URI参照$を［
`~target~URI$や`~field値$
］として~message内に`生成-$するときには，［
`userinfo^p 下位成分（および その "`@^c" 区切子）
］を`生成-$してはナラナイ。
◎
A sender MUST NOT generate the userinfo subcomponent (and its "@" delimiter) when an "http" or "https" URI reference is generated within a message as a target URI or field value.
</p>

<p>
`受信者$は、
信用できない~sourceから受信される［
"`http^c" ／ "`https^c"
］`~URI参照$を用立てる前に，［
`userinfo^p を構文解析した上で，それが在る場合は~errorとして扱う
］ベキである
— それは、
~phishing攻撃の~~目的で，権限を隠蔽するために利用された可能性が高いので。
◎
Before making use of an "http" or "https" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.
</p>

			</section>
			<section id="uri.fragment.identifiers">
<h4 title="http(s) References with Fragment Identifiers">4.2.5. 素片~識別子を伴う `http^c／`https^c ~URI参照</h4>

<p>
素片~識別子（ `fragment^p ）は、
`URI$r `3.5§uri にて定義されるとおり，
~URI`~scheme$とは独立に資源の間接的な識別を許容する。
~URIを指す一部の~protocol要素には、
`fragment$p の内包を許容するものもあれば，そうでないものもある。
それは、
利用される~ABNF規則が `fragment^p を許容するかどうかにより判別される。
`fragment^p を除外した規則が利用される所では、
素片は許容されない。
◎
Fragment identifiers allow for indirect identification of a secondary resource, independent of the URI scheme, as defined in Section 3.5 of [URI]. Some protocol elements that refer to a URI allow inclusion of a fragment, while others do not. They are distinguished by use of the ABNF rule for elements where fragment is allowed; otherwise, a specific rule that excludes fragments is used.
</p>

<p class="note">注記：
素片~識別子~成分は、
~URI`~scheme$用の~scheme定義の一部を成さないので
（ `URI$r `4.3§uri を見よ），
上の［
"`http^c" ／ "`https^c"
］~URI`~scheme$用の~ABNF定義~内には出現しない。
◎
Note: The fragment identifier component is not part of the scheme definition for a URI scheme (see Section 4.3 of [URI]), thus does not appear in the ABNF definitions for the "http" and "https" URI schemes above.
</p>

			</section>
		</section>
		<section id="authoritative.access">
<h3 title="Authoritative Access">4.3. 権限的な~access</h3>

<p>
権限的（ `authoritative^en ）な~accessとは、
所与の識別子【~URI】による参照を解く（ `dereference^en する）こと
— ［
それにより識別される資源への~access
］を得るために，［
その~accessは権限的である【~accessする権限がある】
（その可否は、
当の資源の所有者により制御される）
と`~client$が予見する仕方
］で解くこと —
を指す。
その~accessが是認されるか否かを決定するための処理nは、
当の~URI~schemeにより定義され，~URI成分の中の~data
— 汎用~構文が利用されるときの `authority$p 成分など —
を利用することが多い。
しかしながら、
権限的な~accessは，【~schemeにより】識別される仕組みに制限されない。
◎
Authoritative access refers to dereferencing a given identifier, for the sake of access to the identified resource, in a way that the client believes is authoritative (controlled by the resource owner). The process for determining whether access is granted is defined by the URI scheme and often uses data within the URI components, such as the authority component when the generic syntax is used. However, authoritative access is not limited to the identified mechanism.
</p>

<p>
`4.3.1§ は、
そのような【~access可否を決定するための】利用を援助するため，`生成元$の概念を定義する。
後続な下位節は、［
`peer^en【相手の`端点$】が，生成元を表現する権限を有する
］ことを確立する方法を説明する。
◎
Section 4.3.1 defines the concept of an origin as an aid to such uses, and the subsequent subsections explain how to establish that a peer has the authority to represent an origin.
</p>

<p>
権限の確立-法に関係する~securityの考慮点は、
`17.1§ を見よ。
◎
See Section 17.1 for security considerations related to establishing authority.
</p>

			<section id="origin">
<h4 title="URI Origin">4.3.1. ~URI生成元</h4>

<p>
所与の~URI用の
`生成元@
（ `origin^en ）は、
その ( `~scheme$, `~host$, `~port$ ) が成す組である
— ［
`~scheme$, `~host$
］は小文字に正規化して，
`~port$は頭部にある `0^c を除去して正規化した後の。
`~port$が~URIから省かれている場合、
その`~scheme$用の既定の~portが利用される。
◎
The "origin" for a given URI is the triple of scheme, host, and port after normalizing the scheme and host to lowercase and normalizing the port to remove any leading zeros. If port is elided from the URI, the default port for that scheme is used.＼
</p>

<p class="example">
例えば，~URI
`https://Example.Com/happy.js^c
用の生成元は
( "`https^c", "`example.com^c", "`443^c" )
が成す組になり、
`~port$が常に在るよう正規化された~URI接頭辞
`https://example.com:443^c
としても記述できる。
◎
For example, the URI
• https://Example.Com/happy.js
◎
would have the origin
• { "https", "example.com", "443" }
◎
which can also be described as the normalized URI prefix with port always present:
• https://example.com:443
</p>

<p>
各~生成元は、
自前の名前空間を定義し，
その名前空間に属する識別子たちが各`資源$へどう対応付けられるかを制御する。
それは、［
妥当な要請に対し、
当の生成元【に対し権限的な`生成元~server$】が，どう
— 時間~越しに一貫して —
応答するか
］が［
利用者が~URIに結付けることになる意味論
］を決定することに転じる
— それらの意味論の有用さは、［
未来に参照して~accessする利用者
］のために［
これらの仕組みを最終的に資源へ変形する【？】
］ことにある。
◎
Each origin defines its own namespace and controls how identifiers within that namespace are mapped to resources. In turn, how the origin responds to valid requests, consistently over time, determines the semantics that users will associate with a URI, and the usefulness of those semantics is what ultimately transforms these mechanisms into a resource for users to reference and access in the future.
</p>

<p>
2 つの生成元は、［
`~scheme$, `~host$, `~port$
］いずれかが相違するならば別個とされる。
これら 2 つの生成元を同じ実体が制御することを検証yできたとしても、
それらの生成元の下にある 2 つの名前空間は
— 一方の生成元が、
それに対し権限的な~serverにより，明示的に他方の別名にされない限り —
別個になる。
◎
Two origins are distinct if they differ in scheme, host, or port. Even when it can be verified that the same entity controls two distinct origins, the two namespaces under those origins are distinct unless explicitly aliased by a server authoritative for that origin.
</p>

<p>
`RFC6454$r にて述べられたとおり、
生成元は，この文書の視野を超える［
~HTMLや それに関係する~Web~protocol
］の中でも利用される。
【参照：`~HTMLが定義する生成元＠~ORIGIN#origin$】
◎
Origin is also used within HTML and related Web protocols, beyond the scope of this document, as described in [RFC6454].
</p>

			</section>
			<section id="http.origin">
<h4 title="http Origins">4.3.2. `http^c 生成元</h4>

<p>
~HTTPは，~transport~protocolには依存しないが、
"`http$c" `~scheme$は，次に関して~TCPに特有である
— `authority$p （ “権限” ）成分の中で識別される `host$p が何であれ、
権限を［［［
`host$p にて指示された~host
］の［
`port$p にて指示された~port
］上で~TCP接続を~listenしている`生成元~server$
］を制御する何者か
］に結付けることに関して。
これは，［
`~client$に特有な名前~解決の仕組み
］にも［
経路上の攻撃者に対し~secure化されないかもしれない通信
］にも依存するので、
ごく弱いイミの権限である。
そうであっても、［
"`http$c" 識別子たちを，ある`生成元~server$に束縛すること
］は，少なくとも［
信用-済みな環境の中で，解決が一貫する
］ためには足るものになる。
◎
Although HTTP is independent of the transport protocol, the "http" scheme (Section 4.2.1) is specific to associating authority with whomever controls the origin server listening for TCP connections on the indicated port of whatever host is identified within the authority component. This is a very weak sense of authority because it depends on both client-specific name resolution mechanisms and communication that might not be secured from an on-path attacker. Nevertheless, it is a sufficient minimum for binding "http" identifiers to an origin server for consistent resolution within a trusted environment.
</p>

<p>
`host$p 識別子が~IP~addressとして供された場合、［
その~IP~addressが指示する~TCP~port
］上の~listenerが（もし在れば），`生成元~server$になる。
`host$p 識別子が登録-済みな~host名である場合、
その名前が，［
適切な`生成元~server$用の~address
］を見出すための間接的な識別子として［
~DNSなどの名前~解決~service
］で利用される。
◎
If the host identifier is provided as an IP address, the origin server is the listener (if any) on the indicated TCP port at that IP address. If host is a registered name, the registered name is an indirect identifier for use with a name resolution service, such as DNS, to find an address for an appropriate origin server.
</p>

<p>
`~client$は、
"`http$c" `~scheme$を伴う~URIが［
指示された`資源$への~accessを~callする文脈
］の下で利用されたときは，
次により当の資源へ~accessしようと試みてもヨイ：
◎
When an "http" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by＼
</p>
<ol>
	<li>
~URIの `host$p 識別子を~IP~addressに解決する
◎
resolving the host identifier to an IP address,＼
</li>
	<li>
［
結果の~addressへの~TCP接続
］を［
~URIにて指示された`~port$
］上に確立する
◎
establishing a TCP connection to that address on the indicated port, and＼
</li>
	<li>
接続~越しに，［
次を包含している~HTTP`要請~message$
］を`~server$へ送信する
⇒
［
【当の~URIから得られた】
`~client$の`~target~URI$
］に合致する`要請~target$
◎
sending over that connection an HTTP request message containing a request target that matches the client's target URI (Section 7.1).
</li>
</ol>

<p>
［
`~client$からの そのような要請
］に対する［
`~server$からの`最終-応答$
］は、
【！非-非最終-（ `1xx$st ）~HTTP応答~messageで応答したなら、その応答は】
当の要請に対する`権限的$な回答と見なされる。
◎
If the server responds to such a request with a non-interim HTTP response message, as described in Section 15, then that response is considered an authoritative answer to the client's request.
</p>

<p>
しかしながら，上述は、［
`権限的な応答$を得するための唯一の手段
］でも［
`権限的な応答$は常に必要yなことを含意するもの
］でもないことに注意（ `CACHING$r を見よ）。
例えば， `Alt-Svc^h ~header `ALTSVC$r は、
`生成元~server$が［
他の~serviceのうち，当の`生成元$用にも権限的になるもの
］を識別することを許容する。
"`http$c" で識別される`資源$への~accessは、
この文書の視野の外側にある~protocolにより供されるかもしれない。
◎
Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see [CACHING]). For example, the Alt-Svc header field [ALTSVC] allows an origin server to identify other services that are also authoritative for that origin. Access to "http" identified resources might also be provided by protocols outside the scope of this document.
</p>

			</section>
			<section id="https.origin">
<h4 title="https Origins">4.3.3. `https^c 生成元</h4>

<p>
`https$c ~schemeは、
権限を証明書に結付ける
— ［
証明書に対応している秘密鍵を利用する~serverの能
］に基づいて，`~client$が［
【当の~URIにより】識別された`生成元~server$
］用に信用に価するものと見なす証明書に。
~clientは、［
当の証明書が信用に価するか否か
］を判断するとき，通例的に［
何らかの信用-~anchor
— 予め手配したか環境設定されたそれ —
から伝達される信用の連鎖
］に依拠する（`4.3.4§）。
◎
The "https" scheme (Section 4.2.2) associates authority based on the ability of a server to use the private key corresponding to a certificate that the client considers to be trustworthy for the identified origin server. The client usually relies upon a chain of trust, conveyed from some prearranged or configured trust anchor, to deem a certificate trustworthy (Section 4.3.4).
</p>

<p>
~HTTP11までは、［
ある接続~越しに`~server$と通信している`~client$
］が~serverに権限を帰属させるのは，当の接続が［
特定的に，当の~URI生成元の~host
］へ［
成功裡に確立され, `~secure化$されている
］ときに限られる。
接続の確立と証明書の検証yは、
権限の証明として利用される。
◎
In HTTP/1.1 and earlier, a client will only attribute authority to a server when they are communicating over a successfully established and secured connection specifically to that URI origin's host. The connection establishment and certificate verification are used as proof of authority.
</p>

<p>
［
~HTTP2／~HTTP3
］においては、
`~client$が`~server$に権限を帰属させるのは、［
成功裡に確立され, `~secure化$された接続
］越しに通信していて，［
当の~URIの`生成元$の~hostは、
~serverの証明書~内に在る いずれかの~hostに合致する
］かつ［
~clientは、
当の~URIへ向けて，合致した~hostへの接続を~openできると予見する
］場合になる。
実施においては、
~clientは，［
`生成元$の~hostが、
確立した接続と同じ~server~IP~addressを包含する
］か検査するために，~DNS~queryを為すことになる。
この制約は、
`生成元~server$が等価な
`ORIGIN^i ~frame `RFC8336$r
を送信している場合は，除去し得る。
◎
In HTTP/2 and HTTP/3, a client will attribute authority to a server when they are communicating over a successfully established and secured connection if the URI origin's host matches any of the hosts present in the server's certificate and the client believes that it could open a connection to that host for that URI. In practice, a client will make a DNS query to check that the origin's host contains the same server IP address as the established connection. This restriction can be removed by the origin server sending an equivalent ORIGIN frame [RFC8336].
</p>

<p>
`要請~target$の［
`~host$, `~port$
］値は、
各~HTTP要請の中に渡され，`生成元$を［
同じ~serverが制御しているかもしれない他の名前空間に属するもの
］と判別するよう識別することになる（ `7.2§ ）。
［
証明書の秘密鍵に対する制御も伴って供される
］ような どの~serviceも，［
対応する "`https$c" 名前空間を管理することに等しく責を負う
］, あるいは少なくとも［
誤って~directされるように出現した要請（ `7.4§ ）を却下するよう準備しておく
］ことを確保するのは、
`生成元~server$【！生成元】の責務である。
◎
The request target's host and port value are passed within each HTTP request, identifying the origin and distinguishing it from other namespaces that might be controlled by the same server (Section 7.2). It is the origin's responsibility to ensure that any services provided with control over its certificate's private key are equally responsible for managing the corresponding "https" namespaces or at least prepared to reject requests that appear to have been misdirected (Section 7.4).
</p>

<p>
`生成元~server$は，
ある種の`~target~URI$への要請に対しては、
それを処理する権限を有していても，
それを処理する用意はないかもしれない。
例えば，ある~hostが［
複数の`~port$（例： 443 と 8000 ）上で別個な~serviceを運用する
］とき、［
当の生成元~serverにて，`~target~URI$を検査する
］ことが必要yである
（接続が`~secure化$された後であっても）
— ~network攻撃者は、
ある~port用の接続を他の何らかの~portにて受信させようとするかもしれないので。
`~target~URI$を検査するのに失敗した場合、
そのような攻撃者に［
一方の`~target~URI$
（例： "`https://example.com/foo^c" ）
に対する応答を他方の~port
（例： "`https://example.com:8000/foo^c" ）
からの`権限的$にも見える応答で置換すること
］を許容するかもしれない。
◎
An origin server might be unwilling to process requests for certain target URIs even when they have the authority to do so. For example, when a host operates distinct services on different ports (e.g., 443 and 8000), checking the target URI at the origin server is necessary (even after the connection has been secured) because a network attacker might cause connections for one port to be received at some other port. Failing to check the target URI might allow such an attacker to replace a response to one target URI (e.g., "https://example.com/foo") with a seemingly authoritative response from the other port (e.g., "https://example.com:8000/foo").
</p>

<p>
"`https$c" `~scheme$は、
権限を結付けるときに，［
~TCP, 接続される~port番号
］どちらにも依拠しないことに注意
— どちらも、
~secure化された通信の外側にあり，権威あるものとして信用できないので。
よって，~HTTP通信は、
`~secure化$【！Section 4.2.2】された どの~channel越しにも
— ~TCPを利用しない~protocolも含めて【例：~HTTP3は~QUICを利用する】 —
場を占めるかもしれない。
◎
Note that the "https" scheme does not rely on TCP and the connected port number for associating authority, since both are outside the secured communication and thus cannot be trusted as definitive. Hence, the HTTP communication might take place over any channel that has been secured, as defined in Section 4.2.2, including protocols that don't use TCP.
</p>

<p>
`~client$は、
"`https$c" `~scheme$を伴う~URIが［
指示された`資源$への~accessを~callする文脈
］の下で利用されたときは，
次により~accessしようと試みてもヨイ：
◎
When an "https" URI is used within a context that calls for access to the indicated resource, a client MAY attempt access by＼
</p>
<ol>
	<li>
~URIの `host$p 識別子を~IP~addressに解決する
◎
resolving the host identifier to an IP address,＼
</li>
	<li>
［
結果の~addressへの~TCP接続
］を［
~URIにて指示された`~port$
］上に確立する
◎
establishing a TCP connection to that address on the indicated port,＼
</li>
	<li>
`端点間$の接続を`~secure化$する
— ~TCP越しに~TLSを成功裡に起動することにより，機密性と完全性が保護されるよう
◎
securing the connection end-to-end by successfully initiating TLS over TCP with confidentiality and integrity protection, and＼
</li>
	<li>
接続~越しに，［
次を包含している~HTTP`要請~message$
］を`~server$へ送信する
⇒
［
【当の~URIから得られた】
`~client$の`~target~URI$
］に合致する`要請~target$
◎
sending over that connection an HTTP request message containing a request target that matches the client's target URI (Section 7.1).
</li>
</ol>

<p>
［
`~client$からの そのような要請
］に対する［
`~server$からの`最終-応答$
］は、
【！非-非最終-（ `1xx$st ）~HTTP応答~messageで応答したなら、その応答は】
当の要請に対する`権限的$な回答と見なされる。
◎
If the server responds to such a request with a non-interim HTTP response message, as described in Section 15, then that response is considered an authoritative answer to the client's request.
</p>

<p>
しかしながら，上述は、［
`権限的な応答$を得するための唯一の手段
］でも［
`権限的な応答$は常に必要yなことを含意するもの
］でもないことに注意（ `CACHING$r を見よ）。
◎
Note, however, that the above is not the only means for obtaining an authoritative response, nor does it imply that an authoritative response is always necessary (see [CACHING]).
</p>

			</section>
			<section id="https.verify">
<h4 title="https Certificate Verification">4.3.4. `https^c 証明書の検証y</h4>

<p>
`~secure化$された接続を確立して`~URI参照$を解く（ `dereference^en する）ためには、
`~client$は，［
当の~serviceの識別情報（ `identity^en ）は、
~URIの`生成元~server$に合致するものとして受容-可能かどうか
］を検証yしなければナラナイ。
証明書の検証yは、［
経路上の攻撃者／名前~解決を制御する攻撃者
］が~serverになりすますのを防止するために利用される。
この処理nには、
~clientが信用-~anchorたちが成す集合で環境設定されることが要求される。
◎
To establish a secured connection to dereference a URI, a client MUST verify that the service's identity is an acceptable match for the URI's origin server. Certificate verification is used to prevent server impersonation by an on-path attacker or by an attacker that controls name resolution. This process requires that a client be configured with a set of trust anchors.
</p>

<p>
一般に，`~client$は、
`6125/6$rfc に定義される検証y処理nを利用して，
~serviceの識別情報を検証yしなければナラナイ。
~clientは、
参照~識別情報を当の~serviceの `host$p から構築しなければナラナイ。
`host$p が~literalな~IP~address（ `4.3.5§ ）である場合、
参照~識別情報は~IP-IDになる
— 他の場合、
`host$p は名前であり，参照~識別情報は~DNS-IDになる。
◎
In general, a client MUST verify the service identity using the verification process defined in Section 6 of [RFC6125]. The client MUST construct a reference identity from the service's host: if the host is a literal IP address (Section 4.3.5), the reference identity is an IP-ID, otherwise the host is a name and the reference identity is a DNS-ID.
</p>

<p>
`~client$は、
~CN-ID型の参照~識別情報を利用してはナラナイ。
`6125/6.2.1$rfc に注記されるとおり、
旧い~clientは，そのような参照~識別情報を利用しているかもしれない。
◎
A reference identity of type CN-ID MUST NOT be used by clients. As noted in Section 6.2.1 of [RFC6125], a reference identity of type CN-ID might be used by older clients.
</p>

<p>
`~client$は、［
代替な形による~server識別情報
］の検証yを受容するよう，特別に環境設定されているかもしれない。
例えば，~clientは、
当の~serviceは
— `~target~URI$の`生成元$に合致するものではなく —
~serviceに特有な証明書
（あるいは、
何らかの外部で定義される参照~識別情報に合致している証明書）
を呈示するものと期待する下で，［
~address, ~hostname
］とも動的な~serverへ接続しているかもしれない。
◎
A client might be specially configured to accept an alternative form of server identity verification. For example, a client might be connecting to a server whose address and hostname are dynamic, with an expectation that the service will present a specific certificate (or a certificate matching some externally defined reference identity) rather than one matching the target URI's origin.
</p>

<p>
特殊な事例では，［
~serverの識別情報を単純に無視することが，~clientにとって適切になり得る
］が、
これは，［
接続を能動的な攻撃に対し~~無防備にする
］ものと解されなければならない。
◎
In special cases, it might be appropriate for a client to simply ignore the server's identity, but it must be understood that this leaves a connection open to active attack.
</p>

<p>
証明書が~URIの`生成元$用として妥当でない場合、
`~UA$は，続行する前に利用者から確認を得するか（ `3.5§ を見よ），
不良~証明書~errorで接続を終了しなければナラナイ。
自動化された`~client$は、
（可用なら）適切な監査~logに~errorを~logしなければナラナイ
— 加えて、
接続を（不良~証明書~errorで）終了するベキである。
自動化された~clientは、
この検査を不能化する環境設定を供してもヨイが，
それを可能化する設定も供さなければナラナイ。
◎
If the certificate is not valid for the target URI's origin, a user agent MUST either obtain confirmation from the user before proceeding (see Section 3.5) or terminate the connection with a bad certificate error. Automated clients MUST log the error to an appropriate audit log (if available) and SHOULD terminate the connection (with a bad certificate error). Automated clients MAY provide a configuration setting that disables this check, but MUST provide a setting which enables it.
</p>

			</section>
			<section id="https.ip-id">
<h4 title="IP-ID Reference Identity">4.3.5. ~IP-ID参照~識別情報</h4>

<p>
"`https$c" ~URIの `host$p ~field内に~literalな~IP~addressを利用して識別される~serverに対しては、
その参照~識別情報は，~IP-ID型になる。
~IP~version 4 ~addressは，
`IPv4address^p ~ABNF規則を利用する一方で、
~IP~version 6 ~addressは，
`IPv6address^p ~optionを伴う `IP-literal^p 生成規則を利用する
— `URI$r `3.2.2§uri を見よ。
~IP-ID型の参照~識別情報は、
復号された~byte列による~IP~addressを包含する。
◎
A server that is identified using an IP address literal in the "host" field of an "https" URI has a reference identity of type IP-ID. An IP version 4 address uses the "IPv4address" ABNF rule, and an IP version 6 address uses the "IP-literal" production with the "IPv6address" option; see Section 3.2.2 of [URI]. A reference identity of IP-ID contains the decoded bytes of the IP address.
</p>

<p>
~IP~version 4 ~addressは 4 個の~octetからなり、
~IP~version 6 ~addressは 16 個の~octetからなる。
他の~IP~version用には、
~IP-IDの利用は定義されない。
証明書の `subjectAltName^p 拡張における `iPAddress^p の選択は，
~IP~versionを明示的に含まないので、
当の~addressの長さに依拠して~versionを判別する
— `5280/4.2.1.6$rfc を見よ。
◎
An IP version 4 address is 4 octets, and an IP version 6 address is 16 octets. Use of IP-ID is not defined for any other IP version. The iPAddress choice in the certificate subjectAltName extension does not explicitly include the IP version and so relies on the length of the address to distinguish versions; see Section 4.2.1.6 of [RFC5280].
</p>

<p>
~IP-ID型の参照~識別情報は、
次が満たされるならば合致する
⇒
当の~addressは証明書の `subjectAltName^p 拡張における `iPAddress^p 値に一致している
◎
A reference identity of type IP-ID matches if the address is identical to an iPAddress value of the subjectAltName extension of the certificate.
</p>

			</section>
		</section>
	</section>
	<section id="fields">
<h2 title="Fields">5. ~field</h2>

<p>
~HTTPは、
`~field@
（ `HTTP field^en ／ 略して `field^en ）を利用して，~dataを供する
— ［
名前空間に登録-済みな名前, 値
］が成す~pair【すなわち，`~field行l$】たちが成す拡張-可能な形で。
各~fieldは、
~messageの［
`~header節$／`~trailer節$
］の中に送信され，受信される（ `6§ ）。
◎
HTTP uses "fields" to provide data in the form of extensible name/value pairs with a registered key namespace. Fields are sent and received within the header and trailer sections of messages (Section 6).
</p>

<p class="trans-note">【
`~field$は、［
`~header$／`~trailer$
］の総称になる。
】</p>

		<section id="fields.names">
<h3 title="Field Names">5.1. ~field名</h3>

<p>
`~field名@
（ `field-name$p ）は、［
対応する`~field値$は，その名前により定義される意味論を有する
］ものと~labelする。
例えば， `Date$h ~headerは、［
それが出現する~messageの，出生時の時刻印
］を包含しているものと定義される。
◎
A field name labels the corresponding field value as having the semantics defined by that name. For example, the Date header field is defined in Section 6.6.1 as containing the origination timestamp for the message in which it appears.
</p>

<pre class="bnf">
`field-name@p
	= `token$p
</pre>

<p>
`~field名$は文字大小無視であり、
`~HTTP~field名~registry$cite
の中に登録される~OUGHT。
`16.3.1§ を見よ。
◎
Field names are case-insensitive and ought to be registered within the "Hypertext Transfer Protocol (HTTP) Field Name Registry"; see Section 16.3.1.
</p>

<p class="trans-note">【
参考：［
~HTTP2, ~HTTP3
］においては、
`~field名$は，送信する前に小文字~化される。
】</p>

<p>
`~field$の解釈は、［
同じ~HTTP`~major~version$の下での，`~minor~version$どうし
］では，変化しない
— そのような~fieldが無い下では、
`受信者$の既定の挙動は，変化し得るが。
他が指定されない限り、
~fieldは，すべての~versionの~HTTP用に定義される。
特に，［
`Host$h ／ `Connection$h
］~fieldは、
~HTTP11への適合性を広告するかどうかに関わらず，
すべての~HTTP実装から認識される~OUGHT。
◎
The interpretation of a field does not change between minor versions of the same major HTTP version, though the default behavior of a recipient in the absence of such a field can change. Unless specified otherwise, fields are defined for all versions of HTTP. In particular, the Host and Connection fields ought to be recognized by all HTTP implementations whether or not they advertise conformance with HTTP/1.1.
</p>

<p>
新たな`~field$を、
`~protocol~version$を変更することなく，導入できる
— ［
それに定義される意味論
］において，［
それを認識しない`受信者$が，それを安全に無視する
］ことが許容されるならば。
`16.3§ を見よ。
◎
New fields can be introduced without changing the protocol version if their defined semantics allow them to be safely ignored by recipients that do not recognize them; see Section 16.3.
</p>

<div class="p">
<p>
`~proxy$は、
自身が認識しない各`~header$を回送しなければナラナイ
— 次のいずれかの場合を除いて：
◎
A proxy MUST forward unrecognized header fields unless＼
</p>
<ul>
	<li>
その`~field名$は、
`Connection$h ~headerに~listされている。
◎
the field name is listed in the Connection header field (Section 7.6.1) or＼
</li>
	<li>
~proxy自身が、
そのような`~field$を［
阻止する, あるいは`形式変換-$する
］ように，特定的に環境設定されている。
◎
the proxy is specifically configured to block, or otherwise transform, such fields.＼
</li>
</ul>

<p>
他の`受信者$は、
自身が認識しない各［
`~header$／`~trailer$
］を無視するベキである。
◎
Other recipients SHOULD ignore unrecognized header and trailer fields.＼
</p>

<p>
これらの要件を固守することにより、
配備-済みな`媒介者$を更新したり除去することなく，
~HTTPの機能性を拡張できるようになる。
◎
Adhering to these requirements allows HTTP's functionality to be extended without updating or removing deployed intermediaries.
</p>
</div>

		</section>
		<section id="field.lines">
<h3 title="Field Lines and Combined Field Value">5.2. ~field行lと結合-済みな~field値</h3>

<p>
各
`~field節@
（ `field section^en, 略して `section^en ）は、
任意個数の
`~field行l@
（ `field line^en ）から構成される。
各`~field行l$は、
当の`~field$を識別する
<dfn>`~field名$</dfn>
（ `field name^en ）, および
当の`~field$の その~instance用の~dataを伝達する
`~field行l値@
（ `field line value^en ）を伴う。
◎
Field sections are composed of any number of "field lines", each with a "field name" (see Section 5.1) identifying the field, and a "field line value" that conveys data for that instance of the field.
</p>

<p class="trans-note">【
`~field節$は、［
`~header節$／`~trailer節$
］の総称になる。
】</p>

<p>
所与の`~field名$に対しては、
各`~field節$ごとに，その名前の~field用の`結合-$済みな
`~field値@
（ `field value^en ）が定義される。
それは、［
`~field節$内に在る`~field行l$のうち，その`~field名$を伴うもの
］すべての`~field行l値$を，~commaで分離して順に連結した結果になる。
◎
When a field name is only present once in a section, the combined "field value" for that field consists of the corresponding field line value. When a field name is repeated within a section, its combined field value consists of the list of corresponding field line values within that section, concatenated in order, with each field line value separated by a comma.
</p>

<div class="example">
<p>
例えば，次の`~field節$は：
◎
For example, this section:
</p>

<pre class="lang-http">
Example-Field: Foo, Bar
Example-Field: Baz
</pre>

<p>
2 個の`~field行l$を包含する。
どちらも`~field名$は "`Example-Field^c" になる。
`~field行l値$は、［
1 個目は "`Foo, Bar^c",
2 個目は "`Baz^c"
］になる。
`Example-Field^h 用の`~field値$は、
~list "`Foo, Bar, Baz^c" になる。
◎
contains two field lines, both with the field name "Example-Field". The first field line has a field line value of "Foo, Bar", while the second field line value is "Baz". The field value for "Example-Field" is the list "Foo, Bar, Baz".
</p>
</div>

		</section>
		<section id="fields.order">
<h3 title="Field Order">5.3. ~fieldの順序</h3>

<p>
`受信者$は、
~messageの意味論を変更することなく，同じ`~field節$の中の［
同じ`~field名$を伴う複数個の`~field行l$
］を 1 個の`~field行l$に
`結合-@
（ `combine^en ）してもヨイ
— それらのうち［
最初の`~field行l$の`~field値$
］に，後続な各`~field行l値$を［
現れた順に、［
1 個の~commaと その前後の省略可能な空白（ `OWS$p ）
］で分離した上で，付加する
］ことにより。
一貫性を得るためには、［
~comma, `SP$P
］並びを利用すること。
◎
A recipient MAY combine multiple field lines within a field section that have the same field name into one field line, without changing the semantics of the message, by appending each subsequent field line value to the initial field line value in order, separated by a comma (",") and optional whitespace (OWS, defined in Section 5.6.3). For consistency, use comma SP.
</p>

<p>
したがって、［
同じ`~field名$を伴う複数個の`~field行l$
］が受信される順序は，［
結合された`~field値$の解釈
］において有意になる —
`~proxy$は、
~messageを回送するときに，これらの`~field行l値$の順序を変更してはナラナイ。
◎
The order in which field lines with the same name are received is therefore significant to the interpretation of the field value; a proxy MUST NOT change the order of these field line values when forwarding a message.
</p>

<p>
すなわち、
周知な例外（下に注記される）は別として，および［
当の~fieldの定義にて，（同じ`~field節$内にある）［
同じ`~field名$を伴う複数個の`~field行l$を`結合-$し直す
］ことが許容されている場合
（すなわち、
当の`~field値$の定義を成す ある構文-代替が
— ~ABNF規則 <code>#(`values^p)</code> などとして —
~commaで分離された~list（ `5.6.1§ ）を許容している場合）
］を除き、
`送信者$は，同じ~message【`~field節$】内に
⇒＃
同じ`~field名$を伴う複数個の`~field行l$を`生成-$してはナラナイ／
すでに存在する`~field行l$と同じ`~field名$を伴う`~field行l$を付加してはナラナイ
◎
This means that, aside from the well-known exception noted below, a sender MUST NOT generate multiple field lines with the same name in a message (whether in the headers or trailers) or append a field line when a field line of the same name already exists in the message, unless that field's definition allows multiple field line values to be recombined as a comma-separated list (i.e., at least one alternative of the field's definition allows a comma-separated list, such as an ABNF rule of #(values) defined in Section 5.6.1).
</p>

<p class="trans-note">【
~messageを回送するときなど，~field行lを生成しない場合の取扱いは
— 同じ~field名を伴う~field行lが複数個あっても —
この要件から外されているが、
それらのうちいずれかの`~field行l値$を改変する動作は，
当の~field行lを生成した（または除去してから付加し直した）ものと見なされ，
この要件の対象にされよう。
】</p>

<p class="note">注記：
`Set-Cookie^h ~header `COOKIE$r は，~list構文を利用せず、
実施においては，同じ`応答~message$内に複数個の`~field行l$にわたって出現することが多い。
すなわち，［
同じ`~field名$を伴う複数個の`~field行l$に課される，上の要件
］に違反している。
それは， 1 個の `~field値$に結合できないので、
`受信者$は，~fieldたちを処理する際に
`Set-Cookie$h を特別~事例として取扱う~OUGHT
（詳細は `Kri2001$r
`付録 A.2.3＠http://arxiv.org/abs/cs.SE/0105018#appendix-A.2.3$
を見よ）。
◎
Note: In practice, the "Set-Cookie" header field ([COOKIE]) often appears in a response message across multiple field lines and does not use the list syntax, violating the above requirements on multiple field lines with the same field name. Since it cannot be combined into a single field value, recipients ought to handle "Set-Cookie" as a special case while processing fields. (See Appendix A.2.3 of [Kri2001] for details.)
</p>

<p>
`~field節$内で`~field行l$が受信される順序は、
`~field名$が相違するものどうしでは，有意でない。
しかしながら、［
要請における `Host$h, 応答における `Date$h などの，追加的な制御~dataを包含する~header
］を最初に送信することは，良い実施とされる
— 実装は、
より早く，~messageを取扱うかどうか裁定できるようになるので。
◎
The order in which field lines with differing field names are received in a section is not significant. However, it is good practice to send header fields that contain additional control data first, such as Host on requests and Date on responses, so that implementations can decide when not to handle a message as early as possible.
</p>

<p>
`~server$は、
要請の`~header節$全体を受信するまでは，
要請をその`~target資源$に適用してはナラナイ
— 後に続く~header`~field行l$は、
要請~処理に影響iするような［
`条件付き要請$ ／
認証~用の`資格証$ ／
故意に誤誘導するように重複された~header
］を内包することもあるので。
◎
A server MUST NOT apply a request to the target resource until it receives the entire request header section, since later header field lines might include conditionals, authentication credentials, or deliberately misleading duplicate header fields that could impact request processing.
</p>

		</section>
		<section id="fields.limits">
<h3 title="Field Limits">5.4. ~fieldの長さ制限s</h3>

<p>
`適合性§にて述べたとおり、
~HTTPは、
各［
`~field行l$／
`~field値$／
一体としての`~header節$／
一体としての`~trailer節$
］の長さに，定義済みな制限-を設置しない。
実施においては、
個々の長さには，［
特定の~fieldの意味論に依存して、
様々な場当的な制限が見出される
］ことも多い。
◎
HTTP does not place a predefined limit on the length of each field line, field value, or on the length of a header or trailer section as a whole, as described in Section 2. Various ad hoc limitations on individual lengths are found in practice, often depending on the specific field's semantics.
</p>

<p>
`~server$は、
要請にて受信した~header［
`~field行l$／`~field値$／`~field$たちが成す集合
］が［
自身が望んで処理する大きさ
］を超える場合には，［
適切な `4xx$st 状態s~code
］で応答しなければナラナイ。
そのような~headerを【代わりに】無視することは、
`要請~密入~攻撃$ `HTTP/1.1$r に対する~serverの脆弱性を高めることになる。
◎
A server that receives a request header field line, field value, or set of fields larger than it wishes to process MUST respond with an appropriate 4xx (Client Error) status code. Ignoring such header fields would increase the server's vulnerability to request smuggling attacks (Section 11.2 of [HTTP/1.1]).
</p>

<p>
`~client$は、
応答にて受信した
`~field行l$のうち［
自身が望んで処理する大きさ
］を超えるものに対しては、
その`~field$の意味論にて［
その値（たち）が落とされても，［
~message~frame法や, 応答の意味論
］を変更することなく安全に無視できる
］ならば，それらを破棄するか, 切落して†もヨイ。
◎
A client MAY discard or truncate received field lines that are larger than the client wishes to process if the field semantics are such that the dropped value(s) can be safely ignored without changing the message framing or response semantics.
</p>

<p class="trans-note">【†
`~listに基づく~field$の場合に，一部の~memberを破棄することに思われるが、
不可分な~protocol要素（例： `comment$p ）の一部を破棄することも含まれるかもしれない。
】</p>

		</section>
		<section id="fields.values">
<h3 title="Field Values">5.5. ~field値</h3>

<p>
~HTTP`~field値$は、
当の`~field$の文法により定義される形式による一連の文字からなる。
各~fieldの文法は、
通例的に~ABNF `RFC5234$r を利用して定義される。
◎
HTTP field values consist of a sequence of characters in a format defined by the field's grammar. Each field's grammar is usually defined using ABNF ([RFC5234]).
</p>

<pre class="bnf">
`field-value@p
	= *`field-content$p
`field-content@p
	= `field-vchar$p
	  [ 1*( `SP$P / `HTAB$P / `field-vchar$p ) `field-vchar$p ]
`field-vchar@p
	= `VCHAR$P / `obs-text$p
`obs-text@p
	= `80-FF^X
</pre>

<p>
`~field値$は、［
頭部／尾部
］に`空白$を内包しない。
~HTTPの特定の~versionにおいて，
そのような空白が~message内に出現することが許容されるときは、
~fieldを構文解析する実装は，
当の~field値を評価するに先立ってそのような空白を除外しなければナラナイ。
◎
A field value does not include leading or trailing whitespace. When a specific version of HTTP allows such whitespace to appear in a message, a field parsing implementation MUST exclude such whitespace prior to evaluating the field value.
</p>

<p>
`~field値$は、
通例的に，~US-ASCII文字 `USASCII$r の範囲に拘束される。
より広~範囲な文字を必要とする`~field$は、
符号化法
— `RFC8187$r にて定義されるものなど —
を利用できる。
歴史的に、
~HTTPが `field-content$p 【！field content】に許容していたのは，
ISO-8859-1 ~charset `ISO-8859-1$r
による~textであり、
他の~charsetの~supportは，
`RFC2047$r 符号化法の利用を通してのみ許容してきた。
新たに定義される`~field$用の仕様は、
その`~field値$を［
`VCHAR$P（可視な~US-ASCII~octet）, `SP$P, `HTAB$P
］に制限するベキである。
`受信者$は、
`field-content$p 【！field content】内で許容される他の~octet（すなわち `obs-text$p ）を不透明な~dataとして扱うベキである。
◎
Field values are usually constrained to the range of US-ASCII characters [USASCII]. Fields needing a greater range of characters can use an encoding, such as the one defined in [RFC8187]. Historically, HTTP allowed field content with text in the ISO-8859-1 charset [ISO-8859-1], supporting other charsets only through use of [RFC2047] encoding. Specifications for newly defined fields SHOULD limit their values to visible US-ASCII octets (VCHAR), SP, and HTAB. A recipient SHOULD treat other allowed octets in field content (i.e., obs-text) as opaque data.
</p>

<p>
［
`CR$P ／ `LF$P ／ `NUL^P
］文字を包含している`~field値$は、
妥当でない
— 加えて、［
それらの文字を構文解析して解釈する仕方は、
実装に応じて変わるかもしれない
］ことに因り，危険でもある。
そのような~field値の`受信者$は、
当の~messageを却下するか，~messageを［
処理する／回送する
］前に~field値の中にある各［
`CR^P ／ `LF^P ／ `NUL^P
］を `SP$P に置換しなければナラナイ。
他の `CTL$P 文字を包含している`~field値$も，妥当でない
— しかしながら，`受信者$は、
堅牢性を得るためとして，
そのような文字が安全な文脈の中で出現したときは維持してもヨイ
（例：`下流$にある どの~HTTP構文解析器も処理しない，応用に特有な `quoted-string$p の中）。
◎
Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. Field values containing other CTL characters are also invalid; however, recipients MAY retain such characters for the sake of robustness when they appear within a safe context (e.g., an application-specific quoted string that will not be processed by any downstream HTTP parser).
</p>

<p>
`~field$のうち，その`~field値$として 1 個の~memberしか見越さないもの†を指して、
`単数~field@
（ `singleton field^en ）という。
◎
Fields that only anticipate a single member as the field value are referred to as "singleton fields".
</p>

<p class="trans-note">【†
見越さないとしても、
下に述べるように，`~field値$は
“~listに基づいている” かのように出現し得る。
】</p>

<p>
`~field$のうち，その`~field値$として複数個の~memberを許容するものを指して、
`~listに基づく~field@
（ `list-based field^en ）という。
複数個の~memberを包含し得る~field値を定義するための共通な記法として，
`5.6.1§ に与える~list演算子~拡張が利用される。
◎
Fields that allow multiple members as the field value are referred to as "list-based fields". The list operator extension of Section 5.6.1 is used as a common notation for defining field values that can contain multiple members.
</p>

<p>
~comma（ "`,^c" ）は、
~member間の区切子として利用されるので，
各~memberの中の~dataとして許容される場合には~careの下で扱う必要がある。
このことは、
~listに基づく~fieldのみならず，`単数~field$にも該当する
— `単数~field$は，誤って複数個の~memberを伴って送信されるかもしれず、
そのような~errorを検出することで相互運用能は改善されるので。
`HTTP-date$p や `URI-reference$p 要素の中など，［
~memberの中に~commaを包含する要素
］を期待する~fieldは、［
~list分離子が在ったとしても，要素の中の~commaと判別できる
］よう，当の要素の前後を【~comma以外の】区切子で括るように定義される~OUGHT。
◎
Because commas (",") are used as the delimiter between members, they need to be treated with care if they are allowed as data within a member. This is true for both list-based and singleton fields, since a singleton field might be erroneously sent with multiple members and detecting such errors improves interoperability. Fields that expect to contain a comma within a member, such as within an HTTP-date or URI-reference element, ought to be defined with delimiters around that element to distinguish any comma within that data from potential list separators.
</p>

<div class="example">
<p>
例えば，［
~textな日時／`~URI$
］（どちらも~commaを包含し得る）は、
次の様にすれば，`~listに基づく~field$の`~field値$内で安全に運べる:
◎
For example, a textual date and a URI (either of which might contain a comma) could be safely carried in list-based field values like these:
</p>

<pre class="lang-http">
Example-URIs: "http://example.com/a.html,foo", "http://without-a-comma.example.com/"
Example-Dates: "Sat, 04 May 1996", "Wed, 14 Sep 2005"
</pre>
</div>

<p>
区切子としての二重引用符（ `DQUOTE$P ）は、
ほぼ常に， `quoted-string$p 生成規則と伴に利用されることに注意
— 二重引用符の内側で他の構文を利用した場合、
不必要な混同の原因になる見込みが高くなる。
◎
Note that double-quote delimiters are almost always used with the quoted-string production (Section 5.6.4); using a different syntax inside double-quotes will likely cause unnecessary confusion.
</p>

<p>
多くの`~field$（ `Content-Type$h など）は、
`~parameter$用に共通な構文を利用する
— それは、
~parameter値（ `parameter-value$p ）用の構文に引用符［
無し（ `token$p ）と有り（ `quoted-string$p ）
］どちらも許容する。
共通な構文を利用すれば、
`受信者$は，既存の構文解析器を再利用できるようになる。
両~形とも許容するときは、
どちらの形で受信しようが，~parameter値の意味は同じになる~OUGHT。
◎
Many fields (such as Content-Type, defined in Section 8.3) use a common syntax for parameters that allows both unquoted (token) and quoted (quoted-string) syntax for a parameter value (Section 5.6.6). Use of common syntax allows recipients to reuse existing parser components. When allowing both forms, the meaning of a parameter value ought to be the same whether it was received as a token or a quoted string.
</p>

<p class="note">注記：
この仕様が`~field値$の構文を定義する所では、
当の~field名の後に有名~ABNF規則を利用して，当の`~field$の値
（下層の~message法~構文から抽出され，複数個の~instanceが~listに結合された後の値）
に許容される文法を定義する。
◎
Note: For defining field value syntax, this specification uses an ABNF rule named after the field name to define the allowed grammar for that field's value (after said value has been extracted from the underlying messaging syntax and multiple instances combined into a list).
</p>

		</section>
		<section id="fields.components">
<h3 title="Common Rules for Defining Field Values">5.6. ~field値を定義するための共通な規則</h3>

			<section id="abnf.extension">
<h4 title="Lists (#rule ABNF Extension)">5.6.1. ~list（ <code>#%規則</code> ~ABNF拡張）</h4>

<p>
一部の［
`~listに基づく~field$の`~field値$
］の定義を読み易くするため、
`RFC5234$r の~ABNF規則に対する拡張
<code>#%規則</code>
が利用される：
◎
A #rule extension to the ABNF rules of [RFC5234] is used to improve readability in the definitions of some list-based field values.
</p>

<p>
構成子 "`#^c" は、
"`*^c" と類似に定義され，
~commaで区切られた要素からなる~listを定義する。
全部的な形は，
<code>&lt;%n&gt;#&lt;%m&gt;`<var>element</var>^p</code>
であり、
%n 個以上 %m 個以下の `<var>element</var>^p
— ［
1 個の~comma （"`,^c"）と その前後の省略可能な空白（ `OWS$p ）
］で互いに分離された，それら —
を指示する。
◎
A construct "#" is defined, similar to "*", for defining comma-delimited lists of elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least &lt;n&gt; and at most &lt;m&gt; elements, each separated by a single comma (",") and optional whitespace (OWS, defined in Section 5.6.3).
</p>

				<section id="abnf.extension.sender">
<h5 title="Sender Requirements">5.6.1.1. 送信者に対する要件</h5>

<p>
`送信者$は、
~list構成子を利用するどの生成規則に対しても，
空な~list要素を`生成-$してはナラナイ。
言い換えれば、
送信者は，［
次の構文を満足する~list
］を`生成-$する必要がある：
◎
In any production that uses the list construct, a sender MUST NOT generate empty list elements. In other words, a sender has to generate lists that satisfy the following syntax:
</p>

<pre class="bnf">
1#%element =&gt; %element *( `OWS$p "," `OWS$p %element )
</pre>

<p>
および：
◎
and:
</p>

<pre class="bnf">
#%element =&gt; [ 1#%element ]
</pre>

<p>
%n &gt;= 1, %m &gt; 1 に対し：
◎
and for n &gt;= 1 and m &gt; 1:
</p>

<pre class="bnf">
&lt;%n&gt;#&lt;%m&gt;%element =&gt; %element &lt;%n-1&gt;*&lt;%m-1&gt;( `OWS$p "," `OWS$p %element )
</pre>

<p>
`A§ にて，送信者~用の［
~list構成子が展開された後の，総集的な~ABNF
］を示す。
◎
Appendix A shows the collected ABNF for senders after the list constructs have been expanded.
</p>

				</section>
				<section id="abnf.extension.recipient">
<h5 title="Recipient Requirements">5.6.1.2. 受信者に対する要件</h5>

<p>
空な要素は、
要素として数えられない。
`受信者$は，［
適度な数の空な~list要素
］を構文解析しつつ，それを超える分は無視しなければナラナイ
— ［
送信者が値を併合する際にやりがちな誤りを取扱うに十分
］かつ［
~DoS攻撃の仕組みとして利用し得るほど~~多量ではない
］ような。
言い換えれば、
受信者は，次の構文を満足する どの~listも受容しなければナラナイ：
◎
Empty elements do not contribute to the count of elements present. A recipient MUST parse and ignore a reasonable number of empty list elements: enough to handle common mistakes by senders that merge values, but not so much that they could be used as a denial-of-service mechanism. In other words, a recipient MUST accept lists that satisfy the following syntax:
</p>

<pre class="bnf">
#%element =&gt; [ %element ] *( `OWS$p "," `OWS$p [ %element ] )
</pre>

<p>
空な~list要素も在り得るので、
`RFC5234$r の~ABNFは，~listを成す要素の個数について施行できない。
そのため、
どの事例でも，個数は指定されていないかのように対応付けられる。
◎
Note that because of the potential presence of empty list elements, the RFC 5234 ABNF cannot enforce the cardinality of list elements, and consequently all cases are mapped as if there was no cardinality specified.
</p>

<div class="example">
<p>
例えば，次の~ABNF生成規則が与えられたとき：
◎
For example, given these ABNF productions:
</p>

<pre class="bnf">
`example-list@p
	= 1#`example-list-elmt$p
`example-list-elmt@p
	= `token$p【！4.4.1.1】
</pre>

<p>
次のいずれも、
`example-list$p に対する妥当な値になる
（二重引用符は内包しない
— それは、
区切りを示すためでしかない）：
◎
Then the following are valid values for example-list (not including the double quotes, which are present for delimitation only):
</p>

<pre>
"foo,bar"
"foo ,bar,"
"foo , ,bar,charlie"
</pre>

<p>
対照的に，次のいずれも，妥当でない値になる
— `example-list$p 生成規則には， 1 個~以上の空でない要素が要求されるので：
◎
In contrast, the following values would be invalid, since at least one non-empty element is required by the example-list production:
</p>

<pre>
""
","
",   ,"
</pre>
</div>

				</section>
			</section>
			<section id="tokens">
<h4 title="Tokens">5.6.2. ~token</h4>

<p id="rule.token.separators">
~tokenは、
空白や区切子を内包しない，短い~textな識別子である：
◎
Tokens are short textual identifiers that do not include whitespace or delimiters.
</p>

<pre class="bnf">
`token@p
	= 1*`tchar$p

`tchar@p
	= "!"
	/ "#"
	/ "$"
	/ "`%^"
	/ "&amp;"
	/ "'"
	/ "*"
	/ "+"
	/ "-"
	/ "."
	/ "^"
	/ "_"
	/ "`"
	/ "|"
	/ "~"
	/ `DIGIT$P
	/ `ALPHA$P
	; <span class="comment">
区切子を除く，任意の `VCHAR$P
◎
any VCHAR, except delimiters
</span>
</pre>

<p>
多くの~HTTP`~field値$は、
何個かの共通な構文~成分を利用して定義され，それらの成分は［
`空白$や, 特定の区切子~文字
］で分離される。
区切子は［
~US-ASCII印字可能~文字（ `VCHAR$P ）のうち，
`token$p 内には許容されないもの
］が成す集合
（ `DQUOTE$P ／ "<code>(),/:;&lt;=&gt;?@[\]{}</code>" ）
から選ばれる。
◎
Many HTTP field values are defined using common syntax components, separated by whitespace or specific delimiting characters. Delimiters are chosen from the set of US-ASCII visual characters not allowed in a token (DQUOTE and "(),/:;&lt;=&gt;?@[\]{}").
</p>

			</section>
			<section id="whitespace">
<h4 title="Whitespace">5.6.3. 空白</h4>

<p>
この仕様は、
空白列（ `linear whitespace^en ）の利用を記すときに，
次に挙げる 3 つの規則を利用する：
◎
This specification uses three rules to denote the use of linear whitespace: OWS (optional whitespace), RWS (required whitespace), and BWS ("bad" whitespace).
</p>
<dl>
	<dt>
`OWS@p
（省略可能な空白）
</dt>
	<dd>
<p>
この規則は、［
0 個~以上の~octetからなる空白列
］が出現し得る所で利用される。
`送信者$は、
各~protocol要素に対し：
◎
The OWS rule is used where zero or more linear whitespace octets might appear. For protocol elements＼
</p>
		<ul>
			<li>
［
読み易くするため，省略可能な空白が選好される所
］では、［
省略可能な空白を 1 個の `SP$P として`生成-$する
］ベキである。
◎
where optional whitespace is preferred to improve readability, a sender SHOULD generate the optional whitespace as a single SP;＼
</li>
			<li>
他の所では、
~messageを~filterする際に， `OWS$p を`生成-$するベキでない
— ただし、［
妥当でない／求まれてない
］~protocol要素を上書するために必要になる場合は除く。
◎
otherwise, a sender SHOULD NOT generate optional whitespace except as needed to overwrite invalid or unwanted protocol elements during in-place message filtering.
</li>
		</ul>
	</dd>

	<dt>
`RWS@p
（要求される空白）
</dt>
	<dd>
この規則は、［
各~field~tokenを分離するために，［
1 個~以上の~octetからなる空白列
］が要求される
］ときに，利用される。
`送信者$は、
`RWS$p として 1 個の `SP$P を`生成-$するベキである。
◎
The RWS rule is used when at least one linear whitespace octet is required to separate field tokens. A sender SHOULD generate RWS as a single SP.
</dd>
	<dd>
［
`OWS$p ／ `RWS$p
］の意味論は、
1 個の `SP^P と同じになる。
［
`OWS^p ／ `RWS^p 
］として定義されたことが既知な，どの内容も
— ~messageを［
解釈する, あるいは`下流$へ回送する
］前に —
1 個の `SP$P に置換してもヨイ。
◎
OWS and RWS have the same semantics as a single SP. Any content known to be defined as OWS or RWS MAY be replaced with a single SP before interpreting it or forwarding the message downstream.
</dd>

	<dt>
`BWS@p
（ “不良な” 空白）
</dt>
	<dd>
この規則は、［
もっぱら歴史的な理由のため，省略可能な空白が文法にて許容される所
］で利用される。
`送信者$は、
~message内に `BWS$p を`生成-$してはナラナイ。
`受信者$は、
~protocol要素を解釈する前に，
そのような不良~空白を構文解析して除去しなければナラナイ。
◎
The BWS rule is used where the grammar allows optional whitespace only for historical reasons. A sender MUST NOT generate BWS in messages. A recipient MUST parse for such bad whitespace and remove it before interpreting the protocol element.
</dd>
	<dd>
`BWS^p には意味論は無い。
`BWS^p として定義されたことが既知な，どの内容も
— ~messageを［
解釈する, あるいは`下流$へ回送する
］前に —
除去してもヨイ。
◎
BWS has no semantics. Any content known to be defined as BWS MAY be removed before interpreting it or forwarding the message downstream.
</dd>
</dl>

<pre class="bnf">
`OWS$p
	= *( `SP$P / `HTAB$P )
	; `省略可能な空白^com
`RWS$p
	= 1*( `SP$P / `HTAB$P )
	; `要求される空白^com
`BWS$p
	= `OWS$p
	; `“不良” 空白^com
</pre>

			</section>
			<section id="quoted.strings">
<h4 title="Quoted Strings">5.6.4. 引用符~付き文字列</h4>

<p id="rule.quoted-string">
~textを成す文字列は、
二重引用符（ `DQUOTE$P ）で括られていれば，単独の値として構文解析される：
◎
A string of text is parsed as a single value if it is quoted using double-quote marks.
</p>

<pre class="bnf">
`quoted-string@p
	= `DQUOTE$P *( `qdtext$p / `quoted-pair$p ) `DQUOTE$P
`qdtext@p
	= `HTAB$P
	/ `SP$P
	/ `21^X
	/ `23-5B^X
	/ `5D-7E^X
	/ `obs-text$p
</pre>

<p id="rule.quoted-pair">
構成子［
`quoted-string$p ／ `comment$p
］の中では、
1 個の~octetをエスケープする仕組みとして，~backslash（ "`\^c" ）を利用できる。
`受信者$は， `quoted-string$p による値を処理するときには、
`quoted-pair$p を，それが［
~backslashの直後の~octetに置換されていた
］かのように取扱わなければナラナイ。
◎
The backslash octet ("\") can be used as a single-octet quoting mechanism within quoted-string and comment constructs. Recipients that process the value of a quoted-string MUST handle a quoted-pair as if it were replaced by the octet following the backslash.
</p>

<pre class="bnf">
`quoted-pair@p
	= "\" ( `HTAB$P / `SP$P / `VCHAR$P / `obs-text$p )
</pre>

<div class="p">
<p>
`送信者$は、［
`quoted-string$p ／ `comment$p
］内に `quoted-pair$p を`生成-$するベキでない
— 次に挙げる~octetをエスケープするときを除いて：
</p>
<ul>
	<li>
`quoted-string$p の中の［
`DQUOTE$P, ~backslash
］
</li>
	<li>
`comment$p の中の［
丸括弧, ~backslash
］
</li>
</ul>
◎
A sender SHOULD NOT generate a quoted-pair in a quoted-string except where necessary to quote DQUOTE and backslash octets occurring within that string.＼
A sender SHOULD NOT generate a quoted-pair in a comment except where necessary to quote parentheses ["(" and ")"] and backslash octets occurring within that comment.
</div>

			</section>
			<section id="comments">
<h4 title="Comments">5.6.5. ~comment</h4>

<p id="rule.comment">
一部の~HTTP`~field$は、
丸括弧（ "`(^c", "`)^c" ）で括ることで，~commentを内包できる。
~commentが許容される`~field$は、［
その`~field値$の定義の一部に "`comment$p" を包含している
］ものに限られる：
◎
Comments can be included in some HTTP fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing "comment" as part of their field value definition.
</p>

<pre class="bnf">
`comment@p
	= "(" *( `ctext$p / `quoted-pair$p / `comment$p ) ")"
`ctext@p
	= `HTAB$P
	/ `SP$P
	/ `21-27^X
	/ `2A-5B^X
	/ `5D-7E^X
	/ `obs-text$p
</pre>

			</section>
			<section id="parameter">
<h4 title="Parameters">5.6.6. ~parameter群</h4>

<p id="rule.parameter">
~parameter群（ `parameters$p ）は、
0 個以上の~parameterを与える
— それは、
ある~itemに補助的な情報を付加するための共通な構文として，
`~field値$の中で利用されることが多い。
各~parameter（ `parameter$p ）は、［
名前, 値
］が成す~pairを与える
— 各~pairは、
通例的に，直前の~semicolonにより区切られる。
◎
Parameters are instances of name/value pairs; they are often used in field values as a common syntax for appending auxiliary information to an item. Each parameter is usually delimited by an immediately preceding semicolon.
</p>

<pre class="bnf">
`parameters@p
	= *( `OWS$p ";" `OWS$p [ `parameter$p ] )
`parameter@p
	= `parameter-name$p "=" `parameter-value$p
`parameter-name@p
	= `token$p
`parameter-value@p
	= ( `token$p / `quoted-string$p )
</pre>

<p>
~parameterの名前を成す `parameter-name$p は、
文字大小無視である。
~parameterの値を成す `parameter-value$p が文字大小区別になるかどうかは、
名前の意味論に依存する。
~parameterの例, および一部の等価な形は、
`~MIME型$, `Accept$h ~headerに見られる。
◎
Parameter names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Examples of parameters and some equivalent forms can be seen in media types (Section 8.3.1) and the Accept header field (Section 12.5.1).
</p>

<p>
`token$p 生成規則に合致する `parameter$p 値は、［
`token$p として，または
`quoted-string$p の中に
］伝送できる。
値は、
引用符の有無に関わらず，等価になる。
◎
A parameter value that matches the token production can be transmitted either as a token or within a quoted-string. The quoted and unquoted values are equivalent.
</p>

<p class="note">注記：
~parameterにおける文字 "`=^c" の前後には、
`空白$は許容されない（ “不良” 空白（ `BWS$p ）であっても）。
◎
Note: Parameters do not allow whitespace (not even "bad" whitespace) around the "=" character.
</p>

			</section>
			<section id="http.date">
<h4 title="Date/Time Formats">5.6.7. 日付時刻の形式</h4>

<p>
1995 年より前は、
時刻印を通信するときに， 3 種の形式が~serverで共通的に利用されていた。
旧い実装との互換性を得るため、
その 3 種すべては，ここに定義される。
選好される形式は、［
`RFC5322$r により利用される日付時刻~指定
］の下位集合
— 固定的な長さ, かつ単-時間帯なそれ（ `IMF-fixdate$p ） —
である。
◎
Prior to 1995, there were three different formats commonly used by servers to communicate timestamps. For compatibility with old implementations, all three are defined here. The preferred format is a fixed-length and single-zone subset of the date and time specification used by the Internet Message Format [RFC5322].
</p>

<pre class="bnf">
`HTTP-date@p
	= `IMF-fixdate$p
	/ `obs-date$p
</pre>

<div class="example">
<p>
選好される形式の例：
◎
An example of the preferred format is
</p>

<pre class="lang-http">
Sun, 06 Nov 1994 08:49:37 GMT    ; `IMF-fixdate^p
</pre>

<p>
廃用にされた 2 種の形式の例
（順に，廃用にされた RFC 850 形式, ANSI C の `asctime()^c 形式）：
◎
Examples of the two obsolete formats are
</p>

<pre class="lang-http">
Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete RFC 850 format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
</pre>
</div>

<p>
`受信者$は、
~HTTP~field内の時刻印 値を構文解析するときは，
3 種の `HTTP-date$p 形式すべてを受容しなければナラナイ。
`送信者$は、［
`HTTP-date$p による時刻印を包含する~field
］を`生成-$するときは，
`IMF-fixdate$p 形式による時刻印を`生成-$しなければナラナイ。
◎
A recipient that parses a timestamp value in an HTTP field MUST accept all three HTTP-date formats. When a sender generates a field that contains one or more timestamps defined as HTTP-date, the sender MUST generate those timestamps in the IMF-fixdate format.
</p>

<p>
`HTTP-date$p 値は、
時刻を［
~UTC（ `Coordinated Universal Time^en ）の~instance
］として表現する。
最初の 2 種の形式は、［
~UTC名の~~前身である `Greenwich Mean Time^en （~~グリニッジ~~平均時）の~~頭字語 “GMT”
］による~UTCを指示する
— `asctime^p 形式~内の値は、
~UTCであるものと見做される。
◎
An HTTP-date value represents time as an instance of Coordinated Universal Time (UTC). The first two formats indicate UTC by the three-letter abbreviation for Greenwich Mean Time, "GMT", a predecessor of the UTC name; values in the asctime format are assumed to be in UTC.
</p>

<p>
`時計@
（ `clock^en ）とは、
~UTCにおける~~現在時の適度な近似を供する能力がある実装である。
時計~実装は、
~UTCと同期するよう，［
~NTP（ `RFC5905$r ）または何らかの類似な~protocol
］を利用する~OUGHT。
◎
A "clock" is an implementation capable of providing a reasonable approximation of the current instant in UTC. A clock implementation ought to use NTP ([RFC5905]), or some similar protocol, to synchronize with UTC.
</p>

<p>
選好される形式は：
◎
Preferred format:
</p>

<pre class="bnf">
`IMF-fixdate@p
	= `day-name$p "," SP `date1$p SP `time-of-day$p SP `GMT$p
	; <span class="comment">
固定的な［ 長さ／時間帯／~~大文字頭字 ］による下位集合が成す形式
— `5322/3.3$rfc を見よ
◎
fixed length/zone/capitalization subset of the format; see Section 3.3 of [RFC5322]
</span>

`day-name@p
	= ~Ps"Mon"
	/ ~Ps"Tue"
	/ ~Ps"Wed"
	/ ~Ps"Thu"
	/ ~Ps"Fri"
	/ ~Ps"Sat"
	/ ~Ps"Sun"

`date1@p
	= `day$p SP `month$p SP `year$p
	; `例：^com 02 Jun 1982

`day@p
	= 2`DIGIT$P
`month@p
	= ~Ps"Jan"
	/ ~Ps"Feb"
	/ ~Ps"Mar"
	/ ~Ps"Apr"
	/ ~Ps"May"
	/ ~Ps"Jun"
	/ ~Ps"Jul"
	/ ~Ps"Aug"
	/ ~Ps"Sep"
	/ ~Ps"Oct"
	/ ~Ps"Nov"
	/ ~Ps"Dec"
`year@p
	= 4`DIGIT$P

`GMT@p
	= ~Ps"GMT"

`time-of-day@p
	= `hour$p ":" `minute$p ":" `second$p
	; 00:00:00 - 23:59:60 `（うるう秒（ leap second ））^com

`hour@p
	= 2`DIGIT$P
`minute@p
	= 2`DIGIT$P
`second@p
	= 2`DIGIT$P
</pre>

<p>
廃用にされた形式は：
◎
Obsolete formats:
</p>

<pre class="bnf">
`obs-date@p
	= `rfc850-date$p
	/ `asctime-date$p

`rfc850-date@p
	= `day-name-l$p "," `SP$P `date2$p `SP$P `time-of-day$p `SP$P GMT
`date2@p
	= `day$p "-" `month$p "-" 2`DIGIT$P
	; `例：^com 02-Jun-82

`day-name-l@p
	= ~Ps"Monday"
	/ ~Ps"Tuesday"
	/ ~Ps"Wednesday"
	/ ~Ps"Thursday"
	/ ~Ps"Friday"
	/ ~Ps"Saturday"
	/ ~Ps"Sunday"

`asctime-date@p
	= `day-name$p `SP$P `date3$p `SP$P `time-of-day$p `SP$P `year$p
`date3@p
	= `month$p `SP$P ( 2`DIGIT$P / ( `SP$P 1`DIGIT$P ))
	; `例：^com Jun  2
</pre>

<p>
`HTTP-date$p は文字大小区別である。
これは、
~cache受信者に対しては，
`CACHING$r `鮮度＠~HTTPcache#expiration.model§により緩められることに注意。
◎
HTTP-date is case sensitive. Note that Section 4.2 of [CACHING] relaxes this for cache recipients.
</p>

<p>
`送信者$は、
`HTTP-date$p 内に［
文法~内に `SP$P として特定的に内包されたもの
］以外の余計な`空白$を`生成-$してはナラナイ。
［
`day-name$p ／
`day$p ／
`month$p ／
`year$p ／
`time-of-day$p
］の意味論は、
`5322/3.3$rfc の対応する名前を伴う構成子に定義されるそれと同じである。
◎
A sender MUST NOT generate additional whitespace in an HTTP-date beyond that specifically included as SP in the grammar. The semantics of day-name, day, month, year, and time-of-day are the same as those defined for the Internet Message Format constructs with the corresponding name ([RFC5322], Section 3.3).
</p>

<p>
［
`rfc850-date$p 形式による 2 桁~年を利用する時刻印 値
］の`受信者$は、［
50 年より先の未来として出現する時刻印
］を［
最後の 2 桁が同じ，過去の年
］を表現しているものと解釈しなければナラナイ。
◎
Recipients of a timestamp value in rfc850-date format, which uses a two-digit year, MUST interpret a timestamp that appears to be more than 50 years in the future as representing the most recent year in the past that had the same last two digits.
</p>

<p>
時刻印 値の`受信者$には、
~field定義により制約されない限り，
時刻印の構文解析において堅牢であることが奨励される。
例えば，~messageは、
ときには［［
`RFC5322$r により定義される，いずれかの日付時刻~指定
］を生成し得るような，非~HTTP~source
］から~HTTP越しに回送されることもある。
◎
Recipients of timestamp values are encouraged to be robust in parsing timestamps unless otherwise restricted by the field definition. For example, messages are occasionally forwarded over HTTP from a non-HTTP source that might generate any of the date and time specifications defined by the Internet Message Format.
</p>

<p class="note">注記：
~HTTPが時刻印の形式に課す要件は、
~protocol~streamの中での利用eに限り適用される。
実装には、
これらの形式を［
利用者への呈示, 要請の~logをとる, 等々
］に利用することは，要求されない。
◎
Note: HTTP requirements for timestamp formats apply only to their usage within the protocol stream. Implementations are not required to use these formats for user presentation, request logging, etc.
</p>

			</section>
		</section>
	</section>
	<section id="message.abstraction">
<h2 title="Message Abstraction">6. ~messageの抽象-化</h2>


<p>
~HTTPの各~major~versionは、
~messageの通信-用に自前の構文を定義する。
この節では、［
それらの~message特性の一般~化,
共通な構造,
意味論を伝達するための収容能
］に基づいて，~HTTP~message用の抽象-~data型を定義する。
この抽象-化は、［
送信者／受信者
］に対し［
~HTTP~versionに依存しない要件
］を定義するために利用される
— ある~versionにおける~messageを、
その意味を変更することなく，他の~versionを通して中継できるよう。
◎
Each major version of HTTP defines its own syntax for communicating messages. This section defines an abstract data type for HTTP messages based on a generalization of those message characteristics, common structure, and capacity for conveying semantics. This abstraction is used to define requirements on senders and recipients that are independent of the HTTP version, such that a message in one version can be relayed through other versions without changing its meaning.
</p>

<div class="p">
<p>
各
`~message@
（ `message^en ）は、
次に挙げるものからなる：
◎
A "message" consists of the following:
</p>
<ul>
	<li>
`制御~data$
⇒
~messageについて述べる／~messageを~routeする。
◎
control data to describe and route the message,
</li>
	<li>
`~header節$
⇒
一連の［［
名前, 値
］が成す~pair（`~header$）
］からなる検索~tableを成し，
制御~dataを拡張する, あるいは［
`送信者$／~message／`内容$／文脈
］についての追加的な情報を伝達する。
◎
a headers lookup table of name/value pairs for extending that control data and conveying additional information about the sender, message, content, or context,
</li>
	<li>
`内容$
⇒
~streamを成し，際限なく続くものにもなり得る。
◎
a potentially unbounded stream of content, and
</li>
	<li>
`~trailer節$
⇒
一連の［［
名前, 値
］が成す~pair（`~trailer$）
］からなる検索~tableを成し，
`内容$を送信している間に得された情報を通信する。
◎
a trailers lookup table of name/value pairs for communicating information obtained while sending the content.
</li>
</ul>
</div>

<p>
最初に［
~frame法~data／制御~data
］が送信され，
【！↑containing fields for the headers table】`~header節$が後続する。
~messageが`内容$を内包する場合、
それは`~header節$の後に送信され，
それには`~trailer節$【！↑contain fields for the trailers table】が後続する~~可能性もある†。
◎
Framing and control data is sent first, followed by a header section containing fields for the headers table. When a message includes content, the content is sent after the header section, potentially followed by a trailer section that might contain fields for the trailers table.
</p>

<p class="trans-note">【†
とは言え、
`内容$を成す~streamは，際限なく続くものにもなり得るので、
その中途に`~trailer$たちが~~分散して挟まれる拡張はあり得る。
】</p>

<div class="p">
<p>
~messageは、
~streamとして処理されるものと期待される
— ~streamの目的と継続される処理は、
それが読取られる間に露呈される。
よって：
</p>
<ul>
	<li>
`制御~data$は、
`受信者$は何を即時に知る必要があるかを述べる。
</li>
	<li>
各`~header$は、
`内容$を受信する前に何を知る必要があるかを述べる。
</li>
	<li>
`内容$は（在るならば）、
大概は，`受信者$は~message意味論を充足するために何を［
求める／必要とする
］かを包含する。
</li>
	<li>
各`~trailer$は、
`内容$を送信する前は未知であった，任意選択な~metadataを供する。
</li>
</ul>
◎
Messages are expected to be processed as a stream, wherein the purpose of that stream and its continued processing is revealed while being read. Hence, control data describes what the recipient needs to know immediately, header fields describe what needs to be known before receiving content, the content (when present) presumably contains what the recipient wants or needs to fulfill the message semantics, and trailer fields provide optional metadata that was unknown prior to sending the content.
</div>

<p>
各~messageは、
`自己-記述的@
（ `self-descriptive^en ）になる
— すなわち，次を満たす —
ものと意図される
⇒
受信者が~messageについて知る必要がある あらゆるものは、［
送信者の現在の（先立つ~messageを介して確立された）適用~状態を解する
］ことを要求することなく
— 【接続の`連鎖$を】通過中に［
圧縮された各部を復号した／省かれた各部を~~再構成した
］後に —
~message自体を調べることで，決定できる。
◎
Messages are intended to be "self-descriptive": everything a recipient needs to know about the message can be determined by looking at the message itself, after decoding or reconstituting parts that have been compressed or elided in transit, without requiring an understanding of the sender's current application state (established via prior messages).＼
</p>

<p>
しかしながら，`~client$は、
自身による要請に対する応答を［
構文解析-／解釈-／~cache
］するときは，当の要請の知識を維持する下で行わなければナラナイ。
例えば，［
`HEAD$m ~methodに対する応答,
`GET$m ~methodに対する応答
］は、
始めの方は同じ見かけであっても，同じ方式では構文解析できない。
◎
However, a client MUST retain knowledge of the request when parsing, interpreting, or caching a corresponding response. For example, responses to the HEAD method look just like the beginning of a response to GET but cannot be parsed in the same manner.
</p>

<p>
この~message抽象-化は、
~HTTPの多くの~versionにまたがる一般~化であり，
一部の~versionには見出されないかもしれない特能も含まれることに注意。
例えば，`~trailer$は、
~HTTP11における `chunked$c `転送~符号法$の中で`内容$の後にある`~trailer節$として導入された。
等価な特能は、［
~HTTP2／~HTTP3
］においては，各~streamを終了させる~header~blockの中に在る。
◎
Note that this message abstraction is a generalization across many versions of HTTP, including features that might not be found in some versions. For example, trailers were introduced within the HTTP/1.1 chunked transfer coding as a trailer section after the content. An equivalent feature is present in HTTP/2 and HTTP/3 within the header block that terminates each stream.
</p>

		<section id="message.framing">
<h3 title="Framing and Completeness">6.1. ~frame法と完全さ</h3>

<p>
~message~frame法は、
各~messageが
— 同じ接続~上の他の~messageや~noiseと判別できるよう —
どう始まり, どう終端するかを指示する。
~HTTPの各`~major~version$は、
自前の~frame法の仕組みを定義する。
◎
Message framing indicates how each message begins and ends, such that each message can be distinguished from other messages or noise on the same connection. Each major version of HTTP defines its own framing mechanism.
</p>

<p>
~HTTP09および ~HTTP10の早期の配備は、
下層の接続の~closureを利用して，応答を終端していた。
後方-互換性を得るため、
この暗黙的な~frame法は~HTTP11においても許容される。
しかしながら，当の接続が早く~closeされた場合、
暗黙的な~frame法では，不完全な応答と判別するのに失敗し得る。
この理由から，現代のほぼすべての実装は、
長さで区切られた~message~data列の形で，明示的な~frame法を利用する。
◎
HTTP/0.9 and early deployments of HTTP/1.0 used closure of the underlying connection to end a response. For backwards compatibility, this implicit framing is also allowed in HTTP/1.1. However, implicit framing can fail to distinguish an incomplete response if the connection closes early. For that reason, almost all modern implementations use explicit framing in the form of length-delimited sequences of message data.
</p>

<p>
~messageは、
その~frame法により指示される すべての~octetが可用になったとき，
`完全@
（ `complete^en ）であると見なされる。
明示的な~frame法が利用されていない場合、
下層の接続の~closeにより終端された`応答~message$は
— 不完全な応答と判別-不能であろうが，
~transport~levelの~errorにより完全でないものと指示されない限り —
`完全$と見なされることに注意。
◎
A message is considered "complete" when all of the octets indicated by its framing are available. Note that, when no explicit framing is used, a response message that is ended by the underlying connection's close is considered complete even though it might be indistinguishable from an incomplete response, unless a transport-level error indicates that it is not complete.
</p>

		</section>
		<section id="message.control.data">
<h3 title="Control Data">6.2. 制御~data</h3>

<div class="p">
<p>
~messageは、
その首な目的を述べる
`制御~data@
（ `control data^en ）から開始する：
◎
Messages start with control data that describe its primary purpose.＼
</p>
<ul>
	<li>
`要請~message$の制御~dataは、
次を内包する
⇒＃
`要請~method$,
`要請~target$,
`~protocol~version$
◎
Request message control data includes a request method (Section 9), request target (Section 7.1), and protocol version (Section 2.5).＼
</li>
	<li>
`応答~message$の制御~dataは、
次を内包する
⇒＃
`状態s~code$,
任意選択な`事由~句$,
`~protocol~version$
◎
Response message control data includes a status code (Section 15), optional reason phrase, and protocol version.
</li>
</ul>
</div>

<p>
~HTTP11 `HTTP/1.1$r までの~versionにおいては、
制御~dataは，~messageの最初の行l【 `start-line＠~HTTPv1#p.start-line$p 】として送信される。
［
~HTTP2 `HTTP/2$r ／ ~HTTP3 `HTTP/3$r
］においては、
制御~dataは，予約-済みな名前~接頭辞を伴う疑似-~header（例： "`authority^ph" ）として送信される。
◎
In HTTP/1.1 ([HTTP/1.1]) and earlier, control data is sent as the first line of a message. In HTTP/2 ([HTTP/2]) and HTTP/3 ([HTTP/3]), control data is sent as pseudo-header fields with a reserved name prefix (e.g., ":authority").
</p>

<p>
どの~HTTP~messageも，`~protocol~version$を伴う。
~versionは、
利用-中にある~versionに依存して，［
~messageの中で明示的に識別される
］ことも［
当の~messageが受信された`接続$により推定される
］こともある。
`受信者$は、
その~version情報を利用して，その送信者との今後の通信~用に［
制限／~~可能性
］を決定する。
◎
Every HTTP message has a protocol version. Depending on the version in use, it might be identified within the message explicitly or inferred by the connection over which the message is received. Recipients use that version information to determine limitations or potential for later communication with that sender.
</p>

<p>
~messageの`~protocol~version$は、
媒介者により~messageが回送されるとき，その媒介者が利用する~versionを反映するように更新される。
`Via$h ~headerは、
回送する~messageの中に`上流$からの~protocol情報を通信するために利用される。
◎
When a message is forwarded by an intermediary, the protocol version is updated to reflect the version used by that intermediary. The Via header field (Section 7.6.3) is used to communicate upstream protocol information within a forwarded message.
</p>

<div class="p">
<p>
`~client$が要請~内に送信する~versionは：
◎
A client SHOULD send a request version＼
</p>
<ul>
	<li>
<p>
~AND↓ を満たす，最も高い~versionにするベキである：
</p>
		<ul>
			<li>
~client自身が適合している
</li>
			<li>
その`~major~version$は、［
`~server$が~supportする，最も高い~version
］が~clientに既知である場合は，それ以下である
</li>
		</ul>
◎
equal to the highest version to which the client is conformant and whose major version is no higher than the highest version supported by the server, if this is known.＼
</li>
	<li>
~client自身が適合していなければナラナイ。
◎
A client MUST NOT send a version to which it is not conformant.
</li>
</ul>
</div>

<p>
`~client$は、［
~serverが~HTTP仕様を不正に実装している
］ことが既知である場合，［
より低い~versionによる要請
］を送信してもヨイ
— ただし，それは、
~clientが，少なくとも 1 回は通常の要請を試みて，対する応答の［
`応答~状態s~code$や`~header$（例： `Server$h ）
］から［
~serverが より高い要請~versionを不適正に取扱う
］ことを決定できた後に限られる。
◎
A client MAY send a lower request version if it is known that the server incorrectly implements the HTTP specification, but only after the client has attempted at least one normal request and determined from the response status code or header fields (e.g., Server) that the server improperly handles higher request versions.
</p>

<div class="p">
<p>
`~server$が，所与の要請に対する応答~内に送信する~versionは：
◎
A server SHOULD send a response version＼
</p>
<ul>
	<li>
<p>
~AND↓ を満たす，最も高い~versionにするベキである：
</p>
		<ul>
			<li>
~server自身が適合している
</li>
			<li>
その`~major~version$は、
その要請にて受信したもの以下である
</li>
		</ul>
◎
equal to the highest version to which the server is conformant that has a major version less than or equal to the one received in the request.＼
</li>
	<li>
~server自身が適合していなければナラナイ。
◎
A server MUST NOT send a version to which it is not conformant.＼
</li>
</ul>

<p>
`~server$は、
何らかの事由で［
`~client$の~protocol`~major~version$
］に対する~serviceを拒否するよう望むときは，
`505$st 応答を送信できる。
◎
A server can send a 505 (HTTP Version Not Supported) response if it wishes, for any reason, to refuse service of the client's major protocol version.
</p>
</div>

<div class="p">
<p>
`受信者$は、
受信した~messageに対し，それに伴われる［
`~major~version$番号を %~major,
`~minor~version$番号を %~minor
］とするとき：
◎
↓</p>
<ul>
	<li>
%~major を実装するが，
%~minor は %~major の中で自身が実装する どの`~minor~version$よりも高い場合
⇒
当の~messageを［
%~minor は、
%~major の中で自身が適合する，最も高い`~minor~version$であった
］かのように処理するベキである。
◎
A recipient that receives a message with a major version number that it implements and a minor version number higher than what it implements SHOULD process the message as if it were in the highest minor version within that major version to which the recipient is conformant.＼
</li>
	<li>
%~minor は［
当の~messageが送信される前に，
自身が %~major の中で~supportを指示した`~minor~version$
］より高い場合，
あるいは~supportする`~minor~version$をまだ指示していなかった場合
⇒
当の~messageを［
%~major を実装するどの実装においても安全に処理できる程に，十分に後方-互換である
］ものと見做せる。
◎
A recipient can assume that a message with a higher minor version, when sent to a recipient that has not yet indicated support for that higher version, is sufficiently backwards-compatible to be safely processed by any implementation of the same major version.
</li>
</ul>
</div>

		</section>
		<section id="header.fields">
<h3 title="Header Fields">6.3. ~header</h3>

<p>
`~header@
（ `header field^en ／ 俗に `header^en ）は、
`~field$のうち，`内容$より前に［
送信される／受信される
］ものを指す。
◎
Fields (Section 5) that are sent or received before the content are referred to as "header fields" (or just "headers", colloquially).
</p>

<p class="trans-note">【
この訳では、
一律に，略称（俗称）である “~header” で表記することにする。
】</p>

<p>
~messageの
`~header節@
（ `header section^en, 略して `headers^en ）は、
一連の~header`~field行l$からなる`~field節$である。
各~headerは、
次を行い得る
⇒＃
~messageの意味論を改変するか拡張する／
`送信者$について述べる／
`内容$を定義する／
追加的な文脈を供する
◎
The "header section" of a message consists of a sequence of header field lines. Each header field might modify or extend message semantics, describe the sender, define the content, or provide additional context.
</p>

<p class="note">注記：
【~field定義における語】`~header$は、［
有名~fieldのうち，`~header節$内に限り送信することが許容されるもの
］を特定的に指す。
◎
Note: We refer to named fields specifically as a "header field" when they are only allowed to be sent in the header section.
</p>

		</section>
		<section id="content">
<h3 title="Content">6.4. 内容</h3>

<p>
~HTTP~messageは、［
`完全$／`部分的$
］な`表現$を，その
`内容@
（ `message content^en, 略して `content^en ）として転送することが多い
— それは、
~message~frame法により他と線引きされ，
`~header節$の後に送信される~octetの~streamである。
◎
HTTP messages often transfer a complete or partial representation as the message "content": a stream of octets sent after the header section, as delineated by the message framing.
</p>

<p class="trans-note">【
~messageの`内容$は、
この仕様が改訂した `RFC7231$r においては，
“`payload body^en”
（~payload本体, 略して `payload^en ）と称されていた。
より過去の仕様
— 特に， `RFC2616$r 世代の~RFCなど —
では
“`entity body^en”
（実体~本体）と称されていた。
（ “内容” という語は汎用に過ぎるので、
この訳では，~messageの`内容$を意味する “内容” には，
可能な限り ここを指す~linkをあてがっている。）
】</p>

<p>
この抽象的な［
`内容$の定義
］は、
~message~frame法から抽出された後の~dataを反映する。
例えば、
~HTTP11の`~message本体$は，
`chunked$c `転送~符号法$で符号化された~dataの~stream
— 一連の~data~chunk,
【その終端を指示する】 1 個の長さ 0 の~chunk,
`~trailer節$ —
からなることもある。
一方で，同じ~messageの`内容$は、
`転送~符号法$を復号した後の~data~streamのみを内包する
— それは、［
~chunk長さ,
`chunked$c ~frame法の構文,
`~trailer$
］は内包しない。
◎
This abstract definition of content reflects the data after it has been extracted from the message framing. For example, an HTTP/1.1 message body (Section 6 of [HTTP/1.1]) might consist of a stream of data encoded with the chunked transfer coding -- a sequence of data chunks, one zero-length chunk, and a trailer section -- whereas the content of that same message includes only the data stream after the transfer coding has been decoded; it does not include the chunk lengths, chunked framing syntax, nor the trailer fields (Section 6.5).
</p>

<p class="note">注記：
一部の~field名は、
"`Content-^c" 接頭辞を伴う。
これは、
非正式な規約である
— これらの~fieldのうち一部は，上で定義したように~messageの`内容$を参照rするが、
他のものは，`選定される表現$を視野に入れる。
どちらなのかは、
個々の~fieldの定義を見よ。
◎
Note: Some field names have a "Content-" prefix. This is an informal convention; while some of these fields refer to the content of the message, as defined above, others are scoped to the selected representation (Section 3.2). See the individual field's definition to disambiguate.
</p>

			<section id="content.semantics">
<h4 title="Content Semantics">6.4.1. 内容の意味論</h4>

<p>
要請における`内容$の目的は、
~method意味論（ `9§ ）により定義される。
例えば：
◎
The purpose of content in a request is defined by the method semantics (Section 9).
◎
For example,＼
</p>
<ul>
	<li>
`PUT$m 要請の`内容$における`表現$は、［
要請が成功裡に適用された後の，`~target資源$に欲される状態
］を表現する。
◎
a representation in the content of a PUT request (Section 9.3.4) represents the desired state of the target resource after the request is successfully applied,＼
</li>
	<li>
一方で，
`POST$m 要請の`内容$における`表現$は、［
`~target資源$により処理されることになる情報
］を表現する。
◎
whereas a representation in the content of a POST request (Section 9.3.3) represents information to be processed by the target resource.
</li>
</ul>

<p>
応答における`内容$の目的は、［
`要請~method$,
`応答~状態s~code$,
応答~内の~fieldのうち当の内容について述べるもの
］により定義される。
例えば：
◎
In a response, the content's purpose is defined by the request method, response status code (Section 15), and response fields describing that content. For example,＼
</p>
<ul>
	<li>
`GET$m に対する `200$st 応答の`内容$は、［
`~messageの出生日時$の時点にて観測される，`~target資源$の現在の状態
］を表現する。
◎
the content of a 200 (OK) response to GET (Section 9.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 6.6.1),＼
</li>
	<li>
一方で，
`POST$m に対する同じ `200$st 応答の`内容$は、
処理の結果を表現することもあれば，［
処理を適用した後の，`~target資源$の新たな状態
］を表現することもある。
◎
whereas the content of the same status code in a response to POST might represent either the processing result or the new state of the target resource after applying the processing.
</li>
</ul>

<p>
`GET$m に対する `206$st 応答の`内容$は、
`206§st0 にて述べるとおり，`選定される表現$を成す［
単独の部位t，または
複数個の部位tを包含している`複-部位t$な~message本体
］を包含する。
◎
The content of a 206 (Partial Content) response to GET contains either a single part of the selected representation or a multipart message body containing multiple parts of that representation, as described in Section 15.3.7.
</p>

<p>
~error状態s~codeを伴う`応答~message$は、
通例的に，その~error条件を表現する`内容$を包含する
— ［
その~error状態, および
その解決に示唆される手続き
］は、
当の`内容$が述べる。
◎
Response messages with an error status code usually contain content that represents the error condition, such that the content describes the error state and what steps are suggested for resolving it.
</p>

<p>
`HEAD$m 要請~methodに対する応答は、
`内容$を決して内包しない
— それに結付けられた`応答~header$たちは、［
`要請~method$が `GET$m であったとするときにとる値
］のみを指示する。
◎
Responses to the HEAD request method (Section 9.3.2) never include content; the associated response header fields indicate only what their values would have been if the request method had been GET (Section 9.3.1).
</p>

<p>
`CONNECT$m 要請~methodに対する `2xx$st 応答には、
`内容$は無い
— 代わりに，`接続$を`~tunnel$~modeに切替える。
◎
2xx (Successful) responses to a CONNECT request method (Section 9.3.6) switch the connection to tunnel mode instead of having content.
</p>

<p>
すべての［
`1xx$st／`204$st／`304$st
］応答は、
`内容$を内包しない。
◎
All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include content.
</p>

<p>
他のすべての応答は、
`内容$を内包する
— その長さは 0 にもなり得るが。
◎
All other responses do include content, although that content might be of zero length.
</p>

<p class="trans-note">【
`205$st 応答も`内容$を生成してはナラナイとされている
— `7599$errata（Rejected）を見よ。
】</p>

			</section>
			<section id="identifying.content">
<h4 title="Identifying Content">6.4.2. 内容の識別-法</h4>

<p>
~messageの`内容$として［
`完全$／`部分的$
］な`表現$が転送されるとき、［
その特定の表現に対応する`資源$用の識別子
］を［
送信者が給する, または受信者が決定する
］ことが望ましいことはよくある。
例えば，ある “現在の気象情報” 用の資源に対し `GET$m 要請を為している`~client$は、
返される内容
（例： “20210720T1711 時点における，富士山の気象情報” ）
に特有な識別子を求めるかもしれない。
これは、［
時間~越しに変化している`表現$を有するものと期待される`資源$
］からの`内容$を共有したり~bookmarkするために有用になり得る。
◎
When a complete or partial representation is transferred as message content, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that specific representation. For example, a client making a GET request on a resource for "the current weather report" might want an identifier specific to the content returned (e.g., "weather report for Laguna Beach at 20210720T1711"). This can be useful for sharing or bookmarking content from resources that are expected to have changing representations over time.
</p>

<p>
`要請~message$に対しては：
◎
For a request message:
</p>
<ul class="switch">
	<li>
要請に `Content-Location$h ~headerが在る場合
⇒
`送信者$は，［
その`内容$が［
`Content-Location$h `~field値$により識別される`資源$
］の`表現$である
］ことを表明している。
しかしながら，そのような表明は、
他の手段（この仕様では定義されない）により検証yされない限り，信用できない。
それでも、
その情報は，改訂~履歴~link用には有用になり得る。
◎
If the request has a Content-Location header field, then the sender asserts that the content is a representation of the resource identified by the Content-Location field value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification). The information might still be useful for revision history links.
</li>
	<li>
他の場合
⇒
`内容$は~HTTPにおいては識別されない
— が、
当の内容は，より特有な識別子を給するかもしれない。
◎
Otherwise, the content is unidentified by HTTP, but a more specific identifier might be supplied within the content itself.
</li>
</ul>

<p>
`応答~message$に対しては：
◎
For a response message, the following rules are applied in order until a match is found:
</p>
<ol>
	<li>
`要請~method$が `HEAD$m の場合、
応答には`内容$は無い。
◎
If the request method is HEAD＼
</li>
	<li>
<p>
`要請~method$が `GET$m の場合、
応答の`状態s~code$が次に挙げるいずれかならば，それに応じて：
◎
↓</p>
		<ul class="switch">
			<li>
`204$st／`304$st
⇒
応答には`内容$は無い。
◎
or the response status code is 204 (No Content) or 304 (Not Modified), there is no content in the response.
</li>
			<li>
`200$st
⇒
`内容$は、
`~target資源$の`表現$である。
◎
If the request method is GET and the response status code is 200 (OK), the content is a representation of the target resource (Section 7.1).
</li>
			<li>
`203$st
⇒
`内容$は、
`~target資源$の`表現$であることに加え，
`媒介者$により［
改変されたか増強されて
］供された~~可能性もある。
◎
If the request method is GET and the response status code is 203 (Non-Authoritative Information), the content is a potentially modified or enhanced representation of the target resource as provided by an intermediary.
</li>
			<li>
`206$st
⇒
`内容$は、
`~target資源$の`表現$を成す， 1 個以上の部位tからなる。
◎
If the request method is GET and the response status code is 206 (Partial Content), the content is one or more parts of a representation of the target resource.
</li>
		</ul>
	</li>
	<li>
<p>
他の場合，応答に `Content-Location$h ~headerが在るならば、
その`~field値$が，`~target~URI$と：
◎
↓</p>
		<ul class="switch">
			<li>
同じ~URIへの参照である場合
⇒
`内容$は、
`~target資源$の`表現$である。
◎
If the response has a Content-Location header field and its field value is a reference to the same URI as the target URI, the content is a representation of the target resource.
</li>
			<li>
<p>
異なる~URIへの参照である場合
⇒
`送信者$は、［
`内容$は，その`~field値$により識別される資源の`表現$である
］ことを表明している。
しかしながら，そのような表明は、
他の手段（この仕様では定義されない）により検証yされない限り，信用できない。
◎
If the response has a Content-Location header field and its field value is a reference to a URI different from the target URI, then the sender asserts that the content is a representation of the resource identified by the Content-Location field value. However, such an assertion cannot be trusted unless it can be verified by other means (not defined by this specification).
</p>

<p class="trans-note">【
~field値が妥当な`~URI参照$でない場合も，この場合に含まれるかどうかは、
はっきりしない
— 下の “他の場合” と見做すか，~errorの取扱い（ `2.4§ ）に従うことも考えられる。
】</p>
			</li>
		</ul>
	</li>
	<li>
他の場合
⇒
`内容$は~HTTPにおいては識別されない
— が、
当の内容は，より特有な識別子を給するかもしれない。
◎
Otherwise, the content is unidentified by HTTP, but a more specific identifier might be supplied within the content itself.
</li>
</ol>

			</section>
		</section>
		<section id="trailer.fields">
<h3 title="Trailer Fields">6.5. ~trailer</h3>

<p>
`~trailer@
（ `trailer field^en ／ 俗に `trailer^en ）†
は、
`~field$のうち，
`~trailer節@
（ `trailer section^en, 略して `trailers^en ）の中に所在するものを指す。
~trailerは、
~messageの［
完全性~検査／~digital署名／送達~計量／後処理~状態s情報
］を給するために有用になり得る。
◎
Fields (Section 5) that are located within a "trailer section" are referred to as "trailer fields" (or just "trailers", colloquially). Trailer fields can be useful for supplying message integrity checks, digital signatures, delivery metrics, or post-processing status information.
</p>

<p class="trans-note">【†
この訳では、
一律に，略称（俗称）である “~trailer” で表記することにする。
】</p>

<p>
`~trailer$は、［
`~header節$が完了した時点で既知になった~message意味論
］に矛盾するのを避けるため，`~header節$内の`~field$とは別々に処理され, 格納される~OUGHT。
ある種の~headerの有無は、［
`~trailer$を受信する前に，一体としての~messageを［
~routeする／処理する
］ために為される選択
］に影響iするかもしれない
— そのような選択は、
後から`~trailer$が発見されても，くつがえせない。
◎
Trailer fields ought to be processed and stored separately from the fields in the header section to avoid contradicting message semantics known at the time the header section was complete. The presence or absence of certain header fields might impact choices made for the routing or processing of the message as a whole before the trailers are received; those choices cannot be unmade by the later discovery of trailer fields.
</p>

			<section id="trailers.limitations">
<h4 title="Limitations on Use of Trailers">6.5.1. ~trailerの利用に対する制限</h4>

<p>
`~trailer節$がアリになるのは、
利用-中にある~HTTP~versionが`~trailer$を~supportしていて，
明示的な~frame法の仕組みにより可能化されているときに限られる。
例えば，~HTTP11における `chunked$c `転送~符号法$では、
`内容$の後に`~trailer節$を送信することが許容される。
◎
A trailer section is only possible when supported by the version of HTTP in use and enabled by an explicit framing mechanism. For example, the chunked transfer coding in HTTP/1.1 allows a trailer section to be sent after the content (Section 7.1.2 of [HTTP/1.1]).
</p>

<p>
多くの`~field$は、
`内容$の受信に先立って評価することが必要yなので，
`~header節$の外側では処理し得ない
— ~messageの［
~frame法／
~route法／
認証／
要請~改変子／
応答~制御／
内容~形式
］を述べる`~field$など。
`送信者$は、
次を知っている場合を除き，`~trailer$を`生成-$してはナラナイ
⇒
対応する【！~header】`~field名$の定義は、
当の`~field$を`~trailer節$内に送信することを許可している
◎
Many fields cannot be processed outside the header section because their evaluation is necessary prior to receiving the content, such as those that describe message framing, routing, authentication, request modifiers, response controls, or content format. A sender MUST NOT generate a trailer field unless the sender knows the corresponding header field name's definition permits the field to be sent in trailers.
</p>

<p>
`~trailer$は、
ある~protocol~versionから別のそれへ~messageを回送する`媒介者$にとっては，
処理が困難にもなり得る。
一部の媒介者は、
通過中の~message全体を~bufferできる場合には
— それを回送する前に —
`~trailer$を`~header節$の中へ（適切に）併合することもできる。
しかしながら，ほとんどの事例では、
`~trailer$たちは単純に破棄される。
`受信者$は、
次が満たされる場合を除き，`~trailer$を`~header節$の中に併合してはナラナイ
⇒
［
受信者は、
対応する`~field名$【！~header】の定義を解する
］かつ［
その定義は、
当の~trailerの`~field値$を安全に併合する方法を定義していて，
それを明示的に許可している
］
◎
Trailer fields can be difficult to process by intermediaries that forward messages from one protocol version to another. If the entire message can be buffered in transit, some intermediaries could merge trailer fields into the header section (as appropriate) before it is forwarded. However, in most cases, the trailers are simply discarded. A recipient MUST NOT merge a trailer field into a header section unless the recipient understands the corresponding header field definition and that definition explicitly permits and defines how trailer field values can be safely merged.
</p>

<p>
要請の `TE$h ~header内に~keyword "`trailers$c" が在る場合、
`~client$は
— 自身, および`下流$にある~clientたちに利するため —
~trailerを受容する用意があることを指示する。
`媒介者$からの要請においては、
このことは，［
`下流$【`外方$？】にある すべての~clientが，回送される応答~内の`~trailer$を受容する用意がある
］ことを含意する。
"`trailers^c" が在ったとしても、［
応答~内の特定0の~trailerについて，それを処理する~client（たち）がある
］ことにはならないことに注意
— それが意味するのは、
どの~clientも，`~trailer節$を落とさないことに限られる。
◎
The presence of the keyword "trailers" in the TE header field (Section 10.1.4) of a request indicates that the client is willing to accept trailer fields, on behalf of itself and any downstream clients. For requests from an intermediary, this implies that all downstream clients are willing to accept trailer fields in the forwarded response. Note that the presence of "trailers" does not mean that the client(s) will process any particular trailer field in the response; only that the trailer section(s) will not be dropped by any of the clients.
</p>

<p>
`~trailer$は，通過中に破棄される~~可能性があるので、
~serverは，［
~UAが受信することが必要yであると予見されるもの
］を`~trailer$として`生成-$するベキでない
◎
Because of the potential for trailer fields to be discarded in transit, a server SHOULD NOT generate trailer fields that it believes are necessary for the user agent to receive.
</p>

			</section>
			<section id="trailers.processing">
<h4 title="Processing Trailer Fields">6.5.2. ~trailerの処理</h4>

<p>
`Trailer$h ~headerは、
`~trailer節$内に送信される見込みが高い`~field$を指示するために送信され得る
— それは、［
内容を処理する前に，それらの受領に対し準備すること
］を`受信者$たちに許容する。
これは例えば、
次を指示する`~field名$がある場合にも有用になり得る
⇒
内容を受信するに伴い，動的に~checksumを計算してから、
当の~trailer~field値の受領に際し即時に検査するべきである。
◎
The "Trailer" header field (Section 6.6.2) can be sent to indicate fields likely to be sent in the trailer section, which allows recipients to prepare for their receipt before processing the content. For example, this could be useful if a field name indicates that a dynamic checksum should be calculated as the content is received and then immediately checked upon receipt of the trailer field value.
</p>

<p>
同じ名前を伴う`~trailer$たちは、
`~header$と同様に，受信した順序で処理される。
同じ名前を伴う複数個の~trailer`~field行l$による意味論は、
~memberの~listに複数個の値を付加するのと等価になる。
~trailerのうち，同じ~messageの間に複数個`生成-$され得るものは、
`~listに基づく~field$として定義されなければナラナイ
— 各~member値は、
`~field行l$が受信されるごとに 1 度~限り【その場限りで】処理されるとしても。
◎
Like header fields, trailer fields with the same name are processed in the order received; multiple trailer field lines with the same name have the equivalent semantics as appending the multiple values as a list of members. Trailer fields that might be generated more than once during a message MUST be defined as a list-based field even if each member value is only processed once per field line received.
</p>

<p>
`受信者$は、
~messageの終端-時に，受信した`~trailer$たちが成す集合を［
`~header$たちと類似な（かつ別々な），一連の［［
名前, 値
］が成す~pair
］が成す~data構造
］として扱ってもヨイ。
`~trailer節$における利用が意図される`~field$に対しては、
追加的な処理として期待されるものがあれば，当の~field仕様の中で定義できる。
◎
At the end of a message, a recipient MAY treat the set of received trailer fields as a data structure of name/value pairs, similar to (but separate from) the header fields. Additional processing expectations, if any, can be defined within the field specification for a field intended for use in trailers.
</p>

			</section>
		</section>
		<section id="message.metadata">
<h3 title="Message Metadata">6.6. ~message~metadata</h3>

<p>
各種`~field$のうち，当の`~message$自身を述べるもの
— ~messageが［
いつ／どう
］`生成-$されたかなど —
は、
要請, 応答どちらにも出現し得る。
◎
Fields that describe the message itself, such as when and how the message has been generated, can appear in both requests and responses.
</p>

			<section id="field.date">
<h4>6.6.1. `Date^h</h4>

<p>
`Date^h ~headerは、
~messageが
<dfn id="origination-date">出生した日付時刻</dfn>
を表現する
— その意味論は、
`5322/3.6.1$rfc に定義される `Origination Date Field^en （ `orig-date^p ）と同じである。
その`~field値$は：
◎
The "Date" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in Section 3.6.1 of [RFC5322]. The field value is an HTTP-date, as defined in Section 5.6.7.
</p>

<pre class="bnf">
`Date@p
	= `HTTP-date$p
</pre>

<div class="example">
<p>
例：
◎
An example is
</p>

<pre class="lang-http">
Date: Tue, 15 Nov 1994 08:12:31 GMT
</pre>
</div>

<p>
`送信者$は、
`Date^h ~headerを`生成-$するときは，その`~field値$として［
~message生成の日付時刻に可用な，最良な近似
］を`生成-$するベキである。
日時は、
理論~上は，`内容$を`生成-$する~~直前の瞬間を表現する~OUGHT。
実施においては、
送信者は，~message出生時の間における どの時点でも日時~値を`生成-$できる。
◎
A sender that generates a Date header field SHOULD generate its field value as the best available approximation of the date and time of message generation. In theory, the date ought to represent the moment just before generating the message content. In practice, a sender can generate the date value at any time during message origination.
</p>

<div class="p">
<p>
`時計$を備えている`生成元~server$は、
応答の`状態s~code$に応じて：
◎
An origin server with a clock (as defined in Section 5.6.7)＼
</p>
<ul class="switch">
	<li>
［
`2xx$st ／ `3xx$st ／ `4xx$st
］である場合
⇒
応答~内に `Date^h ~headerを`生成-$しなければナラナイ。
◎
MUST generate a Date header field in all 2xx (Successful), 3xx (Redirection), and 4xx (Client Error) responses,＼
</li>
	<li>
［
`1xx$st ／ `5xx$st
］である場合
⇒
応答~内に `Date^h ~headerを`生成-$してもヨイ。
◎
and MAY generate a Date header field in 1xx (Informational) and 5xx (Server Error) responses.
</li>
</ul>
</div>

<p>
`時計$を備えていない`生成元~server$は、
`Date^h ~headerを`生成-$してはナラナイ。
◎
An origin server without a clock MUST NOT generate a Date header field.
</p>

<p>
`時計$を備えている`受信者$は、
受信した`応答~message$に：
◎
↓</p>
<ul>
	<li>
`Date^h ~headerが無い場合
⇒
応答を［
~cacheする／`下流$へ回送する
］ときには、
受信した時刻を記録して，応答の`~header節$に［
その時刻を与える `Date^h ~header
］を付加しなければナラナイ。
◎
A recipient with a clock that receives a response message without a Date header field MUST record the time it was received and append a corresponding Date header field to the message's header section if it is cached or forwarded downstream.
</li>
	<li>
`Date^h ~headerは在るが，その値は妥当でない場合
⇒
その値を応答を受信した時刻に置換してもヨイ。
◎
A recipient with a clock that receives a response with an invalid Date header field value MAY replace that value with the time that response was received.
</li>
</ul>

<p>
`~UA$は、
要請~内に `Date^h ~headerを送信してもヨイ
— 一般には、
~serverにとって有用な情報を伝達するものと予見される場合に限られるが。
例えば，~HTTPの~customな応用は、［
~serverが［
利用者からの要請の解釈
］を［
~UAと~serverにおける時計の相違
］に基づいて調整する
］ことが予期される場合には，
`Date^h を伝達することもあろう。
◎
A user agent MAY send a Date header field in a request, though generally will not do so unless it is believed to convey useful information to the server. For example, custom applications of HTTP might convey a Date if the server is expected to adjust its interpretation of the user's request based on differences between the user agent and server clocks.
</p>

			</section>
			<section id="field.trailer">
<h4>6.6.2. `Trailer^h</h4>

<p>
`Trailer^h ~headerは、
送信者が［
同じ~messageの中に`~trailer$として送信するもの
］と見越している，`~field名$の~listを供する。
これは、［
`内容$の処理を開始する前に，指示された~metadataの受領に対し準備する
］ことを受信者に許容する。
◎
The "Trailer" header field provides a list of field names that the sender anticipates sending as trailer fields within that message. This allows a recipient to prepare for receipt of the indicated metadata before it starts processing the content.
</p>

<pre class="bnf">
`Trailer@p
	= #`field-name$p
</pre>

<p>
例えば，送信者は、［
`内容$が~stream化されるに伴い，その署名が算出され、
最終-署名を`~trailer$として供することになる
］ことを指示するかもしれない。
受信者は、
`内容$を受信するに伴い，その場で同じ検査を遂行できるようになる。
◎
For example, a sender might indicate that a signature will be computed as the content is being streamed and provide the final signature as a trailer field. This allows a recipient to perform the same check on the fly as it receives the content.
</p>

<p>
~message内に`~trailer$を`生成-$しようと意図する`送信者$は、
当の~messageの`~header節$内に `Trailer$h ~headerを`生成-$して，
そのような`~field$が`~trailer節$内に在るかもしれないことを指示するベキである。
◎
A sender that intends to generate one or more trailer fields in a message SHOULD generate a Trailer header field in the header section of that message to indicate which fields might be present in the trailers.
</p>

<p>
ある`媒介者$が通過中の`~trailer節$を破棄する場合、
`Trailer$h ~fieldが，［
どの~metadataが失われたかについて，~hintを供する
］こともある
— `Trailer^h の送信者が，［
当の【その~field値に挙げられた】名前の~fieldを送信すること
］に常に従い続ける保証は無いが。
【したがって、~trailerを媒介者が破棄したか送信者が送信しなかったかは，この~hintからは依拠-可能に判別できない。】
◎
If an intermediary discards the trailer section in transit, the Trailer field could provide a hint of what metadata was lost, though there is no guarantee that a sender of Trailer will always follow through by sending the named fields.
</p>

			</section>
		</section>
	</section>
	<section id="routing">
<h2 title="Routing HTTP Messages">7. ~HTTP~messageの~route法</h2>

【この節は、`別~pageにて＠~HTTPsem#routing$。】

	</section>
	<section id="representation.data.and.metadata">
<h2 title="Representations">8. 表現~dataと表現~metadata</h2>

【この節は、`別~pageにて＠~HTTPsem#representation.data.and.metadata$。】

	</section>
	<section id="methods">
<h2 title="Methods">9. ~method</h2>

【この節は、`別~pageにて＠~HTTPsem#methods$。】

	</section>
	<section id="context">
<h2 title="Message Context">10. ~message文脈</h2>

【この節は、`別~pageにて＠~HTTPsem#context$。】

	</section>
	<section id="authentication">
<h2 title="HTTP Authentication">11. ~HTTP認証</h2>

【この節は、`別~pageにて＠~HTTPsem#authentication$。】

	</section>
	<section id="content.negotiation">
<h2 title="Content Negotiation">12. 内容~折衝</h2>

【この節は、`別~pageにて＠~HTTPsem#content.negotiation$。】

	</section>
	<section id="conditional.requests">
<h2 title="Conditional Requests">13. 条件付き要請</h2>

【この節は、`別~pageにて＠~HTTPsem#conditional.requests$。】

	</section>
	<section id="range.requests">
<h2 title="Range Requests">14. 範囲~要請</h2>

【この節は、`別~pageにて＠~HTTPsem#range.requests$。】

	</section>
	<section id="status.codes">
<h2 title="Status Codes">15. 状態s~code</h2>

【この節は、`別~pageにて＠~HTTPsem#status.codes$。】

	</section>
	<section id="extending">
<h2 title="Extending HTTP">16. ~HTTPの拡張-法</h2>

<p>
~HTTPは、［
新たな~versionを導入することなく，~protocolに能力を導入する
］ために利用できる汎用な拡張~地点を いくつか定義する
— それらには、［
~method,
状態s~code,
~field名
］なども含まれる。
更には、
定義-済み~fieldの中にも拡張能を成す地点がある
— 認証~schemeや`~cache指令$など。
~HTTPの意味論には~versionは無いので、
これらの拡張~地点は持続的である
— 利用-中にある~protocolの~versionは、
それらの意味論には影響しない。
◎
HTTP defines a number of generic extension points that can be used to introduce capabilities to the protocol without introducing a new version, including methods, status codes, field names, and further extensibility points within defined fields, such as authentication schemes and cache directives (see Cache-Control extensions in Section 5.2.3 of [CACHING]). Because the semantics of HTTP are not versioned, these extension points are persistent; the version of the protocol in use does not affect their semantics.
</p>

<p>
~versionに依存しない拡張は、
利用-中にある 特定の~protocol~version［
に依存する／
と相互作用する
］ことは忌避される。
これを避けれない場合、
当の拡張は，各~version間でどう相互運用し得るかについて注意深い考慮を与える必要がある。
◎
Version-independent extensions are discouraged from depending on or interacting with the specific version of the protocol in use. When this is unavoidable, careful consideration needs to be given to how the extension can interoperate across versions.
</p>

<p>
加えて，~HTTPの特定の~versionは、
自前の拡張能を成す地点を備えることもある
— ~HTTP11における`転送~符号法$,
~HTTP2における `SETTINGS^en や~frame種別（ `HTTP/2$r ）など。
これらの拡張~地点は、
それらが生じた~protocolの~versionに特有になる。
◎
Additionally, specific versions of HTTP might have their own extensibility points, such as transfer codings in HTTP/1.1 (Section 6.1 of [HTTP/1.1]) and HTTP/2 SETTINGS or frame types ([HTTP/2]). These extension points are specific to the version of the protocol they occur within.
</p>

<p>
~versionに特有な拡張は、
（~methodや~headerの様な）~versionに依存しない［
仕組み／拡張~地点
］の意味論を上書きし得ず, 改変し得ない
— 当の~protocol要素が明示的にそれを許容していない限り。
例えば，`CONNECT$m ~methodは、
これを許容する。
◎
Version-specific extensions cannot override or modify the semantics of a version-independent mechanism or extension point (like a method or header field) without explicitly being allowed by that protocol element. For example, the CONNECT method (Section 9.3.6) allows this.
</p>

<p>
これらの指針は、［
経路を成す各部が実装する~HTTP~versionが異なる
］ときでも［
~protocolが正しくかつ予測-可能に運用される
］ことを確約する。
◎
These guidelines assure that the protocol operates correctly and predictably, even when parts of the path implement different versions of HTTP.
</p>

		<section id="method.extensibility">
<h3 title="Method Extensibility">16.1. ~methodの拡張能</h3>

			<section id="method.registry">
<h4 title="Method Registry">16.1.1. ~method~registry</h4>

<p>
`~HTTP~method~registry$cite
は、
`要請~method$~token用の名前空間を定義する。
◎
The "Hypertext Transfer Protocol (HTTP) Method Registry", maintained by IANA at &lt;https://www.iana.org/assignments/http-methods&gt;, registers method names.
</p>

<p>
~HTTP~method登録には、
次に挙げる~fieldを含めなければナラナイ
⇒＃
~method名（ `9§ ）,
`安全$かどうか（ "yes" または "no" ）,
`冪等$かどうか（ "yes" または "no" ）,
仕様~textへの~pointer
◎
HTTP method registrations MUST include the following fields:
• Method Name (see Section 9)
• Safe ("yes" or "no", see Section 9.2.1)
• Idempotent ("yes" or "no", see Section 9.2.2)
• Pointer to specification text
</p>

【！https://www.rfc-editor.org/errata/eid5300】

<p>
この名前空間に追加される値は、
`~IETFによる考査$を要する。
◎
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
</p>

			</section>
			<section id="considerations.for.new.methods">
<h4 title="Considerations for New Methods">16.1.2. 新たな~methodに対する考慮点</h4>

<p>
標準~化された~methodは、
汎用である
— すなわち，それらは、
特定0の［
`~MIME型$／資源の種類／応用
］のみならず，どの資源にも適用-可能になり得る。
そのような新たな~methodは、［
単独の［
応用／~data形式
］］に特有ではない文書~内に登録することが選好される
— 直交的な技術は、
直交的な仕様に~~価するので。
◎
Standardized methods are generic; that is, they are potentially applicable to any resource, not just one particular media type, kind of resource, or application. As such, it is preferred that new methods be registered in a document that isn't specific to a single application or data format, since orthogonal technologies deserve orthogonal specification.
</p>

<p>
~messageの構文解析（ `6§ ）は，（ `HEAD$m に対する応答は別として）~methodの意味論に依存しない必要があるので、
新たな~methodの定義は，［
要請, 応答
］どちらの~messageにおいても［
構文解析~algoを変更する／`内容$が在ることを禁制する
］ことはできない。
新たな~methodの定義は、［
`Content-Length$h ~headerの値に "`0^c" を要求する
］ことにより，［
長さ 0 の`内容$のみが許容される
］よう指定できる。
◎
Since message parsing (Section 6) needs to be independent of method semantics (aside from responses to HEAD), definitions of new methods cannot change the parsing algorithm or prohibit the presence of content on either the request or the response message. Definitions of new methods can specify that only a zero-length content is allowed by requiring a Content-Length header field with a value of "0".
</p>

<p>
同様に，新たな~methodは、
`要請~target$に［
`CONNECT$m ／ `OPTIONS$m
］用に許容される特別な形［
<code>`host$p:`port$p</code> ／ ~asterisk（ "`*^c" ）
］（ `7.1§ ）を利用できない。
`~target~URI$用には、
`絶対~形$による全部的な~URIが必要になる
— すなわち，次のいずれかを意味する
⇒＃
◎
Likewise, new methods cannot use the special host:port and asterisk forms of request target that are allowed for CONNECT and OPTIONS, respectively (Section 7.1). A full URI in absolute form is needed for the target URI, which means either＼
</p>
<ul>
	<li>
要請~targetは、
絶対~形で送信する必要がある
◎
the request target needs to be sent in absolute form＼
</li>
	<li>
~target~URIは、
他の~methodのときと同じ仕方で要請~文脈から構築し直されることになる
◎
or the target URI will be reconstructed from the request context in the same way it is for other methods.
</li>
</ul>

<div class="p">
<p>
新たな~method定義は、
次を指示する必要がある：
◎
A new method definition needs to indicate＼
</p>
<ul>
	<li>
`安全$か？
◎
whether it is safe (Section 9.2.1),＼
</li>
	<li>
`冪等$か？
◎
idempotent (Section 9.2.2),＼
</li>
	<li>
`~cache可能$か？
◎
cacheable (Section 9.2.3),＼
</li>
	<li>
要請の`内容$に結付けられる意味論があるならば、
それは何か？
◎
what semantics are to be associated with the request content (if any), and＼
</li>
	<li>
［
`~header$／`状態s~code$
］の意味論に対し精緻化を為すならば、
それは何か？
◎
what refinements the method makes to header field or status code semantics.＼
</li>
</ul>

<p>
加えて，その定義は、
次も述べる~OUGHT：
◎
＼
</p>
<ul>
	<li>
`~cache可能$である場合、
どの条件~下で，どのように
⇒＃
応答を~cacheに格納できるか？ ／
~cacheを後続な要請を満足するために利用できるか？
◎
If the new method is cacheable, its definition ought to describe how, and under what conditions, a cache can store a response and use it to satisfy a subsequent request.＼
</li>
	<li>
条件付きにできるか？
— できる場合、
条件が ~F に評価されるとき，~serverはどう応答するか？
◎
The new method ought to describe whether it can be made conditional (Section 13.1) and, if so, how a server responds when the condition is false.＼
</li>
	<li>
`部分的な応答$の意味論（ `14.2§ ）用の，何らかの利用はあり得るか？
— その場合、
それも文書化する~OUGHT。
◎
Likewise, if the new method might have some use for partial response semantics (Section 14.2), it ought to document this, too.
</li>
</ul>
</div>

<p class="note">注記：
"`M-^c" から開始する~method名は、
定義しないこと
— その接頭辞は、［
`RFC2774$r によりアテガわれる意味論を有する
］ものと誤解釈され易いので。
◎
Note: Avoid defining a method name that starts with "M-", since that prefix might be misinterpreted as having the semantics assigned to it by [RFC2774].
</p>

			</section>
		</section>
		<section id="status.code.extensibility">
<h3 title="Status Code Extensibility">16.2. 状態s~codeの拡張能</h3>

			<section id="status.code.registry">
<h4 title="Status Code Registry">16.2.1. 状態s~code~registry</h4>

<p>
`状態s~code$番号は、
`~HTTP状態s~code~registry$cite
にて保守され，そこに登録される。
◎
The "Hypertext Transfer Protocol (HTTP) Status Code Registry", maintained by IANA at &lt;https://www.iana.org/assignments/http-status-codes&gt;, registers status code numbers.
</p>

<p>
`状態s~code$の登録には、
次に挙げる~fieldを含めなければナラナイ：
⇒＃
`状態s~code$（ 3 桁）,
短い記述,
仕様~textへの~pointer
◎
A registration MUST include the following fields:
• Status Code (3 digits)
• Short Description
• Pointer to specification text
</p>

<p>
~HTTP状態s~code名前空間に追加される値は、
`~IETFによる考査$を要する。
◎
Values to be added to the HTTP status code namespace require IETF Review (see [RFC8126], Section 4.8).
</p>

			</section>
			<section id="considerations.for.new.status.codes">
<h4 title="Considerations for New Status Codes">16.2.2. 新たな状態s~codeに対する考慮点</h4>

<p>
ある応答~用に表出することが必要yな意味論が，
現在の状態s~codeにより定義されるものでないときは、
新たな状態s~codeを登録できる。
`状態s~code$は、
汎用である
— すなわち，それらは、
特定0の［
`~MIME型$／資源の種類／~HTTPの応用
］のみならず，どの`資源$にも適用-可能になり得る。
そのようなわけで、
新たな状態s~codeは，［
単独の応用
］に特有でない文書に登録されることが選好される。
◎
When it is necessary to express semantics for a response that are not defined by current status codes, a new status code can be registered. Status codes are generic; they are potentially applicable to any resource, not just one particular media type, kind of resource, or application of HTTP. As such, it is preferred that new status codes be registered in a document that isn't specific to a single application.
</p>

<p>
新たな`状態s~code$は、
定義-済みな`~class$のうちいずれかに属することが要求される。
既存の構文解析器が`応答~message$を処理できるようにするため、
新たな状態s~codeは，`内容$を許容する必要がある
— `内容$を長さ 0 に義務化することはできるが。
◎
New status codes are required to fall under one of the categories defined in Section 15. To allow existing parsers to process the response message, new status codes cannot disallow content, although they can mandate a zero-length content.
</p>

<p>
［
まだ広く配備されてない，新たな状態s~code
］用の提案は、［
登録されることになる明瞭な総意が得られる
］までは［
~code用に特定の番号を割振ること
］を避ける~OUGHT
— 早期の草案は、
代わりに，提案される状態s~codeの`~class$を尚早に番号を消費することなく指示する表記法
— "`4NN^st0" や, "`3N0^st0 〜 `3N9^st0" など —
を利用できる。
◎
Proposals for new status codes that are not yet widely deployed ought to avoid allocating a specific number for the code until there is clear consensus that it will be registered; instead, early drafts can use a notation such as "4NN", or "3N0" .. "3N9", to indicate the class of the proposed status code(s) without consuming a number prematurely.
</p>

<p>
新たな`状態s~code$の定義は、
以下について［
説明する／指定する
］~OUGHT：
◎
↓</p>
<ul>
	<li>
要請が［
その状態s~codeを包含する応答を~~生じさせる
］ための条件（例：［
要請~header／~method
］の組合nなど）。
◎
The definition of a new status code ought to explain the request conditions that would cause a response containing that status code (e.g., combinations of request header fields and/or method(s)) along with＼
</li>
	<li>
`応答~header$との依存関係
— 例えば，その状態s~codeを応答に利用するときに
⇒＃
要求される~fieldは何か？／
どの~fieldが意味論を改変し得るか？／
意味論が更に精緻化される~fieldは何か？
◎
any dependencies on response header fields (e.g., what fields are required, what fields can modify the semantics, and what field semantics are further refined when used with the new status code).
</li>
	<li>
既定では、
状態s~codeは，当の応答が応対した要請に限り適用される。
状態s~codeの適用能が，より広い視野
— 例えば，当の資源へのすべての要請／~serverへのすべての要請 —
に及ぶ場合、
そのことを明示的に指定しなければならない。
そうする場合、
新たな状態s~codeを解さない~clientもあるかもしれないので，［
すべての~clientに対し，より広い視野にも一貫して適用されるものと期待できる
］とは限らないことを注記するべきである。
◎
By default, a status code applies only to the request corresponding to the response it occurs within. If a status code applies to a larger scope of applicability -- for example, all requests to the resource in question or all requests to a server -- this must be explicitly specified. When doing so, it should be noted that not all clients can be expected to consistently apply a larger scope because they might not understand the new status code.
</li>
	<li>
<p>
最終-状態s~code【すなわち， `1xx$st0 以外】である場合、
`経験的に~cache可能$かどうか。
◎
The definition of a new final status code ought to specify whether or not it is heuristically cacheable.＼
</p>

<p>
`最終-応答$は、
明示的な`鮮度~情報$を伴うならば，~cacheできることに注意。
明示的な`鮮度~情報$を伴わない応答であっても、［
その状態s~codeが`経験的に~cache可能$であるものと定義されている
］ならば，~cacheすることが許容される。
同様に，状態s~codeの定義は、
`must-understand$sdir `~cache指令$が利用されている場合には，
~cacheの挙動に拘束を設置できる。
更なる情報は `CACHING$r を見よ。
◎
Note that any response with a final status code can be cached if the response has explicit freshness information. A status code defined as heuristically cacheable is allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior if the must-understand cache directive is used. See [CACHING] for more information.
</p>
	</li>
	<li>
`内容$には、
識別される資源（ `6.4.2§ ）への何らかの結付けが含意されるかどうか。
◎
Finally, the definition of a new status code ought to indicate whether the content has any implied association with an identified resource (Section 6.4.2).
</li>
</ul>

			</section>
		</section>
		<section id="fields.extensibility">
<h3 title="Field Extensibility">16.3. ~fieldの拡張能</h3>

<p>
~HTTPの拡張能を成す地点として最も広く利用されているのは、
新たな［
~header／~trailer
］の定義である。
◎
HTTP's most widely used extensibility point is the definition of new header and trailer fields.
</p>

<div class="p">
<p>
新たな`~field$は、
次に挙げるいくつかを行うように定義できる：
◎
New fields can be defined such that,＼
</p>
<ul>
	<li>
`受信者$により解されるときの［
以前に定義された`~field$の解釈
］を［
上書きする／増強する
］。
◎
when they are understood by a recipient, they override or enhance the interpretation of previously defined fields,＼
</li>
	<li>
要請を評価する際の`事前条件$を定義する。
◎
define preconditions on request evaluation, or＼
</li>
	<li>
応答の意味を精緻化する。
◎
refine the meaning of responses.
</li>
</ul>
</div>

<p>
しかしながら，ある~fieldを定義しても、
その［
配備／受信者による認識
］は保証されない。
ほとんどの~fieldは、
受信者が認識しない~fieldを安全に無視できる（が`下流$へ回送する）とする期待の下で設計される。
他にも、
所与の~fieldを解する送信者の能が，それに先立つ通信により指示される事例もある
— たぶん，先立つ~message内に送信者が送信した［
~protocol~version／~fieldたち
］により、
あるいは，特定の~MIME型の利用により。
同様に，~support有無の直な検分は、［
`OPTIONS$m 要請を通して／
定義-済みな周知な~URI【 `/.well-known/^c 】 `RFC8615$r とヤリトリすることにより
］アリかもしれない
— そのような検分が，当の~fieldを導入するに伴って定義された場合には。
◎
However, defining a field doesn't guarantee its deployment or recognition by recipients.＼
Most fields are designed with the expectation that a recipient can safely ignore (but forward downstream) any field not recognized.＼
In other cases, the sender's ability to understand a given field might be indicated by its prior communication, perhaps in the protocol version or fields that it sent in prior messages, or its use of a specific media type.＼
Likewise, direct inspection of support might be possible through an OPTIONS request or by interacting with a defined well-known URI [RFC8615] if such inspection is defined along with the field being introduced.
</p>

			<section id="fields.registry">
<h4 title="Field Name Registry">16.3.1. ~field名~registry</h4>

<p>
`~HTTP~field名~registry$cite
が，~HTTP`~field名$用の名前空間を定義する。
◎
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" defines the namespace for HTTP field names.
</p>

<p>
どの主体も~HTTP`~field$の登録を要請できる。
新たな~HTTP`~field$を作成するときに織り込む考慮点については、
`16.3.2§ を見よ。
◎
Any party can request registration of an HTTP field. See Section 16.3.2 for considerations to take into account when creating a new HTTP field.
</p>

<p>
`~field名$の登録~要請は、［
`~HTTP~field名~registry$cite
に所在する指示書きに従うか，
"ietf-http-wg@w3.org" ~mailing-list宛に~emailを送信する
］ことにより為せる。
◎
The "Hypertext Transfer Protocol (HTTP) Field Name Registry" is located at &lt;https://www.iana.org/assignments/http-fields/&gt;. Registration requests can be made by following the instructions located there or by sending an email to the "ietf-http-wg@w3.org" mailing list.
</p>

<p>
`~field名$は、
`指名された専門家＠~RFCx/rfc8126.html#section-5$
（ IESG, または その代表者により任命される）による助言の下で登録される。
位置付け `恒久的^i を伴う`~field$は、
仕様~化が要求される（ `8126/4.6$rfc ）。
◎
Field names are registered on the advice of a designated expert (appointed by the IESG or their delegate). Fields with the status 'permanent' are Specification Required ([RFC8126], Section 4.6).
</p>

<p>
登録~要請は、
次に挙げる情報からなる：
◎
Registration requests consist of the following information:
</p>
<dl>
	<dt>
`Field name:^en
（~field名）
</dt>
	<dd>
要請された`~field名$。
`field-name$p 構文に適合しなければナラナイ
— それは、［
英字, 数字, ~hyphen ('-')
］文字のみからなる, かつ最初の文字は英字
に制約されるベキである。
◎
The requested field name. It MUST conform to the field-name syntax defined in Section 5.1, and it SHOULD be restricted to just letters, digits, and hyphen ('-') characters, with the first character being a letter.
</dd>

	<dt>
`Status:^en
（位置付け）
</dt>
	<dd>
次に挙げるいずれか
⇒＃
`恒久的^i（ `permanent^en ）／
`暫定的^i（ `provisional^en ）／
`非推奨d^i（ `deprecated^en ）／
`廃用d^i（ `obsoleted^en ）
◎
"permanent", "provisional", "deprecated", or "obsoleted".
</dd>

	<dt>
`Specification document(s):^en
（仕様~文書）
</dt>
	<dd>
当の`~field$を指定する文書への参照。
文書の複製を検索取得するために利用できる~URIを含める方が好ましい。
`暫定的^i な登録~用には、
任意選択であるが，奨励される。
関連な各~節の指示も含ませれるが、
要求されてはいない。
◎
Reference to the document that specifies the field, preferably including a URI that can be used to retrieve a copy of the document. Optional but encouraged for provisional registrations. An indication of the relevant section(s) can also be included, but is not required.
</dd>
</dl>

<div class="p">
<p>
および，任意選択で、
次に挙げるものも：
</p>
<dl>
	<dt>
`Comments:^en
（~comment）
</dt>
	<dd>
追加的な情報
— 予約-済みかどうかなど
</dd>
</dl>
◎
And optionally:
Comments: Additional information, such as about reserved entries.
</div>

<p>
専門家（たち）は、
~communityとの協議の下で，
~registry内に収集されることになる追加的な`~field$を定義できる。
◎
The expert(s) can define additional fields to be collected in the registry, in consultation with the community.
</p>

<p>
標準により定義される名前の位置付けは `恒久的^i とする。
他の名前も［
~communityとの協議の下で、
当の専門家（たち）が，それが利用-中にあることを見出した
］ならば、
`恒久的^i として登録できる。
他の名前は、
`暫定的^i として登録されるべきである。
◎
Standards-defined names have a status of "permanent". Other names can also be registered as permanent if the expert(s) finds that they are in use, in consultation with the community. Other names should be registered as "provisional".
</p>

<p>
専門家（たち）は、
`暫定的^i な~entryを除去できる
— ~communityとの協議の下で、
利用-中にあるものでないことを見出したならば。
当の専門家（たち）は、
`暫定的^i な~entryの位置付けを，いつでも `恒久的^i に変更できる。
◎
Provisional entries can be removed by the expert(s) if -- in consultation with the community -- the expert(s) find that they are not in use. The expert(s) can change a provisional entry's status to permanent at any time.
</p>

<p>
第三者-主体（当の専門家（たち）も含む）も，名前を登録できることに注意
— 当の専門家（たち）が［
未登録な名前が、
広く配備されていて，さもなければ適時な方式で登録される見込みが低い
］と決定した場合には。
◎
Note that names can be registered by third parties (including the expert(s)) if the expert(s) determines that an unregistered name is widely deployed and not likely to be registered in a timely manner otherwise.
</p>

			</section>
			<section id="considerations.for.new.fields">
<h4 title="Considerations for New Fields">16.3.2. 新たな~fieldに対する考慮点</h4>

<p>
~HTTP［
~header／~trailer
］は、
この~protocol用の拡張~地点として広く利用されている。
それらは場当的な流儀でも利用され得るが、
より広い利用-用に意図される~fieldは，［
相互運用能を確保するため，注意深く文書化される
］必要がある。
◎
HTTP header and trailer fields are a widely used extension point for the protocol. While they can be used in an ad hoc fashion, fields that are intended for wider use need to be carefully documented to ensure interoperability.
</p>

<p>
特に，新たな`~field$ %~field を定義している仕様の策定者には、
次に挙げる側面を考慮して，それらを適切になる所で文書化することを勧める：
◎
In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects:
</p>

<ul>
	<li>
%~field は、
どの条件の下で利用できるか？
— 例：
応答のみ ／
要請のみ ／
すべての`~message$ ／
特定0の`要請~method$に対する応答のみ,
等々。
◎
Under what conditions the field can be used; e.g., only in responses or requests, in all messages, only on responses to a particular request method, etc.
</li>
	<li>
%~field の意味論は、
それを利用する文脈
— ある種の［
`要請~method$／`状態s~code$
］との伴用など —
の下で，更に精緻化されるか？
◎
Whether the field semantics are further refined by their context, such as their use with certain request methods or status codes.
</li>
	<li>
%~field が伝達する情報の適用能が及ぶ視野。
既定では、
`~field$は，それに結付けられた~messageに限り適用されるが、
応答~fieldには，資源の表現すべてに
— あるいは、
資源~自身にも, もっと広い視野にすら —
適用されるよう設計されているものもある。
応答~fieldの視野を拡げる仕様は、［
`内容~折衝$／適用能が及ぶ期間／
（一部の事例では）~multi-tenant【複数の事業者（店子）から共有される】~server配備
］などの課題を注意深く考慮する必要がある。
◎
The scope of applicability for the information conveyed. By default, fields apply only to the message they are associated with, but some response fields are designed to apply to all representations of a resource, the resource itself, or an even broader scope. Specifications that expand the scope of a response field will need to carefully consider issues such as content negotiation, the time period of applicability, and (in some cases) multi-tenant server deployments.
</li>
	<li>
`媒介者$は、
どの条件の下で，
%~field の`~field値$を［
挿入する／削除する／改変する
］ことが許容されるか？
◎
Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
</li>
	<li>
%~field は、
`~trailer節$内に許容-可能か？
— 既定では、
許容されない（ `6.5.1§ を見よ）。
◎
If the field is allowable in trailers; by default, it will not be (see Section 6.5.1).
</li>
	<li>
%~field の`~field名$を `Connection$h ~header内に~listすることは、
適切になるか, あるいは要求されるか？
（すなわち， %~field は`隣点間$か？
— `7.6.1§ を見よ）。
◎
Whether it is appropriate or even required to list the field name in the Connection header field (i.e., if the field is to be hop-by-hop; see Section 7.6.1).
</li>
	<li>
%~field は、
~privacyに関係する~dataの開示など，追加的な~security考慮点を導入するか？
◎
Whether the field introduces any additional security considerations, such as disclosure of privacy-related data.
</li>
</ul>

<p>
要請~headerには、
既定の挙動が適切にならない場合に文書化される必要がある，追加的な考慮点がある：
◎
Request header fields have additional considerations that need to be documented if the default behavior is not appropriate:
</p>
<ul>
	<li>
［
`Vary$h 応答~header内に， %~field の`~field名$を~listする
］ことは適切になるか？
（例： 要請~headerが，`生成元~server$の内容~選定~algoにより利用されるときなど）。
◎
If it is appropriate to list the field name in a Vary response header field (e.g., when the request header field is used by an origin server's content selection algorithm; see Section 12.5.5).
</li>
	<li>
%~field は、
`PUT$m 要請にて受信されたとき，【資源とともに】格納されるものと意図されるか？
◎
If the field is intended to be stored when received in a PUT request (see Section 9.3.4).
</li>
	<li>
%~field は、
要請を自動的に~redirectするとき，~securityの懸念に因り除去される~OUGHTか？
（ `3xx§st0 を見よ）。
◎
If the field ought to be removed when automatically redirecting a request due to security concerns (see Section 15.4).
</li>
</ul>

				<section id="considerations.for.new.field.names">
<h5 title="Considerations for New Field Names">16.3.2.1. 新たな~field名に対する考慮点</h5>

<p>
新たな`~field$を定義している仕様の策定者には、
短いが記述的な`~field名$を選ぶよう勧める。
短い名前は、
無用な~data伝送を避ける。
記述的な名前は、
より広く利用されているかもしれない他の名前との混同や “名前の独り占め” を避ける。
◎
Authors of specifications defining new fields are advised to choose a short but descriptive field name. Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on names that might have broader uses.
</p>

<p>
そのため，限定的に利用される~field（単独の［
応用／利用事例
］に限定される~headerなど）には、
その用途（または略語）を接頭辞として含む名前を利用することが奨励される。
例えば， “Description” ~fieldが必要な応用 “Foo” は、
"`Foo-Desc^c" を利用することになろう
— "`Description^c" では汎用に過ぎ， "`Foo-Description^c" では無用に長いので。
◎
To that end, limited-use fields (such as a header confined to a single application or use case) are encouraged to use a name that includes that use (or an abbreviation) as a prefix; for example, if the Foo Application needs a Description field, it might use "Foo-Desc"; "Description" is too generic, and "Foo-Description" is needlessly long.
</p>

<p>
`field-name$p 構文は，どの~token文字も許容するものと定義されているが、
実施においては，
`field-name$p 内に受容する文字に対し制限sを設置する実装もある。
相互運用可能になるよう、
新たな`~field名$は，［
英数字 ／ "`-^c" ／ "`.^c"
］のみからなる, かつ英字から始まるよう，拘束するベキである。
例えば，文字~underscore "`_^c" は、
非~HTTP~gateway~interfaceを通して渡された場合に問題になり得る
（ `17.10§ を見よ）。
◎
While the field-name syntax is defined to allow any token character, in practice some implementations place limits on the characters they accept in field-names. To be interoperable, new field names SHOULD constrain themselves to alphanumeric characters, "-", and ".", and SHOULD begin with a letter. For example, the underscore ("_") character can be problematic when passed through non-HTTP gateway interfaces (see Section 17.10).
</p>

<p>
`~field名$には、
"`X-^c" を接頭しない~OUGHT
— 更なる情報は `BCP178$r を見よ。
◎
Field names ought not be prefixed with "X-"; see [BCP178] for further information.
</p>

<p>
`~field名$には、
他の接頭辞が利用されることもある。
例えば、
多くの内容~折衝~headerには， "`Accept-^c" が利用されている／
"`Content-^c" は， `6.4§ に説明したように利用されている。
これらの接頭辞は、
`~field$の目的を認識する援助でしかなく，自動的な処理を誘発することはない。
◎
Other prefixes are sometimes used in HTTP field names; for example, "Accept-" is used in many content negotiation headers, and "Content-" is used as explained in Section 6.4. These prefixes are only an aid to recognizing the purpose of a field and do not trigger automatic processing.
</p>

<p class="trans-note">【
とは言え、
`禁止~要請~header$の "`Sec-^c" のように，
（ある~platformにおける）
他の仕様において特別な要件が一律に課される接頭辞もある。
】</p>

				</section>
				<section id="considerations.for.new.field.values">
<h5 title="Considerations for New Field Values">16.3.2.2. 新たな~field値に対する考慮点</h5>

<p>
新たな~HTTP~fieldの定義における~majorな~taskは、
`~field値$の構文の仕様である：
`送信者$は何を`生成-$するべきで，`受信者$は受信した~field値から意味論をどう推定するべきか？
◎
A major task in the definition of a new HTTP field is the specification of the field value syntax: what senders should generate, and how recipients should infer semantics from what is received.
</p>

<p>
策定者には、
（要求されてはいないが）［
この仕様あるいは `RFC8941$r
］における~ABNF規則を利用して，新たな~field値の構文を定義することが奨励される。
◎
Authors are encouraged (but not required) to use either the ABNF rules in this specification or those in [RFC8941] to define the syntax of new field values.
</p>

<p>
策定者には、
複数個の`~field行l$が`結合-$されたときの影響iを，注意深く考慮することを勧める（ `5.3§ を見よ）。
`送信者$は，誤って複数個の値を送信するかもしれず、［
媒介者／~HTTP~library
］は，自動的に結合nを遂行し得るので、
これは，すべての~field値に
— `単数~field$の値であっても —
適用される。
◎
Authors are advised to carefully consider how the combination of multiple field lines will impact them (see Section 5.3). Because senders might erroneously send multiple values, and both intermediaries and HTTP libraries can perform combination automatically, this applies to all field values -- even when only a single value is anticipated.
</p>

<p>
したがって，策定者には、
~field~dataの中の~commaが~list値を区切る~commaと混同されないことを確保するため，
~commaを包含する値を何かで区切るか符号化することを勧める
（例：
`quoted-string$p 規則 ／
`RFC8941$r の`~sf文字列$ ~data型／
当の~fieldに特有な符号化法）。
◎
Therefore, authors are advised to delimit or encode values that contain commas (e.g., with the quoted-string rule of Section 5.6.4, the String data type of [RFC8941], or a field-specific encoding). This ensures that commas within field data are not confused with the commas that delimit a list value.
</p>

<p>
例えば，
`Content-Type$h の~field値は、
`quoted-string$p の内側でしか~commaを許容しないので，
複数個の値が在るときでも依拠-可能に構文解析できる。
`Location$h の~field値は、
模倣されるべきでない反例を供する
— ~URIは~commaを内包し得るので、
~commaを内包する 1 個の値が 2 個の値でないことを依拠-可能に判別するのはアリでない。
◎
For example, the Content-Type field value only allows commas inside quoted strings, which can be reliably parsed even when multiple values are present. The Location field value provides a counter-example that should not be emulated: because URIs can include commas, it is not possible to reliably distinguish between a single value that includes a comma from two values.
</p>

<p>
加えて，`単数~field$の策定者には、
複数個の~memberが在るときに，~messageを扱う方法を文書化するよう勧める
（当の~fieldを無視するのが既定としてイミを成し得るかもしれないが、
常に当を得た選択になるとは限らない）。
◎
Authors of fields with a singleton value (see Section 5.5) are additionally advised to document how to treat messages where the multiple members are present (a sensible default would be to ignore the field, but this might not always be the right choice).
</p>

				</section>
			</section>
		</section>
		<section id="auth.scheme.extensibility">
<h3 title="Authentication Scheme Extensibility">16.4. 認証~schemeの拡張能</h3>

			<section id="auth.scheme.registry">
<h4 title="Authentication Scheme Registry">16.4.1. 認証~scheme~registry</h4>

<p>
［
~challenge／`資格証$
］における`認証~scheme$用の名前空間は、
`~HTTP認証~scheme~registry$cite
にて保守され, 定義される。
◎
The "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" defines the namespace for the authentication schemes in challenges and credentials. It is maintained at &lt;https://www.iana.org/assignments/http-authschemes&gt;.
</p>

<p>
各 登録には、
次に挙げる~fieldを含めなければナラナイ
⇒＃
`認証~scheme$名,
仕様~textへの~pointer,
注記（省略可能）
◎
Registrations MUST include the following fields:
• Authentication Scheme Name
• Pointer to specification text
• Notes (optional)
</p>

<p>
この名前空間に追加される値は、
`~IETFによる考査$を要する。
◎
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
</p>

			</section>
			<section id="considerations.for.new.auth.schemes">
<h4 title="Considerations for New Authentication Schemes">16.4.2. 新たな認証~schemeに対する考慮点</h4>

<p>
~HTTP認証~frameworkは、
次に挙げる側面において，新たな`認証~scheme$がどう働得るかについて拘束を課す：
◎
There are certain aspects of the HTTP Authentication framework that put constraints on how new authentication schemes can work:
</p>
<ul>
	<li>
~HTTP認証は、
`~stateless$であることを~~前提にする：
要請を認証するために必要yな，すべての情報が、
その要請~内に供されなければナラナイ
— `~server$が それに先立つ要請を記憶することに依存するのではなく。
下層~接続に［
基づく／束縛される
］認証は、
この仕様の視野から外れる
— それは、［
その接続が、
認証-済み利用者~以外のどの主体からも利用され得ない
］ことを確保する手続きが踏まれない限り，内来的に欠陥があるものとされる（ `3.3§ を見よ）。
◎
HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. Authentication based on, or bound to, the underlying connection is outside the scope of this specification and inherently flawed unless steps are taken to ensure that the connection cannot be used by any party other than the authenticated user (see Section 3.3).
</li>
	<li>
名前 `realm$c の`認証~parameter$は、
`保護~空間$を定義するものとして予約される。
新たな~schemeは、
"`realm^c" をその定義と非~互換な仕方で利用してはナラナイ。
◎
The authentication parameter "realm" is reserved for defining protection spaces as described in Section 11.5. New schemes MUST NOT use it in a way incompatible with that definition.
</li>
	<li>
既存の`認証~scheme$との互換性を得るために， `token68$p 表記法が導入された
— それは、［
`challenge$p／`credentials$p
］ごとに 1 個しか利用できない。
したがって，新たな~schemeは、
代わりに `auth-param$p 構文を利用する~OUGHT
— さもなければ，将来の拡張が不可能になるので。
◎
The "token68" notation was introduced for compatibility with existing authentication schemes and can only be used once per challenge or credential. Thus, new schemes ought to use the auth-param syntax instead, because otherwise future extensions will be impossible.
</li>
	<li>
<p>
［
`challenge$p／`credentials$p
］の構文解析は，この仕様により定義され、
新たな`認証~scheme$は，それを改変できない。
`auth-param$p 構文が利用されるときは、
すべての~parameterが `token$p, `quoted-string$p 両~構文を~supportする~OUGHT。
また，構文上の拘束は、
構文解析-後の（すなわち， `quoted-string$p を処理した後の）`~field値$に対し，定義される~OUGHT。
これは、
`受信者$が，［
すべての`認証~scheme$に適用される，汎用な構文解析器
］を利用できるようにするために必要yである。
◎
The parsing of challenges and credentials is defined by this specification and cannot be modified by new authentication schemes. When the auth-param syntax is used, all parameters ought to support both token and quoted-string syntax, and syntactical constraints ought to be defined on the field value after parsing (i.e., quoted-string processing). This is necessary so that recipients can use a generic parser that applies to all authentication schemes.
</p>

<p class="note">注記：
"`realm^c" ~parameter用の値の構文が `quoted-string$p に制約される事は、
不良な設計の選択であった
— 新たな~parameterに対しては繰返されない。
◎
Note: The fact that the value syntax for the "realm" parameter is restricted to quoted-string was a bad design choice not to be repeated for new parameters.
</p>
	</li>
	<li>
新たな~schemeの定義は、
未知な拡張~parameterの扱いを定義する~OUGHT。
一般に、
“無視しなければならない”
とする規則が
“解さなければならない”
とするよりも選好される
— さもなければ、
旧来の`受信者$が在る下で，新たな~parameterを導入することが難しくなるので。
更には、
新たな~parameterを定義するための施策を述べる方が良い
（ “〜の仕様を更新せよ” や, “この~registryを利用せよ” など）。
◎
Definitions of new schemes ought to define the treatment of unknown extension parameters. In general, a "must-ignore" rule is preferable to a "must-understand" rule, because otherwise it will be hard to introduce new parameters in the presence of legacy recipients. Furthermore, it's good to describe the policy for defining new parameters (such as "update the specification" or "use this registry").
</li>
	<li>
`認証~scheme$は、［
`生成元~server$による認証（すなわち， `WWW-Authenticate$h を利用）／
`~proxy$による認証（すなわち， `Proxy-Authenticate$h を利用）
］に利用できるかどうかを文書化する必要がある。
◎
Authentication schemes need to document whether they are usable in origin-server authentication (i.e., using WWW-Authenticate), and/or proxy authentication (i.e., using Proxy-Authenticate).
</li>
	<li>
<p>
`Authorization$h ~header内に運ばれる`資格証$は，`~UA$に特有なので、
それが出現する要請の視野の下で，~HTTP~cacheに対する `private$sdir 応答`~cache指令$と同じ効果がある。
◎
The credentials carried in an Authorization header field are specific to the user agent and, therefore, have the same effect on HTTP caches as the "private" cache response directive (Section 5.2.2.7 of [CACHING]), within the scope of the request in which they appear.
</p>

<p>
したがって，新たな`認証~scheme$は、
`資格証$を `Authorization$h ~header内に運ばせないことを選ぶ場合
（例：新たに定義される~headerを利用して）、
明示的に，~cachingを許容しない必要がある
— 応答`~cache指令$（例： `private$sdir ）の利用を義務化することにより。
◎
Therefore, new authentication schemes that choose not to carry credentials in the Authorization header field (e.g., using a newly defined header field) will need to explicitly disallow caching, by mandating the use of cache response directives (e.g., "private").
</p>
	</li>
	<li>
［
`Authentication-Info$h, `Proxy-Authentication-Info$h
］その他の，認証に関係する応答~headerを利用している~schemeは、
関係する~securityの考慮点を考慮して文書化する必要がある（ `17.16.4§ を見よ）。
◎
Schemes using Authentication-Info, Proxy-Authentication-Info, or any other authentication related response header field need to consider and document the related security considerations (see Section 17.16.4).
</li>
</ul>

			</section>
		</section>
		<section id="range.unit.extensibility">
<h3 title="Range Unit Extensibility">16.5. 範囲~単位の拡張能</h3>

			<section id="range.unit.registry">
<h4 title="Range Unit Registry">16.5.1. 範囲~単位~registry</h4>

<p>
`~HTTP範囲~単位~registry$cite
にて保守されている~registryは、
`範囲~単位$を与える名前~用の名前空間を定義し，対応する各~仕様を指す。
◎
The "HTTP Range Unit Registry" defines the namespace for the range unit names and refers to their corresponding specifications. It is maintained at &lt;https://www.iana.org/assignments/http-parameters&gt;.
</p>

<p>
~HTTP`範囲~単位$の登録には、
次に挙げる~fieldを含めなければナラナイ
⇒＃
名前,
記述,
仕様~textへの~pointer
◎
Registration of an HTTP Range Unit MUST include the following fields:
• Name
• Description
• Pointer to specification text
</p>

<p>
この名前空間に追加されることになる値は、
`~IETFによる考査$を要する。
◎
Values to be added to this namespace require IETF Review (see [RFC8126], Section 4.8).
</p>

			</section>
			<section id="considerations.for.new.range.units">
<h4 title="Considerations for New Range Units">16.5.2. 新たな範囲~単位に対する考慮点</h4>

<p>
他の`範囲~単位$
— ~p-s-r-r-t, 等々の様な，形式に特有な境界 —
も，~HTTPにおいては応用に特有な目的に利用-可能になり得るが、
実施においては，共通して利用されてはいない。
代替な範囲~単位の実装者は、
それらが［
内容~符号法, 一般用~媒介者
］とどう働くことになるか考慮する~OUGHT。
◎
Other range units, such as format-specific boundaries like pages, sections, records, rows, or time, are potentially usable in HTTP for application-specific purposes, but are not commonly used in practice. Implementors of alternative range units ought to consider how they would work with content codings and general-purpose intermediaries.
</p>

			</section>
		</section>
		<section id="content.coding.extensibility">
<h3 title="Content Coding Extensibility">16.6. 内容~符号法の拡張能</h3>

			<section id="content.coding.registry">
<h4 title="Content Coding Registry">16.6.1. 内容~符号法~registry</h4>

<p>
~IANAにより保守されている
`内容~符号法~registry$cite
は、
`内容~符号法$~名を登録する。
◎
The "HTTP Content Coding Registry", maintained by IANA at &lt;https://www.iana.org/assignments/http-parameters/&gt;, registers content-coding names.
</p>

<p>
`内容~符号法$の登録には、
次に挙げる~fieldを含めなければナラナイ
⇒＃
名前,
記述,
仕様~textへの~pointer
◎
Content coding registrations MUST include the following fields:
• Name
• Description
• Pointer to specification text
</p>

<p>
`内容~符号法の名前$は、
`転送~符号法の名前$
（これも
`内容~符号法~registry$cite
に所在する）
と重合してはナラナイ
— 符号化法の形式変換（`内容~符号法§に定義される各種 圧縮~符号法など）が一致している場合を除き。
◎
Names of content codings MUST NOT overlap with names of transfer codings (per the "HTTP Transfer Coding Registry" located at &lt;https://www.iana.org/assignments/http-parameters/&gt;) unless the encoding transformation is identical (as is the case for the compression codings defined in Section 8.4.1).
</p>

<p>
この名前空間に追加される値は、
`~IETFによる考査$を要する。
また、
`内容~符号法§の目的に適合しなければナラナイ。
◎
Values to be added to this namespace require IETF Review (see Section 4.8 of [RFC8126]) and MUST conform to the purpose of content coding defined in Section 8.4.1.
</p>

			</section>
			<section id="considerations.for.new.content.codings">
<h4 title="Considerations for New Content Codings">16.6.2. 新たな内容~符号法に対する考慮点</h4>

<p>
新たな内容~符号法は、
アリなときは，［
その符号法の形式の中で発見-可能な，省略可能な各種~parameter
］で`自己-記述的$になる~OUGHT
— 通過中に失われるかもしれない，外部の~metadataに依拠するのではなく。
◎
New content codings ought to be self-descriptive whenever possible, with optional parameters discoverable within the coding format itself, rather than rely on external metadata that might be lost during transit.
</p>
			</section>
		</section>
		<section id="upgrade.token.registry">
<h3 title="Upgrade Token Registry">16.7. `Upgrade^h ~token~registry</h3>

<p>
［
`Upgrade$h ~header内の~protocolを識別するために利用される，
`protocol-name$p ~token
］用の名前空間は、
`~HTTP~Upgrade~token~registry$cite
にて保守され，定義される。
◎
The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name tokens used to identify protocols in the Upgrade header field. The registry is maintained at &lt;https://www.iana.org/assignments/http-upgrade-tokens&gt;.
</p>

<p>
登録された各~protocol名には、
連絡~先~情報に加えて，省略可能な［
接続は、
昇格された後 どう処理されるか
］について詳細を述べる仕様たちが成す集合が結付けられる。
◎
Each registered protocol name is associated with contact information and an optional set of specifications that details how the connection will be processed after it has been upgraded.
</p>

<p>
登録は、
“~~申請順（ `First Come First Served^en ）”
（ `8126/4.4$rfc ）
に基づいて行われ，次の規則の~subjectになる：
◎
Registrations happen on a "First Come First Served" basis (see Section 4.4 of [RFC8126]) and are subject to the following rules:
</p>
<ol>
	<li>
一度~登録された `protocol-name$p ~tokenは、
登録されたまま~~恒久的に居残る。
◎
A protocol-name token, once registered, stays registered forever.
</li>
	<li>
`protocol-name$p ~tokenは文字大小無視であるが、
送信者が`生成-$するときは，登録された文字大小が選好される。
◎
A protocol-name token is case-insensitive and registered with the preferred case to be generated by senders.
</li>
	<li>
登録は、
登録に対する責任-主体を命名しなければナラナイ。
◎
The registration MUST name a responsible party for the registration.
</li>
	<li>
登録は、
連絡~窓口を命名しなければナラナイ。
◎
The registration MUST name a point of contact.
</li>
	<li>
登録は、［
その~tokenに結付けられる仕様たちが成す集合
］を命名してもヨイ。
そのような仕様は、
公に可用になる必要はない。
◎
The registration MAY name a set of specifications associated with that token. Such specifications need not be publicly available.
</li>
	<li>
登録は、［
登録の時点でその~tokenに結付けられる［
期待される "`protocol-version$p" ~tokenからなる集合
］］を命名するベキである。
◎
The registration SHOULD name a set of expected "protocol-version" tokens associated with that token at the time of registration.
</li>
	<li>
責任-主体は、
いつでも登録を変更してもヨイ。
~IANAは、
そのような変更~すべての記録-を保って，
要請に応じて，それらを可用にすることになる。
◎
The responsible party MAY change the registration at any time. The IANA will keep a record of all such changes, and make them available upon request.
</li>
	<li>
IESG は、
`protocol$p ~tokenに対する責任-主体を他にアテガってもヨイ。
これは、
通常は，責任-主体に連絡できなくなったときに限られる。
◎
The IESG MAY reassign responsibility for a protocol token. This will normally only be used in the case when a responsible party cannot be contacted.
</li>
</ol>

		</section>
	</section>
	<section id="security.considerations">
<h2 title="Security Considerations">17. ~securityの考慮点</h2>

<p>
この節は、［
開発者／情報~provider／利用者
］向けに，~HTTP意味論, および［
~Internet越しに情報を転送するための，その利用
］に関連な，既知な~securityの懸念を伝えることを~~意図している。
~cache法に関係する考慮点は、
`CACHING$r `~securityの考慮点＠~HTTPcache#security.considerations§にて論じられる。
~HTTP11における~messageの［
構文／構文解析
］に関係する考慮点は、
`HTTP/1.1$r `~securityの考慮点＠~HTTPv1#security.considerations§にて論じられる。
◎
This section is meant to inform developers, information providers, and users of known security concerns relevant to HTTP semantics and its use for transferring information over the Internet. Considerations related to caching are discussed in Section 7 of [CACHING], and considerations related to HTTP/1.1 message syntax and parsing are discussed in Section 11 of [HTTP/1.1].
</p>

<div class="p">
<p>
この節に挙げる考慮点は、
網羅的ではない。
~HTTP意味論に関係する~securityの懸念のほとんどは、
~protocolの~securityではなく，次についてである：
◎
The list of considerations below is not exhaustive. Most security concerns related to HTTP semantics are about＼
</p>
<ul>
	<li>
~server側~応用（~HTTP~interfaceの背後にある~code）の~secure化。
◎
securing server-side applications (code behind the HTTP interface),＼
</li>
	<li>
~HTTPを介して受信される`内容$に対する，~UAによる処理の~secure化。
◎
securing user agent processing of content received via HTTP, or＼
</li>
	<li>
一般における~Internetの~secureな利用。
◎
secure use of the Internet in general,＼
</li>
</ul>

<p>
~URIに対する~securityの考慮点は、
~HTTP運用の根幹を成し，
`URI$r `7§uri にて論じられる。
様々な組織が、
~Web応用における~securityの［
時事的な情報, および 現在の事実調査への~link
］を保守している。
（例： `OWASP$r）。
◎
↑rather than security of the protocol.＼
The security considerations for URIs, which are fundamental to HTTP operation, are discussed in Section 7 of [URI]. Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]).
</p>
</div>

		<section id="establishing.authority">
<h3 title="Establishing Authority">17.1. 権限の確立-法</h3>

<p>
~HTTPは、
`権限的な応答@
（ `authoritative response^en ）の観念に依拠する。
それは、［
`応答~message$の出生時における`~target資源$の状態
］が与えられた下で［
要請に対する，最も適切な応答になる
］ものとして，［
`~target~URI$の中で識別される`生成元~server$
］により（または，の~directionの下で）決定される応答である。
◎
HTTP relies on the notion of an "authoritative response": a response that has been determined by (or at the direction of) the origin server identified within the target URI to be the most appropriate response for that request given the state of the target resource at the time of response message origination.
</p>

<p>
ある登録-済みな名前が `authority$p 成分~内に利用されるとき、
"`http$c" ~URI`~scheme$は，［
`権限的な応答$がどこで見出せるかを決定する
］ときに［
利用者に局所的な名前~解決~service
］に依拠する。
これは、
利用者の［
~network~host~table／
~cacheされる名前／
名前~解決~library
］に対するどの攻撃も，
"`http$c" ~URI用に権限を確立する際の攻撃に繋がることを意味する。
同様に，［
利用者が~DNS（ `Domain Name Service^en ）用に選んだ~server
］, および［
解決の結果を得するときに用いた，~server階層
］は、［
~address対応付けの真正性
］に影響iし得る
— 真正性を改善する仕方の一つには，
DNSSEC（ `DNS Security Extensions^en, `RFC4033$r ）があり、
より~secureな転送~protocol越しに~DNS要請を為すための様々な仕組みもある。
◎
When a registered name is used in the authority component, the "http" URI scheme (Section 4.2.1) relies on the user's local name resolution service to determine where it can find authoritative responses. This means that any attack on a user's network host table, cached names, or name resolution libraries becomes an avenue for attack on establishing authority for "http" URIs. Likewise, the user's choice of server for Domain Name Service (DNS), and the hierarchy of servers from which it obtains resolution results, could impact the authenticity of address mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to improve authenticity, as are the various mechanisms for making DNS requests over more secure transfer protocols.
</p>

<p>
更には、
~IP~addressが得された後に，
"`http$c" ~URI用に権限を確立することは、
Internet Protocol ~route法に対する攻撃に脆弱である。
◎
Furthermore, after an IP address is obtained, establishing authority for an "http" URI is vulnerable to attacks on Internet Protocol routing.
</p>

<div class="p">
<p>
"`https$c" `~scheme$は、
前述したような［
権限を確立する際の，攻撃の~~可能性
］の多くを防ぐ（または少なくとも露呈する）ことを意図している
— ~AND↓ が満たされる限りにおいて：
◎
The "https" scheme (Section 4.2.2) is intended to prevent (or at least reveal) many of these potential attacks on establishing authority, provided that＼
</p>
<ul>
	<li>
折衝される接続は`~secure化$されている。
◎
the negotiated connection is secured and＼
</li>
	<li>
`~client$は、
自身が通信している`~server$の識別情報を［
`~target~URI$の `authority$p 成分に合致するかどうか
］により，適正に検証yしている（ `4.3.4§ ）。
◎
the client properly verifies that the communicating server's identity matches the target URI's authority component (Section 4.3.4).＼
</li>
</ul>

<p>
そのような検証yを正しく実装するのは、
困難なこともある（ `Georgiev$r ）。
◎
Correctly implementing such verification can be difficult (see [Georgiev]).
</p>
</div>

<p>
所与の`生成元~server$用の権限は、
~protocol拡張
— 例えば， `ALTSVC$r —
を通して委任できる。
同様に、
`RFC8336$r の様な~protocol拡張により，［
ある接続に対し権限的と見なされる~server
］たちが成す集合を変更できる。
◎
Authority for a given origin server can be delegated through protocol extensions; for example, [ALTSVC]. Likewise, the set of servers for which a connection is considered authoritative can be changed with a protocol extension like [RFC8336].
</p>

<p>
応答を［
共用~proxy~cacheなどの権限的でない~source
］から供することは、［
処理能や可用性を改善するために有用になる
］ことが多いが，［
当の~sourceを信用できるか、
信用できない応答でも安全に利用できる
］場合までに限られる。
◎
Providing a response from a non-authoritative source, such as a shared proxy cache, is often useful to improve performance and availability, but only to the extent that the source can be trusted or the distrusted response can be safely used.
</p>

<div class="p">
<p>
あいにく、
利用者に権限を通信することは 困難にもなり得る。
例えば，
`~phishing^dfn
は、［
権限に対する利用者の知覚
］に対する攻撃である。
その知覚は、
~hypertext内に類似な銘柄が呈示されることで，誤誘導され得る
— 場合によっては［
`authority$p 成分（権限）をごまかす `userinfo$p
］でも~~補強されて。
`~UA$は、
~phishing攻撃による影響iを，次により抑制できる：
◎
Unfortunately, communicating authority to users can be difficult. For example, "phishing" is an attack on the user's perception of authority, where that perception can be misled by presenting similar branding in hypertext, possibly aided by userinfo obfuscating the authority component (see Section 4.2.1). User agents can reduce the impact of phishing attacks＼
</p>
<ul>
	<li>
利用者が何らかの動作をとるに先立って、
`~target~URI$を，利用者から検分し易くする。
◎
by enabling users to easily inspect a target URI prior to making an action,＼
</li>
	<li>
`userinfo$p が在るときは、
それを目立つ様に~~区別する（または却下する）。
◎
by prominently distinguishing (or rejecting) userinfo when present, and＼
</li>
	<li>
参照元~文書が［
未知な, あるいは信用できない
］~sourceから来ている場合、
自身に格納されている`資格証$や~cookieは送信しない。
◎
by not sending stored credentials and cookies when the referring document is from an unknown or untrusted source.
</li>
</ul>
</div>

		</section>
		<section id="risks.intermediaries">
<h3 title="Risks of Intermediaries">17.2. 媒介者の~risk</h3>

<p>
~HTTP`媒介者$は、
内来的に，経路上の攻撃を成せる立場にある。
媒介者が稼働する~systemが弱体化されると、
深刻な［
~security／~privacy
］問題になり得る。
媒介者は，［
~securityに関係する情報／
個々の［
利用者や組織
］についての個人-情報／
利用者と内容~providerに所属している~proprietary情報
］へも~accessし得るかもしれない。
弱体化された媒介者, あるいは［
~securityや~privacy
］の考慮点に~~無関心に［
実装された／環境設定された
］媒介者は、
その引き換えに広範な攻撃に晒され得る。
◎
HTTP intermediaries are inherently situated for on-path attacks. Compromise of the systems on which the intermediaries run can result in serious security and privacy problems. Intermediaries might have access to security-related information, personal information about individual users and organizations, and proprietary information belonging to users and content providers. A compromised intermediary, or an intermediary implemented or configured without regard to security and privacy considerations, might be used in the commission of a wide range of potential attacks.
</p>

<p>
`共用~cache$を包含する`媒介者$は
— `CACHING$r `~securityの考慮点＠~HTTPcache#security.considerations§
にて述べられるとおり —
~cache汚染~攻撃に，とりわけ脆弱である。
◎
Intermediaries that contain a shared cache are especially vulnerable to cache poisoning attacks, as described in Section 7 of [CACHING].
</p>

<p>
実装者は、［
設計と その~code化にあたっての裁定／
運用者に供する環境設定~option（とりわけ，既定の環境設定）
］による，~privacyや~securityに対する含意を考慮する必要がある。
◎
Implementers need to consider the privacy and security implications of their design and coding decisions, and of the configuration options they provide to operators (especially the default configuration).
</p>

<p>
`媒介者$は、
それを運用している［
人々, 施策
］以上に信用に価するものにはならない
— ~HTTPは、
この問題を解決sできない。
◎
Intermediaries are no more trustworthy than the people and policies under which they operate; HTTP cannot solve this problem.
</p>

		</section>
		<section id="attack.pathname">
<h3 title="Attacks Based on File and Path Names">17.3. ~file名や~path名に基づく攻撃</h3>

<p>
`生成元~server$は、［
`~target~URI$から資源~表現への対応付け
］を管理するために，自身の局所的な~file~systemを用立てることが多い。
ほとんどの~file~systemは、
悪意的な［
~file／~path
］名から保護されるように設計されていない。
したがって，生成元~serverは、
`~target資源$を［
~file／~folder／~directory
］に対応付けるときに，［
~systemにおいて特別な有意性がある名前
］への~accessを避ける必要がある。
◎
Origin servers frequently make use of their local file system to manage the mapping from target URI to resource representations. Most file systems are not designed to protect against malicious file or path names. Therefore, an origin server needs to avoid accessing names that have a special significance to the system when mapping the target resource to files, folders, or directories.
</p>

<p>
例えば［
~UNIX, Microsoft Windows, その他の~OS
］は、
"`..^c" を［
現在の~levelより一つ上の~directoryを指示する，~path成分
］として利用することに加え，特別に命名された［
~path／~file
］名を［
~dataを~system機器へ送信する
］ために利用する。
類似な命名~慣行は、
他の型の~storage~systemにも存在し得る。
同様に，局所的な~storage~systemは、
次を取扱うときに，~securityよりも利用者への親切さを選好する厄介な傾向がある
⇒＃
妥当でない文字／
期待されない文字／
分解された文字の再組成／
文字大小無視な名前に対する 文字大小の正規化
◎
For example, UNIX, Microsoft Windows, and other operating systems use ".." as a path component to indicate a directory level above the current one, and they use specially named paths or file names to send data to system devices. Similar naming conventions might exist within other types of storage systems. Likewise, local storage systems have an annoying tendency to prefer user-friendliness over security when handling invalid or unexpected characters, recomposition of decomposed characters, and case-normalization of case-insensitive names.
</p>

<p>
そのような特別な名前に基づく攻撃は、［
~DoS （例： ~serverに COM ~portから読取るように~~仕向ける）
］や［
~serve用に意味されていない，環境設定や~source~fileの開示
］に力点を置く傾向にある。
◎
Attacks based on such special names tend to focus on either denial-of-service (e.g., telling the server to read from a COM port) or disclosure of configuration and source files that are not meant to be served.
</p>

		</section>
		<section id="attack.injection">
<h3 title="Attacks Based on Command, Code, or Query Injection">17.4. ~command／~code／~query の注入に基づく攻撃</h3>

<p>
`生成元~server$は、
`~URI$の中の~parameterを，［
~system~serviceを識別する／
~database~entryを選定する／
~data~sourceを選ぶ
］ための手段として利用することが多い。
しかしながら、
要請~内に受信される~dataは，信用できない。
攻撃者は、［［
~command呼出n／言語~解釈器／~database~interface
］を通して渡されたときに［
~command／~code／~query
］として誤解釈され得る
］ような~dataを包含させるために，どのような要請~data要素（~method, `~target~URI$, `~header$, `内容$）も構築できる。
◎
Origin servers often use parameters within the URI as a means of identifying system services, selecting database entries, or choosing a data source. However, data received in a request cannot be trusted. An attacker could construct any of the request data elements (method, target URI, header fields, or content) to contain data that might be misinterpreted as a command, code, or query when passed through a command invocation, language interpreter, or database interface.
</p>

<p>
共通的にある攻撃として，例えば~SQL注入は、［
`~target~URI$または~header（例： `Host$h, `Referer$h, 等々）のある部分
］の中に，追加的な~query言語を挿入する。
受信した~dataが SELECT 文0の中で直に利用された場合、
~query言語は，~database~commandとして解釈され得る
— 単純な文字列~値としてではなく。
実装における この型の脆弱性は、
防止するのは容易にもかかわらず，ごく ありふれている。
◎
For example, SQL injection is a common attack wherein additional query language is inserted within some part of the target URI or header fields (e.g., Host, Referer, etc.). If the received data is used directly within a SELECT statement, the query language might be interpreted as a database command instead of a simple string value. This type of implementation vulnerability is extremely common, in spite of being easy to prevent.
</p>

<p>
一般に，資源の実装は、［
指示命令として［
処理される／解釈される
］ような文脈
］においては，要請~dataの利用を避ける~OUGHT。
要請~dataの~parameterは、
固定的な文字列と比較された上で，その比較の結果として動作する~OUGHT
— ［
信用できない~data用に準備されたものではない~interface
］を通して渡されるのではなく。
受信した~dataが固定的な~parameterに基づかない場合、
誤解釈を避けるため，注意深く［
~filterする／符号化する
］~OUGHT。
◎
In general, resource implementations ought to avoid use of request data in contexts that are processed or interpreted as instructions. Parameters ought to be compared to fixed strings and acted upon as a result of that comparison, rather than passed through an interface that is not prepared for untrusted data. Received data that isn't based on fixed parameters ought to be carefully filtered or encoded to avoid being misinterpreted.
</p>

<p>
類似な考慮点は、［
いったん格納され，後で処理される
］ような要請~dataにも適用される
— ［
~log~fileの中／
監視-用~tool／
埋込d~scriptも許容する~data形式の中に内包されるとき
］など。
◎
Similar considerations apply to request data when it is stored and later processed, such as within log files, monitoring tools, or when included within a data format that allows embedded scripts.
</p>

		</section>
		<section id="attack.protocol.element.length">
<h3 title="Attacks via Protocol Element Length">17.5. ~protocol要素の長さを介した攻撃</h3>

<p>
~HTTPは，大方，文字で区切られる~textな~fieldを利用するので、
構文解析器は，［
~~長大な（または とても遅い）~data~streamの送信に基づく攻撃
］に脆弱になることが多い
— 特に，実装が［
定義済みな長さ（ `2.3§ ）がない~protocol要素
］を期待している所では。
◎
Because HTTP uses mostly textual, character-delimited fields, parsers are often vulnerable to attacks based on sending very long (or very slow) streams of data, particularly where an implementation is expecting a protocol element with no predefined length (Section 2.3).
</p>

<p>
相互運用能を促進するため、
各種`~field$には，最小な~size上限について特定の推奨が為される（ `5.4§ ）。
これらは、［
資源が制限された実装でも~support可能になるような，最小
］を与える推奨になるように選ばれている
— ほとんどの実装は，相当に高い上限を選ぶことになると期待されている。
◎
To promote interoperability, specific recommendations are made for minimum size limits on fields (Section 5.4). These are minimum recommendations, chosen to be supportable even by implementations with limited resources; it is expected that most implementations will choose substantially higher limits.
</p>

<p>
`~server$は、
~messageの［
`~target~URI$が~~長過ぎる／要請の`内容$が巨大~過ぎる
］場合には，（ `414$st ／ `413$st で）却下できる。
~HTTPの拡張 `RFC6585$r にも，［
容量~制限に関係する追加的な`状態s~code$
］が定義されている。
◎
A server can reject a message that has a target URI that is too long (Section 15.5.15) or request content that is too large (Section 15.5.14). Additional status codes related to capacity limits have been defined by extensions to HTTP [RFC6585].
</p>

<p>
`受信者$は、［
自身が処理する他の~protocol要素の限度
］を注意深く制限する~OUGHT。
それらには、［
`要請~method$,
応答`事由~句$【！状態s句】,
`~field名$,
数量-値,
~chunkの長さ
］も含まれる。
そのような処理における制限の失敗は、
~buffer~overflowや算術的な桁溢れに因る任意な~code実行, および
~DoS攻撃に対する脆弱性を高める結果になり得る。
◎
Recipients ought to carefully limit the extent to which they process other protocol elements, including (but not limited to) request methods, response status phrases, field names, numeric values, and chunk lengths. Failure to limit such processing can result in arbitrary code execution due to buffer or arithmetic overflows, and increased vulnerability to denial-of-service attacks.
</p>

		</section>
		<section id="compression.attacks">
<h3 title="Attacks Using Shared-Dictionary Compression">17.6. 辞書を共有している圧縮を利用する攻撃</h3>

<p>
暗号化された~protocolに対する攻撃には、
動的な圧縮により作成される~sizeの相違を利用して，機密的な情報を露呈するものもある
— 例えば `BREACH$r
。
攻撃者が制御する内容と機密的な情報に同じ辞書を利用している動的な圧縮~algoは、
前者の内容が後者の内容の一部に合致する場合，より効率的に圧縮することになる
— これらの攻撃は、
そのような冗長性を作成することに依拠する。
◎
Some attacks on encrypted protocols use the differences in size created by dynamic compression to reveal confidential information; for example, [BREACH]. These attacks rely on creating a redundancy between attacker-controlled content and the confidential information, such that a dynamic compression algorithm using the same dictionary for both content will compress more efficiently when the attacker-controlled content matches parts of the confidential content.
</p>

<p>
~HTTP~messageは、
圧縮され得る
— その仕方には、
いくつかあり，次の利用も含まれる
⇒＃
~TLS圧縮,
`内容~符号法$,
`転送~符号法$,
拡張や~versionに特有な他の仕組み
◎
HTTP messages can be compressed in a number of ways, including using TLS compression, content codings, transfer codings, and other extension or version-specific mechanisms.
</p>

<p>
この~riskに対する最も効果的な軽減策は、［
敏感な~dataに対しては圧縮を不能化する
］か［
敏感な~dataを攻撃者が制御する~dataから厳密に分離して，
それらが同じ圧縮~辞書を共有し得ないようにする
］ことである。
注意深い設計の下では、
圧縮~schemeは，［
制限された利用事例においては，悪用-可能とは見なされない
］ような仕方で設計できる
— ~HPACK `HPACK$r など。
◎
The most effective mitigation for this risk is to disable compression on sensitive data, or to strictly separate sensitive data from attacker-controlled data so that they cannot share the same compression dictionary. With careful design, a compression scheme can be designed in a way that is not considered exploitable in limited use cases, such as HPACK ([HPACK]).
</p>

		</section>
		<section id="personal.information">
<h3 title="Disclosure of Personal Information">17.7. 個人-情報の開示</h3>

<div class="p">
<p>
`~client$は，~~多量な個人-情報
— 次に挙げるものを含む —
を知る立場にあることが多いので、
実装は，意図的でない個人-情報の開示を防止する必要がある：
</p>
<ul>
	<li>
資源とヤリトリするために，利用者から供される情報（例：
利用者の［
名前, 所在, ~mail~address, ~password, 暗号化~鍵, 等々
］）
</li>
	<li>
時経過にわたる，利用者の閲覧~活動についての情報（例： 履歴, ~bookmark, 等々）
</li>
</ul>
◎
Clients are often privy to large amounts of personal information, including both information provided by the user to interact with resources (e.g., the user's name, location, mail address, passwords, encryption keys, etc.) and information about the user's browsing activity over time (e.g., history, bookmarks, etc.). Implementations need to prevent unintentional disclosure of personal information.
</div>

		</section>
		<section id="privacy.of.server.log.information">
<h3 title="Privacy of Server Log Information">17.8. ~server~log情報の~privacy</h3>

<p>
`~server$は、［
期間に渡る利用者の要請についての個人-~data
］を保存する立場にあり，利用者の［
行動様式／関心事
］も識別し得る。
特に，［
`媒介者$に集められた~log情報
］は、［
不特定多数の~siteにまたがる，~UAとのヤリトリの履歴
］を包含することが多く，個々の利用者を追跡し得る。
◎
A server is in the position to save personal data about a user's requests over time, which might identify their reading patterns or subjects of interest. In particular, log information gathered at an intermediary often contains a history of user agent interaction, across a multitude of sites, that can be traced to individual users.
</p>

<p>
~HTTP~log情報は，その資質からして機密的なので、
その取扱いは，法律や規制により拘束されることが多い。
~log情報は、
~secureに格納された上で，その分析に際しては適切な指針に従う必要がある。
［
個々の~entryの中の個人-情報の匿名化
］も補助になるが、
一般に，本物の~log追跡から［
他の~access特性との相関
］に基づいて識別し直されるのを防ぐには十分でない。
そのようなわけで、［
特定の`~client$に対し~keyされた~access追跡
］の流出は，当の~keyが疑似匿名であっても安全とは言えない。
◎
HTTP log information is confidential in nature; its handling is often constrained by laws and regulations. Log information needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within individual entries helps, but it is generally not sufficient to prevent real log traces from being re-identified based on correlation with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if the key is pseudonymous.
</p>

<p>
盗聴や不用意な流出の~riskを最小限にするため，個人識別可能な情報
— ［
利用者~識別子,
~IP~address,
利用者が供した `query$p ~parameter
］なども含む
— は、［
~security／ ~~監査（ `auditing^en ）／ 不正行為の~~規制（ `fraud control^en ）
などの，運用~上の必要性を~supportする
］ことが必要yでなくなり次第，~log情報から一掃される~OUGHT。
◎
To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information, including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary to support operational needs for security, auditing, or fraud control.
</p>

		</section>
		<section id="sensitive.information.in.uris">
<h3 title="Disclosure of Sensitive Information in URIs">17.9. ~URI内の敏感な情報の開示</h3>

<p>
`~URI$は、
~secureな資源を識別するものであっても，［
共有され, ~secure化されないもの
］になるように意図されている。
~URIは、［
~displayに示される／
~pageの印刷-時に各用紙に刷られる／
様々な未保護な~bookmark~list内に格納される
］ことが多い。
多くの［
~server／~proxy／~UA
］は、
`~target~URI$を［
第三者-主体から可視になり得る所
］に，~logしたり, 表示する。
したがって，［
敏感な ／ 個人識別可能な ／ 開示される~riskがある
］情報を~URIに内包することは、
賢明でない。
【とは言え、`能力~URL$のような用法はある。】
◎
URIs are intended to be shared, not secured, even when they identify secure resources. URIs are often shown on displays, added to templates when a page is printed, and stored in a variety of unprotected bookmark lists. Many servers, proxies, and user agents log or display the target URI in places where it might be visible to third parties. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
</p>

<p>
応用が［
利用者が供した情報から`~target~URI$を構築するような，~client側の仕組み
］
— `GET$m を利用している~formの~query~fieldなど —
を利用している場合、
~URIの中に開示するには適切にならない，敏感になり得る~dataが供されるかもしれない。
そのような事例では、
`POST$m が選好されることが多い
— それは通例的に、
~URIは構築しない代わりに，
敏感になり得る~dataを~formの `POST$m 要請の`内容$内に伝送するので。
しかしながら，これは、
~cachingを邪魔することに加え，
他であれば`安全$になる要請に安全でない~methodを利用する。
代替な対処法として、［
~URIを構築するに先立って，利用者が供した~dataを形式変換する／
敏感でない 共通的な値に限り内包するよう，当の~dataを~filterする
］などが挙げられる。
同様に【その上で？】，~queryの結果を（~serverが`生成-$した）異なる~URIへ~redirectすれば、
後の~linkから敏感になり得る~dataを除去して，後で再利用できる`~cache可能$な応答を供し得る。
◎
When an application uses client-side mechanisms to construct a target URI out of user-provided information, such as the query fields of a form using GET, potentially sensitive data might be provided that would not be appropriate for disclosure within a URI. POST is often preferred in such cases because it usually doesn't construct a URI; instead, POST of a form transmits the potentially sensitive data in the request content. However, this hinders caching and uses an unsafe method for what would otherwise be a safe request. Alternative workarounds include transforming the user-provided data prior to constructing the URI or filtering the data to only include common values that are not sensitive. Likewise, redirecting the result of a query to a different (server-generated) URI can remove potentially sensitive data from later links and provide a cacheable response for later reuse.
</p>

<p>
`Referer$h ~headerは，要請を~~生じさせた文脈について ~target~siteに~~伝えるので、
参照元~資源の~URI内に見出され得るような［
利用者の直前の閲覧~履歴についての情報, その他の個人-情報
］を露呈する~~可能性がある。
`Referer$h ~headerに対する制限は、
その定義に述べたように，その~securityの考慮点の一部に取組む。
◎
Since the Referer header field tells a target site about the context that resulted in a request, it has the potential to reveal information about the user's immediate browsing history and any personal information that might be found in the referring resource's URI. Limitations on the Referer header field are described in Section 10.1.3 to address some of its security considerations.
</p>

		</section>
		<section id="underscore.in.fields">
<h3 title="Application Handling of Field Names">17.10. 応用による~field名の取扱い</h3>

<p>
`~server$は、［
受信した要請を処理して 応答~用に内容を生産する
］ときに，非~HTTPな［
~gateway~interfaceや~framework
］を利用することが多い。
歴史的な理由から，そのような~interfaceは、
受信した`~field名$を
— 環境~変数~用に相応しい名前への対応付けを利用して —
外部~変数~名として渡すことが多い。
◎
Servers often use non-HTTP gateway interfaces and frameworks to process a received request and produce content for the response. For historical reasons, such interfaces often pass received field names as external variable names, using a name mapping suitable for environment variables.
</p>

<p>
例えば、
`3875/4.1.18$rfc により定義される［
~CGI（
`Common Gateway Interface^en, 共通~gateway~interface
）における，
~protocolに特有な~meta-変数（ `meta-variable^en ）用の対応付け
］は、［
受信した~headerのうち，~CGIの標準~変数に対応しないもの
］に適用される
— その対応付けでは、
各~名前に対し【まず大文字~化してから】 "`HTTP_^c" を前付加して，
すべての~hyphen（ "`-^c" ）を~underscore（ "`_^c" ）に置換する【！変更する】。
同じ対応付けは、
他の多くの応用~frameworkにも継承されている
— 応用を ある~platformから `the next^en【次の~version？他の~platform？】へ移動するのを単純~化するために。
◎
For example, the Common Gateway Interface (CGI) mapping of protocol-specific meta-variables, defined by Section 4.1.18 of [RFC3875], is applied to received header fields that do not correspond to one of CGI's standard variables; the mapping consists of prepending "HTTP_" to each name and changing all instances of hyphen ("-") to underscore ("_"). This same mapping has been inherited by many other application frameworks in order to simplify moving applications from one platform to the next.
</p>

<p>
~CGIにおいては、
受信した `Content-Length$h ~fieldは，
~meta-変数 `CONTENT_LENGTH^c として
— 受信した`~field値$に合致する文字列~値を伴わせて —
渡されることになる。
対照的に，受信した `Content_Length^h ~headerは、
当の~protocolに特有な~meta-変数 `HTTP_CONTENT_LENGTH^c として渡されることになる
— それは、
ある応用を［
既定の~meta-変数ではなく，当の~protocolに特有な~meta-変数に誤解して読取る
］ような混同へ導くかもしれない。
（ `16.3.2.1§ にて［
~underscoreを包含する新たな~field名の作成が忌避される
］わけは、
この歴史的な実施による。）
◎
In CGI, a received Content-Length field would be passed as the meta-variable "CONTENT_LENGTH" with a string value matching the received field's value. In contrast, a received "Content_Length" header field would be passed as the protocol-specific meta-variable "HTTP_CONTENT_LENGTH", which might lead to some confusion if an application mistakenly reads the protocol-specific meta-variable instead of the default one. (This historical practice is why Section 16.3.2.1 discourages the creation of new field names that contain an underscore.)
</p>

<p>
あいにく，`~field名$から~interface名への対応付けは、［
不完全／多義的
］な場合，~securityの脆弱性へ導き得る。
例えば，攻撃者が "`Transfer_Encoding^c" と命名された~fieldを送信した場合、
素朴な~interfaceは `Transfer-Encoding^h ~fieldと同じ変数~名へ対応付けるかもしれず、
その結果，`要請~密入~攻撃$ `HTTP/1.1$r に対する脆弱性になる~~可能性がある。
◎
Unfortunately, mapping field names to different interface names can lead to security vulnerabilities if the mapping is incomplete or ambiguous. For example, if an attacker were to send a field named "Transfer_Encoding", a naive interface might map that to the same variable name as the "Transfer-Encoding" field, resulting in a potential request smuggling vulnerability (Section 11.2 of [HTTP/1.1]).
</p>

<p>
そのような対応付けを遂行する実装は、
それにつきまとう~riskを軽減するため，
名前として受信される~~可能性がある 全-範囲の~octetに対し
（忌避されるものや, ~HTTP文法により禁止されるものも含む），
対応付けが一義的かつ完全になるようにすることを勧める。
例えば，ある~fieldが通例的でない名前~文字を伴う場合、［
当の要請が阻止されたり，
特定の~fieldが除去されたり，
当の名前に
— 他の~fieldと判別できるよう —
他と異なる接頭辞が付与された上で渡される
］結果になるかもしれない。
◎
To mitigate the associated risks, implementations that perform such mappings are advised to make the mapping unambiguous and complete for the full range of potential octets received as a name (including those that are discouraged or forbidden by the HTTP grammar). For example, a field with an unusual name character might result in the request being blocked, the specific field being removed, or the name being passed with a different prefix to distinguish it from other fields.
</p>

		</section>
		<section id="fragment.disclosure">
<h3 title="Disclosure of Fragment after Redirects">17.11. ~redirect後の素片の開示</h3>

<p>
`~URI参照$の中で利用される素片~識別子は，要請~内には送信されないが、
実装者は，［
それらが、
応答の結果として，~UA, および稼働している どの［
拡張／~script
］からも可視になる
］ことを自覚しておく~OUGHT。
特に，［
~redirectが生じて，元の要請の素片~識別子が `Location$h 内の新たな参照に継承される
］とき、
これには，［
ある~siteの素片を別の~siteに開示する
］かもしれない効果がある。
最初の~siteが `fragment$p 内に個人-情報を利用している場合、
他の~siteへの~redirectに際しては，［
【最初の `fragment^p と無関係な】（場合によっては空な） `fragment^p 成分を内包することにより，その継承を阻止する
］ことを確保する~OUGHT。
◎
Although fragment identifiers used within URI references are not sent in requests, implementers ought to be aware that they will be visible to the user agent and any extensions or scripts running as a result of the response. In particular, when a redirect occurs and the original request's fragment identifier is inherited by the new reference in Location (Section 10.2.2), this might have the effect of disclosing one site's fragment to another site. If the first site uses personal information in fragments, it ought to ensure that redirects to other sites include a (possibly empty) fragment component in order to block that inheritance.
</p>

		</section>
		<section id="disclosure.product.information">
<h3 title="Disclosure of Product Information">17.12. 製品~情報の開示</h3>

<p>
［
`User-Agent$h ／ `Via$h ／ `Server$h
］~headerは、［
当の`送信者$の~software~systemについての情報
］を露呈することが多い。
これは，理論においては、
攻撃者が既知な~securityの穴を悪用し易くし得る
— 実施においては、
攻撃者は，［
利用されている ~~見かけの~software~version
］に関わらず，~~可能性がある すべての穴を試行する傾向にあるが。
◎
The User-Agent (Section 10.1.5), Via (Section 7.6.3), and Server (Section 10.2.4) header fields often reveal information about the respective sender's software systems. In theory, this can make it easier for an attacker to exploit known security holes; in practice, attackers tend to try all potential holes regardless of the apparent software versions being used.
</p>

<p>
［
~network~firewallを通る~portalとして~serveする`~proxy$
］は、［
~firewallの背後の~hostを識別し得るような ~header情報
］の転送に関して，特別な予防策を~~講じる~OUGHT。
`Via$h ~headerは、［
敏感な~machine名を `pseudonym$p に置換する
］ことを`媒介者$に許容する。
◎
Proxies that serve as a portal through a network firewall ought to take special precautions regarding the transfer of header information that might identify hosts behind the firewall. The Via header field allows intermediaries to replace sensitive machine names with pseudonyms.
</p>

		</section>
		<section id="fingerprinting">
<h3 title="Browser Fingerprinting">17.13. ~browser指紋収集</h3>

<p>
~browser指紋収集（ `fingerprinting^en ）は、［
一意な［
~UAの各種~特性からなる集合
］を通して，特定の~UAを時間~越しに識別する
］ための，様々な技法の~~総称である。
これらの特性には、［
~UAが下層の~transport~protocolをどう利用するか,
~UAに備わる特能,
~UAの~scripting環境
］に関係する情報も含まれ得る
— 特に関心を引くものは、［
~HTTPを介して通信され得る，一意な【個別の~UAを一意に~~特定するような】特性たちが成す集合
］である。
指紋収集は，［
~UAの挙動を時間~越しに追跡すること `Bujlow$r
］を
— 利用者が，他の形の~data~collection（例：~cookie）に対しては持ち得るような、
対応する制御なしに —
可能化するので、
~privacy懸念と見なされる。
多くの一般用~UA（すなわち，~web~browser）は、
指紋収集を抑制する手続きを踏んでいる。
◎
Browser fingerprinting is a set of techniques for identifying a specific user agent over time through its unique set of characteristics. These characteristics might include information related to how it uses the underlying transport protocol, feature capabilities, and scripting environment, though of particular interest here is the set of unique characteristics that might be communicated via HTTP. Fingerprinting is considered a privacy concern because it enables tracking of a user agent's behavior over time ([Bujlow]) without the corresponding controls that the user might have over other forms of data collection (e.g., cookies). Many general-purpose user agents (i.e., Web browsers) have taken steps to reduce their fingerprints.
</p>

<p>
いくつもの要請~headerが、
一意に足る指紋収集を可能化するような情報を，~serverに露呈し得る。
最も明白なのは `From$h ~headerである
— それは、［
利用者から，自己の識別が欲されている
］ときに限り，送信されるものと期待されているが。
同様に， `Cookie$h ~headerは、［
再~識別を可能化するよう，故意に設計されている
］ので，指紋収集の懸念が適用されるのは［
~UAの環境設定により，~cookieが不能化-または制約されている状況
］に限られる。
◎
There are a number of request header fields that might reveal information to servers that is sufficiently unique to enable fingerprinting. The From header field is the most obvious, though it is expected that From will only be sent when self-identification is desired by the user. Likewise, Cookie header fields are deliberately designed to enable re-identification, so fingerprinting concerns only apply to situations where cookies are disabled or restricted by the user agent's configuration.
</p>

<p>
`User-Agent$h ~headerは、
特に`~UA$が［
利用者の~systemや拡張についての過度な詳細
］を送信した場合に，［
通例的に，他の特性と組合されたとき、
特定の機器を一意に識別するに十分な情報
］を包含し得る。
しかしながら，それよりも［
利用者が まず予期しないであろう，一意な情報の~source
］を成すものは、
`~proactive折衝~header$であり，次が含まれる
⇒＃
`Accept$h,
`Accept-Charset$h,
`Accept-Encoding$h,
`Accept-Language$h
◎
The User-Agent header field might contain enough information to uniquely identify a specific device, usually when combined with other characteristics, particularly if the user agent sends excessive details about the user's system or extensions. However, the source of unique information that is least expected by users is proactive negotiation (Section 12.1), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.
</p>

<p>
指紋収集の懸念に加えて，［
`Accept-Language$h ~headerの詳細な利用
］は、［
利用者が私的な資質と見なし得る情報
］を露呈し得る。
例えば，［
所与の言語~集合を解すること
］は、［
特定0の民族の成員であること
］に強く相関し得る。
~UAがとり得る，そのような~privacyの損失を制限する~approachとしては、
明示的に許可された~siteを除き，
`Accept-Language$h の送信を省略することが挙げられる
— たぶん，［
言語~折衝を指示する `Vary$h ~header
］を検出した後のやりとりを介することが、
有用になり得る。
◎
In addition to the fingerprinting concern, detailed use of the Accept-Language header field can reveal information the user might consider to be of a private nature. For example, understanding a given language set might be strongly correlated to membership in a particular ethnic group. An approach that limits such loss of privacy would be for a user agent to omit the sending of Accept-Language except for sites that have been explicitly permitted, perhaps via interaction after detecting a Vary header field that indicates language negotiation might be useful.
</p>

<p>
~privacyを強化するために`~proxy$が利用される環境においては、
`~UA$は［
`~proactive折衝~header$の送信
］に保守的になる~OUGHT。
~headerの~~高度な環境設定-能を供する一般用`~UA$は、［
詳細が供され過ぎる結果，~privacyの損失に繋がり得る
］ことについて，利用者に伝える~OUGHT。
~~究極の~privacy~~保護措置として、
~proxyは，中継される要請~内の`~proactive折衝~header$を~filterできる。
◎
In environments where proxies are used to enhance privacy, user agents ought to be conservative in sending proactive negotiation header fields. General-purpose user agents that provide a high degree of header field configurability ought to inform users about the loss of privacy that might result if too much detail is provided. As an extreme privacy measure, proxies could filter the proactive negotiation header fields in relayed requests.
</p>

		</section>
		<section id="security.validators">
<h3 title="Validator Retention">17.14. 検証子の維持</h3>

<p>
この仕様により定義される検証子は、［
`表現$の妥当性を確保する／
悪意的な変更に抗して防護する／
経路上の攻撃を検出する
］ものとして意図されてはいない。
それらは~~最善でも、
すべての参加者が~~順調に挙動する下で［
より効率的な~cache更新を可能化する／同時並行な書込nをより~~適化する
］だけである。
~~最悪でも、
条件は失敗し，~clientは［［
条件付き~でない要請による~HTTP交換
］以上に有害にはならない，応答
］を受信するだけである。
◎
The validators defined by this specification are not intended to ensure the validity of a representation, guard against malicious changes, or detect on-path attacks. At best, they enable more efficient cache updates and optimistic concurrent writes when all participants are behaving nicely. At worst, the conditions will fail and the client will receive a response that is no more harmful than an HTTP exchange without conditional requests.
</p>

<p>
`実体~tag$は、
~privacy~riskを高める仕方で濫用され得る。
例えば、
ある~siteが，［
利用者／~UA
］を識別し直す手段として、
意味論的に妥当でない`実体~tag$を［
利用者／~UA
］間で一意になるよう故意に構築して，それを［
`~cache可能$かつ`鮮度~維持期間$が長い，応答
］内に送信した上で，［
今後の`条件付き要請$からその`実体~tag$を読取る
］こともあり得る。
そのような識別-用の~tagは、［
~UAが元の~cache~entryを維持する限り，持続する
］ような識別子になるであろう。
`表現$を~cacheする~UAは、
利用者が~privacyを保守する動作を遂行したとき
— ［
格納された~cookieを~clearする／私的~閲覧~modeに変える
］など —
には，その~cacheが［
~clearされる／置換される
］ことを確保する~OUGHT。
◎
An entity tag can be abused in ways that create privacy risks. For example, a site might deliberately construct a semantically invalid entity tag that is unique to the user or user agent, send it in a cacheable response with a long freshness time, and then read that entity tag in later conditional requests as a means of re-identifying that user or user agent. Such an identifying tag would become a persistent identifier for as long as the user agent retained the original cache entry. User agents that cache representations ought to ensure that the cache is cleared or replaced whenever the user performs privacy-maintaining actions, such as clearing stored cookies or changing to a private browsing mode.
</p>

		</section>
		<section id="overlapping.ranges">
<h3 title="Denial-of-Service Attacks Using Range">17.15. 範囲を利用する~DoS攻撃</h3>

<p>
拘束されない複数~範囲の要請は、
~DoS攻撃に~~感受性が~~高い
— 重合する多数の範囲を要請する労力は、
要請された~dataを多数の部位tで~serveしようとするときに消費される［
時間, ~memory, 帯域幅
］に比較して僅かなので。
`~server$は、
~~甚しい`範囲~要請$
— 3 個~以上が重合したり, 多数に細切れにされた範囲たちに対する要請 —
を［
無視する／
合体する／
却下する
］~OUGHT
— 特に，それらの範囲が~~明らかな理由なしに順不同で要請されたとき。
複-部位tな範囲~要請は、
~random~accessを~supportするように設計されていない。
◎
Unconstrained multiple range requests are susceptible to denial-of-service attacks because the effort required to request many overlapping ranges of the same data is tiny compared to the time, memory, and bandwidth consumed by attempting to serve the requested data in many parts. Servers ought to ignore, coalesce, or reject egregious range requests, such as requests for more than two overlapping ranges or for many small ranges in a single set, particularly when the ranges are requested out of order for no apparent reason. Multipart range requests are not designed to support random access.
</p>

		</section>
		<section id="security.auth">
<h3 title="Authentication Considerations">17.16. 認証の考慮点</h3>

<p>
~HTTP認証の論題については何もかも~securityの考慮点になるので、
以下に挙げる考慮点は，網羅的ではない。
更には、［
一般的な，認証~frameworkに関する~securityの考慮点
］に制限されている
— 特定の`認証~scheme$について，~~可能性がある考慮点~すべてを論じるのではなく
（それらは，各~schemeを定義する仕様にて文書化される~OUGHT）。
様々な組織が，~Web応用の~securityについての時事的な情報や現在の事実調査への~linkを保守する
（例： `OWASP$r ）
— 実施において見出される`認証~scheme$を［
実装する／利用する
］際に共通的な罠など。
◎
Everything about the topic of HTTP authentication is a security consideration, so the list of considerations below is not exhaustive. Furthermore, it is limited to security considerations regarding the authentication framework, in general, rather than discussing all of the potential considerations for specific authentication schemes (which ought to be documented in the specifications that define those schemes). Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]), including common pitfalls for implementing and using the authentication schemes found in practice.
</p>

			<section id="confidentiality.of.credentials">
<h4 title="Confidentiality of Credentials">17.16.1. 資格証の機密性</h4>

<p>
~HTTP認証~frameworkは、［
`資格証$の機密性を保守するための，単独の仕組み
］は定義しない
— 代わりに、
各 `認証~scheme$が［
伝送に先立って`資格証$が符号化される方法
］を定義する。
これは、
将来における`認証~scheme$の開発に柔軟性を供する一方で、［
自前の機密性を供さない, あるいは
反射攻撃に対する保護には足らない
］ような既存の~schemeの保護には，必要十分でない。
更には，`~server$が［
個々の利用者に特有な`資格証$
］を期待する場合、
それらの`資格証$の交換は，その利用者を識別する効果ももたらす
— `資格証$の中の内容が機密的であり続けるとしても。
◎
The HTTP authentication framework does not define a single mechanism for maintaining the confidentiality of credentials; instead, each authentication scheme defines how the credentials are encoded prior to transmission. While this provides flexibility for the development of future authentication schemes, it is inadequate for the protection of existing schemes that provide no confidentiality on their own, or that do not sufficiently protect against replay attacks. Furthermore, if the server expects credentials that are specific to each individual user, the exchange of those credentials will have the effect of identifying that user even if the content within credentials remains confidential.
</p>

<p>
~HTTPが供する［
`~field$の伝送における機密性
］は、
下層［
~transport／~session
］~levelの接続の，各種~securityの~propertyに依存する。
個々の利用者~認証に依存する~serviceは、
`資格証$を交換するに先立って，~secure化された接続が要求される。
◎
HTTP depends on the security properties of the underlying transport- or session-level connection to provide confidential transmission of fields. Services that depend on individual user authentication require a secured connection prior to exchanging credentials (Section 4.2.2).
</p>

			</section>
			<section id="auth.credentials.and.idle.clients">
<h4 title="Credentials and Idle Clients">17.16.2. 資格証と遊休~client</h4>

<p>
既存の~HTTP［
`~client$／`~UA$
］が認証~情報を維持する~~期間は、
概して不定である。
~HTTPは、［
`生成元~server$が、
`~client$に対し，~cacheされた`資格証$を破棄するよう指令する
］ための仕組みを供さない
— この~protocolは、
~UAが`資格証$を［
得する／管理する
］方法については~~関知しないので。
`資格証$を［
失効させる／廃用にする
］ための仕組みは、
`認証~scheme$定義の一部として指定し得る。
◎
Existing HTTP clients and user agents typically retain authentication information indefinitely. HTTP does not provide a mechanism for the origin server to direct clients to discard these cached credentials, since the protocol has no awareness of how credentials are obtained or managed by the user agent. The mechanisms for expiring or revoking credentials can be specified as part of an authentication scheme definition.
</p>

<p>
資格証を~cacheすることは、
少なくとも次に挙げる状況下においては，応用の~security~modelに干渉し得る：
◎
Circumstances under which credential caching can interfere with the application's security model include but are not limited to:
</p>
<ul>
	<li>
`~client$が期間を延長して遊休~中にあるときに、
`~server$が，`~client$に対し［
再度，利用者に`資格証$の~~入力を促す
］よう望むかもしれないとき。
◎
Clients that have been idle for an extended period, following which the server might wish to cause the client to re-prompt the user for credentials.
</li>
	<li>
応用は，~sessionの終了n指示
（~page上の “~logout” や “~commit” ~buttonなど）
を含んでいて、
それにより，応用を成す~server側は［
`~client$が`資格証$を維持する理由は、
もう無い
］ことを “知る” とき。
◎
Applications that include a session termination indication (such as a "logout" or "commit" button on a page) after which the server side of the application "knows" that there is no further reason for the client to retain the credentials.
</li>
</ul>

<p>
`資格証$を~cacheする`~UA$には、［
~cacheされた`資格証$を利用者-制御の下で破棄する
］ための［
~~簡単に~access可能な仕組み
］を供することが奨励される。
◎
User agents that cache credentials are encouraged to provide a readily accessible mechanism for discarding cached credentials under user control.
</p>

			</section>
			<section id="protection.spaces">
<h4 title="Protection Spaces">17.16.3. 保護~空間</h4>

<p>
`認証~scheme$のうち，［
もっぱら `realm$c の仕組みに依拠して`保護~空間$を確立するもの
］は、［
`生成元~server$上のすべての資源に対し，認証~用の`資格証$を公開する
］ことになる。
資源への認証-済み要請を成功裡に為した`~client$は、
同じ`生成元~server$上の他の資源に対しても，同じ`資格証$を利用できる。
これは、［
ある資源が，他の資源~用の`資格証$を採取すること
］をアリにする。
◎
Authentication schemes that solely rely on the "realm" mechanism for establishing a protection space will expose credentials to all resources on an origin server. Clients that have successfully made authenticated requests with a resource can use the same authentication credentials for other resources on the same origin server. This makes it possible for a different resource to harvest authentication credentials for other resources.
</p>

<div class="p">
<p>
これは特に、［
`生成元~server$が、
同じ`生成元$の下で，複数の主体~用に資源を~hostするとき
］に懸念される（ `11.5§ ）。
とり得る軽減策としては、
次が挙げられる：
◎
This is of particular concern when an origin server hosts resources for multiple parties under the same origin (Section 11.5). Possible mitigation strategies include＼
</p>
<ul>
	<li>
認証~用の`資格証$への直な~accessを制約する
（すなわち， `Authorization$h 要請~headerの内容を可用にしない）。
◎
restricting direct access to authentication credentials (i.e., not making the content of the Authorization request header field available), and＼
</li>
	<li>
異なる~host名（あるいは~port番号）を利用して，`保護~空間$を各~主体ごとに分離する。
◎
separating protection spaces by using a different host name (or port number) for each party.
</li>
</ul>
</div>

			</section>
			<section id="security.auth.add.resp">
<h4 title="Additional Response Fields">17.16.4. 追加的な応答~field</h4>

<p>
［
暗号化されてない~channel越しに送信される応答
］に情報を追加すると、
~securityや~privacyに影響し得る。
［
`Authentication-Info$h ／ `Proxy-Authentication-Info$h
］~headerが在ること自体は、
~HTTP認証が利用~中にあることを指示する。
`認証~scheme$に特有な~parameterの内容により，追加的な情報も公開され得る
— これらの~schemeの定義は、
このことを考慮する必要がある。
◎
Adding information to responses that are sent over an unencrypted channel can affect security and privacy. The presence of the Authentication-Info and Proxy-Authentication-Info header fields alone indicates that HTTP authentication is in use. Additional information could be exposed by the contents of the authentication-scheme specific parameters; this will have to be considered in the definitions of these schemes.
</p>

			</section>
		</section>
	</section>
	<section id="IANA.considerations">
<h2 title="IANA Considerations">18. ~IANA考慮点</h2>

<p>
以下に挙げる登録の変更~制御者は、
“~IETF（ iesg@ietf.org, `Internet Engineering Task Force^en ）”
である。
◎
The change controller for the following registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</p>

		<section id="uri.scheme.registration">
<h3 title="URI Scheme Registration">18.1. ~URI~schemeの登録</h3>

<p>
~IANAは、
`~URI~scheme~registry$cite
（ `Uniform Resource Identifier (URI) Schemes^en ）
`BCP35$r
を更新した
— `4.2§に挙げられた恒久的な~schemeを伴うよう：
◎
IANA has updated the "Uniform Resource Identifier (URI) Schemes" registry [BCP35] at &lt;https://www.iana.org/assignments/uri-schemes/&gt; with the permanent schemes listed in Table 2 in Section 4.2.
</p>

<div>
<table><thead>
<tr><th>~URI~scheme
<th>記述
<th>§
<tbody>

<tr><td>`http^c
<td>Hypertext Transfer Protocol
<td>`4.2.1§

<tr><td>`https^c
<td>Hypertext Transfer Protocol
<td>`4.2.2§
</table>
◎
↑↑ § 4.2
</div>

<p class="trans-note">【
この表tは，原文では `4.2＠#uri.scheme.table§ に在るが、
一貫させるため，ここに与えることにする。
】</p>

		</section>
		<section id="method.registration">
<h3 title="Method Registration">18.2. ~methodの登録</h3>

<p>
~IANAは、
`~HTTP~method~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Method Registry^en ）
を更新した
— `16.1.1§ の登録~手続-に従って，
次の表tに要約される~method名を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Method Registry" at &lt;https://www.iana.org/assignments/http-methods&gt; with the registration procedure of Section 16.1.1 and the method names summarized in the following table.
</p>

<div>
<table id="iana.method.registration.table"><thead>
<tr><th>~method
<th>安全か
<th>冪等か
<th>§
<tbody>

<tr><td>`CONNECT^m
<td>no
<td>no
<td>`9.3.6§

<tr><td>`DELETE^m
<td>no
<td>yes
<td>`9.3.5§

<tr><td>`GET^m
<td>yes
<td>yes
<td>`9.3.1§

<tr><td>`HEAD^m
<td>yes
<td>yes
<td>`9.3.2§

<tr><td>`OPTIONS^m
<td>yes
<td>yes
<td>`9.3.7§

<tr><td>`POST^m
<td>no
<td>no
<td>`9.3.3§

<tr><td>`PUT^m
<td>no
<td>yes
<td>`9.3.4§

<tr><td>`TRACE^m
<td>yes
<td>yes
<td>`9.3.8§

<tr><td>`*^m
<td>no
<td>no
<td>`18.2§
</table>
◎
Table 7
Method｜Safe｜Idempotent｜Section
CONNECT｜no｜no｜9.3.6
DELETE｜no｜yes｜9.3.5
GET｜yes｜yes｜9.3.1
HEAD｜yes｜yes｜9.3.2
OPTIONS｜yes｜yes｜9.3.7
POST｜no｜no｜9.3.3
PUT｜no｜yes｜9.3.4
TRACE｜yes｜yes｜9.3.8
*｜no｜no｜18.2
</div>

<p>
~method名 "`*^m" は、
予約される
— ~method名として "`*^m" を利用すると、
一部の~field
（例： `Access-Control-Request-Method$h ）
における `wildcard^p としての "`*^c" の用法と競合することになるので。
◎
The method name "*" is reserved because using "*" as a method name would conflict with its usage as a wildcard in some fields (e.g., "Access-Control-Request-Method").
</p>

		</section>
		<section id="status.code.registration">
<h3 title="Status Code Registration">18.3. 状態s~codeの登録</h3>

<p>
~IANAは、
`~HTTP状態s~code~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Status Code Registry^en ）
を更新した
— `16.2.1§ の登録~手続-に従って，
次の表tに要約される状態s~code値を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Status Code Registry" at &lt;https://www.iana.org/assignments/http-status-codes&gt; with the registration procedure of Section 16.2.1 and the status code values summarized in the following table.
</p>

<div>
<table id="iana.status.code.registration.table"><thead>
<tr><th>値
<th>記述
<th>§
<tbody>

<tr><td>`100^st0
<td>Continue
<td>`15.2.1§

<tr><td>`101^st0
<td>Switching Protocols
<td>`15.2.2§

<tr><td>`200^st0
<td>OK
<td>`15.3.1§

<tr><td>`201^st0
<td>Created
<td>`15.3.2§

<tr><td>`202^st0
<td>Accepted
<td>`15.3.3§

<tr><td>`203^st0
<td>Non-Authoritative Information
<td>`15.3.4§

<tr><td>`204^st0
<td>No Content
<td>`15.3.5§

<tr><td>`205^st0
<td>Reset Content
<td>`15.3.6§

<tr><td>`206^st0
<td>Partial Content
<td>`15.3.7§

<tr><td>`300^st0
<td>Multiple Choices
<td>`15.4.1§

<tr><td>`301^st0
<td>Moved Permanently
<td>`15.4.2§

<tr><td>`302^st0
<td>Found
<td>`15.4.3§

<tr><td>`303^st0
<td>See Other
<td>`15.4.4§

<tr><td>`304^st0
<td>Not Modified
<td>`15.4.5§

<tr><td>`305^st0
<td>Use Proxy
<td>`15.4.6§

<tr><td>`306^st0
<td>（利用されない）
<td>`15.4.7§

<tr><td>`307^st0
<td>Temporary Redirect
<td>`15.4.8§

<tr><td>`308^st0
<td>Permanent Redirect
<td>`15.4.9§

<tr><td>`400^st0
<td>Bad Request
<td>`15.5.1§

<tr><td>`401^st0
<td>Unauthorized
<td>`15.5.2§

<tr><td>`402^st0
<td>Payment Required
<td>`15.5.3§

<tr><td>`403^st0
<td>Forbidden
<td>`15.5.4§

<tr><td>`404^st0
<td>Not Found
<td>`15.5.5§

<tr><td>`405^st0
<td>Method Not Allowed
<td>`15.5.6§

<tr><td>`406^st0
<td>Not Acceptable
<td>`15.5.7§

<tr><td>`407^st0
<td>Proxy Authentication Required
<td>`15.5.8§

<tr><td>`408^st0
<td>Request Timeout
<td>`15.5.9§

<tr><td>`409^st0
<td>Conflict
<td>`15.5.10§

<tr><td>`410^st0
<td>Gone
<td>`15.5.11§

<tr><td>`411^st0
<td>Length Required
<td>`15.5.12§

<tr><td>`412^st0
<td>Precondition Failed
<td>`15.5.13§

<tr><td>`413^st0
<td>Content Too Large
<td>`15.5.14§

<tr><td>`414^st0
<td>URI Too Long
<td>`15.5.15§

<tr><td>`415^st0
<td>Unsupported Media Type
<td>`15.5.16§

<tr><td>`416^st0
<td>Range Not Satisfiable
<td>`15.5.17§

<tr><td>`417^st0
<td>Expectation Failed
<td>`15.5.18§

<tr><td>`418^st0
<td>(Unused)
<td>`15.5.19§

<tr><td>`421^st0
<td>Misdirected Request
<td>`15.5.20§

<tr><td>`422^st0
<td>Unprocessable Content
<td>`15.5.21§

<tr><td>`426^st0
<td>Upgrade Required
<td>`15.5.22§

<tr><td>`500^st0
<td>Internal Server Error
<td>`15.6.1§

<tr><td>`501^st0
<td>Not Implemented
<td>`15.6.2§

<tr><td>`502^st0
<td>Bad Gateway
<td>`15.6.3§

<tr><td>`503^st0
<td>Service Unavailable
<td>`15.6.4§

<tr><td>`504^st0
<td>Gateway Timeout
<td>`15.6.5§

<tr><td>`505^st0
<td>HTTP Version Not Supported
<td>`15.6.6§
</table>

<p class="trans-note">【
“記述” 列に挙げられる~textは、
この仕様において，状態s~code用に利用される`事由~句$と同じ。
】</p>
◎
Table 8
Value｜Description｜Section
100｜Continue｜15.2.1
101｜Switching Protocols｜15.2.2
200｜OK｜15.3.1
201｜Created｜15.3.2
202｜Accepted｜15.3.3
203｜Non-Authoritative Information｜15.3.4
204｜No Content｜15.3.5
205｜Reset Content｜15.3.6
206｜Partial Content｜15.3.7
300｜Multiple Choices｜15.4.1
301｜Moved Permanently｜15.4.2
302｜Found｜15.4.3
303｜See Other｜15.4.4
304｜Not Modified｜15.4.5
305｜Use Proxy｜15.4.6
306｜(Unused)｜15.4.7
307｜Temporary Redirect｜15.4.8
308｜Permanent Redirect｜15.4.9
400｜Bad Request｜15.5.1
401｜Unauthorized｜15.5.2
402｜Payment Required｜15.5.3
403｜Forbidden｜15.5.4
404｜Not Found｜15.5.5
405｜Method Not Allowed｜15.5.6
406｜Not Acceptable｜15.5.7
407｜Proxy Authentication Required｜15.5.8
408｜Request Timeout｜15.5.9
409｜Conflict｜15.5.10
410｜Gone｜15.5.11
411｜Length Required｜15.5.12
412｜Precondition Failed｜15.5.13
413｜Content Too Large｜15.5.14
414｜URI Too Long｜15.5.15
415｜Unsupported Media Type｜15.5.16
416｜Range Not Satisfiable｜15.5.17
417｜Expectation Failed｜15.5.18
418｜(Unused)｜15.5.19
421｜Misdirected Request｜15.5.20
422｜Unprocessable Content｜15.5.21
426｜Upgrade Required｜15.5.22
500｜Internal Server Error｜15.6.1
501｜Not Implemented｜15.6.2
502｜Bad Gateway｜15.6.3
503｜Service Unavailable｜15.6.4
504｜Gateway Timeout｜15.6.5
505｜HTTP Version Not Supported｜15.6.6
</div>

		</section>
		<section id="field.name.registration">
<h3 title="Field Name Registration">18.4. ~field名の登録</h3>

<p>
この仕様は、［
`RFC3864$r にて定義された，~message~header~field用の既存の登録~手続-
］の［
~HTTPに関係する側面
］を更新する。
それは、［
新たな登録~手続-を定義して，
~HTTP~field定義を別々な~registryの中へ移動する
］ことにより，~HTTPに関係する旧-手続-を置換する。
◎
This specification updates the HTTP-related aspects of the existing registration procedures for message header fields defined in [RFC3864]. It replaces the old procedures as they relate to HTTP by defining a new registration procedure and moving HTTP field definitions into a separate registry.
</p>

<p>
~IANAは、
`~HTTP~field名~registry$cite
と称される新たな~registryを，
`16.3.1§ にて要旨されるとおりに作成した。
◎
IANA has created a new registry titled "Hypertext Transfer Protocol (HTTP) Field Name Registry" as outlined in Section 16.3.1.
</p>

<p>
~IANAは、
`~message~header＠~IANA-a/message-headers/$cite
（ `Message Headers^en ）
~registry内の［
恒久的~message~header名,
暫定的~message~header名
］~registry内に在った~entryのうち［
~protocol `http^c を伴うものすべて
］を，この~registryに移動した
— 加えて、
次に挙げる変更を適用した：
◎
IANA has moved all entries in the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries (see &lt;https://www.iana.org/assignments/message-headers/&gt;) with the protocol 'http' to this registry and has applied the following changes:
</p>
<ol>
	<li>
“適用-可能な~protocol” ~fieldは、
省略した。
◎
The 'Applicable Protocol' field has been omitted.
</li>
	<li>
位置付け［
`standard^en ／ `experimental^en ／ `reserved^en ／ `informational^en
］【 “標準” ／ “試験的” ／ “予約-済み” ／ “参考” 】
を伴っていた~entryには、
位置付け `恒久的^i を伴わせた。
◎
Entries that had a status of 'standard', 'experimental', 'reserved', or 'informational' have been made to have a status of 'permanent'.
</li>
	<li>
位置付けを伴っていなかった暫定的な~entryには、
位置付け `暫定的^i を伴わせた。
◎
Provisional entries without a status have been made to have a status of 'provisional'.
</li>
	<li>
位置付けを伴っていなかった恒久的な~entry
（確認~後に，それを登録した文書が定義していなかったもの）
には、
位置付け `暫定的^i を伴わせた。
専門家（たち）は、
別の位置付けの方が適切とする根拠があるならば，
当の~entryの位置付けを更新することを選べる。
◎
Permanent entries without a status (after confirmation that the registration document did not define one) have been made to have a status of 'provisional'. The expert(s) can choose to update the entries' status if there is evidence that another is more appropriate.
</li>
</ol>

<p>
~IANAは、［
恒久的~message~header名,
暫定的~message~header名
］~registryに対し，［
~HTTP~field名の登録は移動されたこと
］を指示する次の注記（ `Note^en ）で注釈した
⇒
<q lang="en">HTTP field name registrations have been moved to [https://www.iana.org/assignments/http-fields] per [RFC9110].</q>
【 “~HTTP~field名の登録は、`RFC9110^r に従って， `~HTTP~field名~registry$cite へ移動された。” 】
◎
IANA has annotated the "Permanent Message Header Field Names" and "Provisional Message Header Field Names" registries with the following note to indicate that HTTP field name registrations have moved:
◎
Note
• HTTP field name registrations have been moved to [https://www.iana.org/assignments/http-fields] per [RFC9110].
</p>

<p>
~IANAは、
`~HTTP~field名~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Field Name Registry^en ）
を更新した
— 次の表tに挙げる~field名を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Field Name Registry" with the field names listed in the following table.
</p>

<div>
<table id="iana.header.registration.table"><thead>
<tr><th>~field名
<th>位置付け
<th>§
<th>~comment
<tbody>

<tr><td>`Accept^h
<td>`恒久的^i
<td>`12.5.1§
<td>

<tr><td>`Accept-Charset^h
<td>`非推奨d^i
<td>`12.5.2§
<td>

<tr><td>`Accept-Encoding^h
<td>`恒久的^i
<td>`12.5.3§
<td>

<tr><td>`Accept-Language^h
<td>`恒久的^i
<td>`12.5.4§
<td>

<tr><td>`Accept-Ranges^h
<td>`恒久的^i
<td>`14.3§
<td>

<tr><td>`Allow^h
<td>`恒久的^i
<td>`10.2.1§
<td>

<tr><td>`Authentication-Info^h
<td>`恒久的^i
<td>`11.6.3§
<td>

<tr><td>`Authorization^h
<td>`恒久的^i
<td>`11.6.2§
<td>

<tr><td>`Connection^h
<td>`恒久的^i
<td>`7.6.1§
<td>

<tr><td>`Content-Encoding^h
<td>`恒久的^i
<td>`8.4§
<td>

<tr><td>`Content-Language^h
<td>`恒久的^i
<td>`8.5§
<td>

<tr><td>`Content-Length^h
<td>`恒久的^i
<td>`8.6§
<td>

<tr><td>`Content-Location^h
<td>`恒久的^i
<td>`8.7§
<td>

<tr><td>`Content-Range^h
<td>`恒久的^i
<td>`14.4§
<td>

<tr><td>`Content-Type^h
<td>`恒久的^i
<td>`8.3§
<td>

<tr><td>`Date^h
<td>`恒久的^i
<td>`6.6.1§
<td>

<tr><td>`ETag^h
<td>`恒久的^i
<td>`8.8.3§
<td>

<tr><td>`Expect^h
<td>`恒久的^i
<td>`10.1.1§
<td>

<tr><td>`From^h
<td>`恒久的^i
<td>`10.1.2§
<td>

<tr><td>`Host^h
<td>`恒久的^i
<td>`7.2§
<td>

<tr><td>`If-Match^h
<td>`恒久的^i
<td>`13.1.1§
<td>

<tr><td>`If-Modified-Since^h
<td>`恒久的^i
<td>`13.1.3§
<td>

<tr><td>`If-None-Match^h
<td>`恒久的^i
<td>`13.1.2§
<td>

<tr><td>`If-Range^h
<td>`恒久的^i
<td>`13.1.5§
<td>

<tr><td>`If-Unmodified-Since^h
<td>`恒久的^i
<td>`13.1.4§
<td>

<tr><td>`Last-Modified^h
<td>`恒久的^i
<td>`8.8.2§
<td>

<tr><td>`Location^h
<td>`恒久的^i
<td>`10.2.2§
<td>

<tr><td>`Max-Forwards^h
<td>`恒久的^i
<td>`7.6.2§
<td>

<tr><td>`Proxy-Authenticate^h
<td>`恒久的^i
<td>`11.7.1§
<td>

<tr><td>`Proxy-Authentication-Info^h
<td>`恒久的^i
<td>`11.7.3§
<td>

<tr><td>`Proxy-Authorization^h
<td>`恒久的^i
<td>`11.7.2§
<td>

<tr><td>`Range^h
<td>`恒久的^i
<td>`14.2§
<td>

<tr><td>`Referer^h
<td>`恒久的^i
<td>`10.1.3§
<td>

<tr><td>`Retry-After^h
<td>`恒久的^i
<td>`10.2.3§
<td>

<tr><td>`Server^h
<td>`恒久的^i
<td>`10.2.4§
<td>

<tr><td>`TE^h
<td>`恒久的^i
<td>`10.1.4§
<td>

<tr><td>`Trailer^h
<td>`恒久的^i
<td>`6.6.2§
<td>

<tr><td>`Upgrade^h
<td>`恒久的^i
<td>`7.8§
<td>

<tr><td>`User-Agent^h
<td>`恒久的^i
<td>`10.1.5§
<td>

<tr><td>`Vary^h
<td>`恒久的^i
<td>`12.5.5§
<td>

<tr><td>`Via^h
<td>`恒久的^i
<td>`7.6.3§
<td>

<tr><td>`WWW-Authenticate^h
<td>`恒久的^i
<td>`11.6.1§
<td>

<tr><td>`*^h
<td>`恒久的^i
<td>`12.5.5§
<td>（予約-済み）
</table>
◎
Table 9
Field Name｜Status｜Section｜Comments
Accept｜permanent｜12.5.1｜
Accept-Charset｜deprecated｜12.5.2｜
Accept-Encoding｜permanent｜12.5.3｜
Accept-Language｜permanent｜12.5.4｜
Accept-Ranges｜permanent｜14.3｜
Allow｜permanent｜10.2.1｜
Authentication-Info｜permanent｜11.6.3｜
Authorization｜permanent｜11.6.2｜
Connection｜permanent｜7.6.1｜
Content-Encoding｜permanent｜8.4｜
Content-Language｜permanent｜8.5｜
Content-Length｜permanent｜8.6｜
Content-Location｜permanent｜8.7｜
Content-Range｜permanent｜14.4｜
Content-Type｜permanent｜8.3｜
Date｜permanent｜6.6.1｜
ETag｜permanent｜8.8.3｜
Expect｜permanent｜10.1.1｜
From｜permanent｜10.1.2｜
Host｜permanent｜7.2｜
If-Match｜permanent｜13.1.1｜
If-Modified-Since｜permanent｜13.1.3｜
If-None-Match｜permanent｜13.1.2｜
If-Range｜permanent｜13.1.5｜
If-Unmodified-Since｜permanent｜13.1.4｜
Last-Modified｜permanent｜8.8.2｜
Location｜permanent｜10.2.2｜
Max-Forwards｜permanent｜7.6.2｜
Proxy-Authenticate｜permanent｜11.7.1｜
Proxy-Authentication-Info｜permanent｜11.7.3｜
Proxy-Authorization｜permanent｜11.7.2｜
Range｜permanent｜14.2｜
Referer｜permanent｜10.1.3｜
Retry-After｜permanent｜10.2.3｜
Server｜permanent｜10.2.4｜
TE｜permanent｜10.1.4｜
Trailer｜permanent｜6.6.2｜
Upgrade｜permanent｜7.8｜
User-Agent｜permanent｜10.1.5｜
Vary｜permanent｜12.5.5｜
Via｜permanent｜7.6.3｜
WWW-Authenticate｜permanent｜11.6.1｜
*｜permanent｜12.5.5｜(reserved)
</div>

<p id="field.asterisk">
~field名
"`*@h" は、
予約される
— その名前は、
`Vary$h ~headerにおいて特別な意味論があり，
~HTTP~headerとして利用すると競合するかもしれないので。
◎
The field name "*" is reserved because using that name as an HTTP header field might conflict with its special semantics in the Vary header field (Section 12.5.5).
</p>

<p>
~IANAは、
新たな~registryにおける "`Content-MD5^h" ~entryの位置付けを `廃用d^i に更新した
— 次への参照も伴わせた上で
⇒＃
（この~fieldを定義した） `2616/14.15$rfc,
（その定義を除去した） `RFC7231$r `B＠~RFC7231#appendix-B§
◎
IANA has updated the "Content-MD5" entry in the new registry to have a status of 'obsoleted' with references to Section 14.15 of [RFC2616] (for the definition of the header field) and Appendix B of [RFC7231] (which removed the field definition from the updated specification).
</p>

		</section>
		<section id="auth.scheme.registration">
<h3 title="Authentication Scheme Registration">18.5. 認証~schemeの登録</h3>

<p>
~IANAは、
`~HTTP認証~scheme~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry^en ）
を
`16.4.1§ の登録~手続-に従って更新した
— この文書~内に定義される認証~schemeは無い。
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Authentication Scheme Registry" at &lt;https://www.iana.org/assignments/http-authschemes&gt; with the registration procedure of Section 16.4.1. No authentication schemes are defined in this document.
</p>

		</section>
		<section id="content.coding.registration">
<h3 title="Content Coding Registration">18.6. 内容~符号法の登録</h3>

<p>
~IANAは、
`~HTTP内容~符号法~registry＠~IANA-a/http-parameters/$cite
（ `HTTP Content Coding Registry^en ）
を更新した
— `16.6.1§ の登録~手続-に従って，
次の表tに要約される内容~符号法~名を伴うよう：
◎
IANA has updated the "HTTP Content Coding Registry" at &lt;https://www.iana.org/assignments/http-parameters/&gt; with the registration procedure of Section 16.6.1 and the content coding names summarized in the table below.
</p>

<div>
<table id="iana.content.coding.registration.table"><thead>
<tr><th>名前
<th>記述
<th style="min-width:7em;">§
<tbody>

<tr><td>`compress$c
<td>~UNIX "compress" ~data形式 `Welch$r
<td>`8.4.1.1§

<tr><td>`deflate$c
<td>"zlib" ~data形式 `RFC1950$r の内側にある，
"deflate" で圧縮された~data `RFC1951$r
<td>`8.4.1.2§

<tr><td>`gzip$c
<td>GZIP ~file形式 `RFC1952$r
<td>`8.4.1.3§

<tr><td>`identity$c
<td>予約-済み
<td>`Accept§h

<tr><td>`x-compress^c
<td>非推奨d（ `compress$c 用の別名）
<td>`8.4.1.1§

<tr><td>`x-gzip^c
<td>非推奨d（ `gzip$c 用の別名）
<td>`8.4.1.3§
</table>
◎
Table 10
Name｜Description｜Section
compress｜UNIX "compress" data format [Welch] ｜8.4.1.1
deflate｜"deflate" compressed data ([RFC1951]) inside the "zlib" data format ([RFC1950])｜8.4.1.2
gzip｜GZIP file format [RFC1952] ｜8.4.1.3
identity｜Reserved｜12.5.3
x-compress｜Deprecated (alias for compress)｜8.4.1.1
x-gzip｜Deprecated (alias for gzip)｜8.4.1.3
</div>

		</section>
		<section id="range.unit.registration">
<h3 title="Range Unit Registration">18.7. 範囲~単位の登録</h3>

<p>
~IANAは、
`~HTTP範囲~単位~registry＠~IANA-a/http-parameters/$cite
（ `HTTP Range Unit Registry^en ）
を更新した
— `16.5.1§ の登録~手続-に従って，
次の表tに要約される範囲~単位~名を伴うよう：
◎
IANA has updated the "HTTP Range Unit Registry" at &lt;https://www.iana.org/assignments/http-parameters/&gt; with the registration procedure of Section 16.5.1 and the range unit names summarized in the table below.
</p>

<div>
<table id="iana.range.units.table"><thead>
<tr><th>範囲~単位~名
<th>記述
<th>§
<tbody>

<tr><td>`bytes$c
<td>~octet単位による範囲
<td>`14.1.2§

<tr><td>`none$c
<td>`範囲~要請$は~supportされないことを指示する~keywordとして、
予約される
<td>`14.3§
</table>
◎
Table 11
Range Unit Name｜Description｜Section
bytes｜a range of octets｜14.1.2
none｜reserved as keyword to indicate range requests are not supported｜14.3
</div>

		</section>
		<section id="media.type.reg">
<h3 title="Media Type Registration">18.8. ~MIME型の登録</h3>

<p>
~IANAは、
`~MIME型~registry＠~IANA-a/media-types$cite
（ `Media Types registry^en ）
を［
`~MIME型$ "`multipart/byteranges$c" 用の登録~情報
］を伴うよう更新した。
◎
IANA has updated the "Media Types" registry at &lt;https://www.iana.org/assignments/media-types&gt; with the registration information in Section 14.6 for the media type "multipart/byteranges".
</p>

<p>
~IANAは、
"`q$c" ~parameterについての~registry注記を，
この文書の `Accept§h への~linkを伴うよう更新した。
◎
IANA has updated the registry note about "q" parameters with a link to Section 12.5.1 of this document.
</p>

		</section>
		<section id="port.reg">
<h3 title="Port Registration">18.9. ~portの登録</h3>

<p>
~IANAは、［
~UDP ／ ~TCP
］を利用する~port［
80, 443
］上の~service用に，
`~service名と~transport~protocol~port番号~registry$cite
（ `Service Name and Transport Protocol Port Number Registry^en ）
を次のように更新した：
◎
IANA has updated the "Service Name and Transport Protocol Port Number Registry" at &lt;https://www.iana.org/assignments/service-names-port-numbers/&gt; for the services on ports 80 and 443 that use UDP or TCP to:
</p>
<ul>
	<li>
この文書を “参照” として利用する
◎
use this document as "Reference", and
</li>
	<li>
現在~未指定であった［
“`Assignee^en” は "IESG",
“`Contact^en” は "IETF_Chair"
］に設定する。
◎
when currently unspecified, set "Assignee" to "IESG" and "Contact" to "IETF_Chair".
</li>
</ul>

		</section>
		<section id="upgrade.token.registration">
<h3 title="Upgrade Token Registration">18.10. `Upgrade^h ~tokenの登録</h3>

<p>
~IANAは、
`~HTTP~Upgrade~token~registry$cite
（ `Hypertext Transfer Protocol (HTTP) Upgrade Token Registry^en ）
を更新した
— `16.7§ に述べた登録~手続-に従って，
次の表tに要約される `Upgrade$h ~token名を伴うよう：
◎
IANA has updated the "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" at &lt;https://www.iana.org/assignments/http-upgrade-tokens&gt; with the registration procedure described in Section 16.7 and the upgrade token names summarized in the following table.
</p>

<div>
<table><thead>
<tr><th>名前
<th>記述
<th>期待される~version~token
<th>§
<tbody>

<tr><td>`HTTP^c
<td>Hypertext Transfer Protocol
<td>任意の <code class="production">`DIGIT$P.`DIGIT$P</code> （例： "`2.0^c" ）
<td>`2.5§
</table>
◎
Table 12
Name｜Description｜Expected Version Tokens｜Section
HTTP｜Hypertext Transfer Protocol｜any DIGIT.DIGIT (e.g., "2.0")｜2.5
</div>

		</section>
	</section>
	<section id="collected.abnf">
<h2 title="Collected ABNF">付録 A. 総集的~ABNF</h2>

<p class="trans-note">【
この節は未訳。
】</p>

	</section>
	<section id="changes.from.previous.rfcs">
<h2 title="Changes from Previous RFCs">付録 B. 以前の~RFCからの変更点</h2>

		<section id="changes.from.rfc.2818">
<h3 title="Changes from RFC 2818">B.1. RFC 2818 からの変更点</h3>

<p>
<del>無い。</del>
◎
None.
</p>

<p class="trans-note">【
`7105$errata（Verified）：
~CN-IDの利用は非推奨にされた。
（ `4.3.4§ ）
】</p>

		</section>
		<section id="changes.from.rfc.7230">
<h3 title="Changes from RFC 7230">B.2. RFC 7230 からの変更点</h3>

<p>
~HTTPの［
設計~目標,
歴史,
~architecture,
適合性の判定基準,
~protocol~version法,
~URI,
~message~route法,
`~header$
］を導入している各~節は、
ここに移動された。
◎
The sections introducing HTTP's design goals, history, architecture, conformance criteria, protocol versioning, URIs, message routing, and header fields have been moved here.
</p>

<p>
意味論上の適合性に対する要件は、
実装に特有な失敗［
を無視する／に対処する
］ことの許可に置換された。
（ `2.2§ ）
◎
The requirement on semantic conformance has been replaced with permission to ignore or work around implementation-specific failures. (Section 2.2)
</p>

<p>
［
`生成元$, および`生成元~server$への権限的な~access
］についての記述は、
~TCPに基づくとは限らない［
代替な~service／~secure化された接続
］も織り込むため，［
"`http^c", "`https^c"
］両~URI用に拡張された。
（ `http§c, `https§c, `4.3.1§, `7.3.3§ ）
◎
The description of an origin and authoritative access to origin servers has been extended for both "http" and "https" URIs to account for alternative services and secured connections that are not necessarily based on TCP. (Sections 4.2.1, 4.2.2, 4.3.1, and 7.3.3)
</p>

<p>
［
`~target~URI$の~schemeの意味論を検査して、
それに結付けられた要件を満たさない要請は，却下する
］とする，明示的な要件を追加した。
（ `7.4§ ）
◎
Explicit requirements have been added to check the target URI scheme's semantics and reject requests that don't meet any associated requirements. (Section 7.4)
</p>

<p>
［
`media-type$p ／ `media-range$p ／ `expectation$p
］内の `parameters$p は、
尾部にある 1 個以上の~semicolonを介して空になり得る。
（ `5.6.6§ ）
◎
Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)
</p>

<p>
`~field値$は、
今や複数個の~field行lの値を~commaで結合した後の値を指す
— それが他よりずっと共通的な利用なので。
単独の`~field行l$【！~header行l】【！`6.3§】の値を指すときは、
`~field行l値$を利用すること。
◎
"Field value" now refers to the value after multiple field lines are combined with commas -- by far the most common use. To refer to a single header line's value, use "field line value". (Section 6.3)
</p>

<p>
`~trailer$の意味論は、
今や `chunked$c `転送~符号法$に特有なそれを超越している
（ `6.5.1§ ）：
◎
Trailer field semantics now transcend the specifics of chunked transfer coding.＼
</p>
<ul>
	<li>
<p>
`~trailer$の利用は、
更に制限された：
◎
The use of trailer fields has been further limited＼
</p>
		<ul>
			<li>
`~trailer$としての生成は、
送信者が［
当の`~field$は、
そのような用法を定義している
］ことを知っているときに限り許容される。
◎
to allow generation as a trailer field only when the sender knows the field defines that usage and＼
</li>
			<li>
`~trailer$を`~header節$の中に併合することは、
受信者が［
対応する~field定義は、
そうすることを許可していて，そうする方法を定義する
］ことを知っている場合に限り，許容される。
◎
to allow merging into the header section only if the recipient knows the corresponding field definition permits and defines how to merge.＼
</li>
		</ul>
	</li>
	<li>
他のすべての事例では、
実装には、
`~trailer$を併合する代わりに，別々に格納するか破棄することが奨励される。
◎
In all other cases, implementations are encouraged either to store the trailer fields separately or to discard them instead of merging. (Section 6.5.1)
</li>
</ul>

<p>
`絶対~形$による要請~URIの優先度を
— ~proxyの取扱いに揃えるため —
明示的に，`生成元~server$による `Host^h ~headerよりも高くした。
（ `Host§h ）
◎
The priority of the absolute form of the request URI over the Host header field by origin servers has been made explicit to align with proxy handling. (Section 7.2)
</p>

<p>
`Via^h ~fieldの `received-by$p 用の文法~定義は、［
~URI文法における `host$p に対する変更 `URI$r
］に因り `RFC7230$r において拡げられたが，
`Via^h 用には望ましくない。
単純にするため， `received-by$p 生成規則から `uri-host$p を除去した
— それは、
既存の `pseudonym$p 用の文法により包摂できるので。
特に，この変更により、［
`received-by$p において~host名に許容される文字たちが成す集合
］から，~commaが除去された。
（ `Via§h ）
◎
The grammar definition for the Via field's "received-by" was expanded in RFC 7230 due to changes in the URI grammar for host [URI] that are not desirable for Via. For simplicity, we have removed uri-host from the received-by production because it can be encompassed by the existing grammar for pseudonym. In particular, this change removed comma from the allowed set of characters for a host name in received-by. (Section 7.6.3)
</p>

		</section>
		<section id="changes.from.rfc.7231">
<h3 title="Changes from RFC 7231">B.3. RFC 7231 からの変更点</h3>

<p>
実装が~supportすることになる最小な~URI長さは、
今や推奨される。
（ `4.1§ ）
◎
Minimum URI lengths to be supported by implementations are now recommended. (Section 4.1)
</p>

<div class="p">
<p>
次について明確化した
（ `5.5§ ）：
◎
The following have been clarified:＼
</p>
<ul>
	<li>
`~field値$内の［
`CR$P ／ `NUL^P
］は、
却下されるか， `SP$P に対応付けられる。
◎
CR and NUL in field values are to be rejected or mapped to SP,＼
</li>
	<li>
［
頭部／尾部
］を成す空白は、
消費される前に`~field値$から剥取る必要がある。
◎
and leading and trailing whitespace needs to be stripped from field values before they are consumed. (Section 5.5)
</li>
</ul>
</div>

<p>
［
`media-type$p ／ `media-range$p ／ `expectation$p
］内の `parameters$p は、
尾部にある 1 個以上の~semicolonを介して空になり得る。
（ `5.6.6§ ）
◎
Parameters in media type, media range, and expectation can be empty via one or more trailing semicolons. (Section 5.6.6)
</p>

<p>
~messageを成す各種~成分と それらの意味論を複数の~HTTP~versionにまたがる抽象-化として定義するため、
~HTTP~message用の抽象-~data型を導入した
— `HTTP/1.1$r における~HTTP11に特有な構文の形によらない, かつ~messageを構文解析した後の内容を反映するよう。
これは、
`内容$に対する要件（何が伝達されるか）と~message法~構文に対する要件（どう伝達されるか）を より判別し易くすることに加え，
早期の`~protocol~version$における制限を将来の~HTTPの中に焼付けることを避ける。
（ `6§ ）
◎
An abstract data type for HTTP messages has been introduced to define the components of a message and their semantics as an abstraction across multiple HTTP versions, rather than in terms of the specific syntax form of HTTP/1.1 in [HTTP/1.1], and reflect the contents after the message is parsed. This makes it easier to distinguish between requirements on the content (what is conveyed) versus requirements on the messaging syntax (how it is conveyed) and avoids baking limitations of early protocol versions into the future of HTTP. (Section 6)
</p>

<p>
用語［
“~payload”, “~payload本体”
］を “`内容$” に置換した
— 他所における（例：`~field名$における）その用法に もっと良く揃えるため，および［
~HTTP2／~HTTP3
］における~frame~payloadとの混同を避けるため。
（ `6.4§ ）
◎
The terms "payload" and "payload body" have been replaced with "content", to better align with its usage elsewhere (e.g., in field names) and to avoid confusion with frame payloads in HTTP/2 and HTTP/3. (Section 6.4)
</p>

<p>
用語 “実効~要請~URI” を “`~target~URI$” に置換した。
（ `7.1§ ）
◎
The term "effective request URI" has been replaced with "target URI". (Section 7.1)
</p>

<p>
~clientによる再試行に対する制約を実装の挙動を反映するよう~~緩めた。
（ `9.2.2§ ）
◎
Restrictions on client retries have been loosened to reflect implementation behavior. (Section 9.2.2)
</p>

<p>
［
`GET^m ／ `HEAD^m ／ `DELETE^m
］要請~内の`内容$【！本体】は相互運用可能でない事実を明確化した。
（ `GET§m ／ `HEAD§m ／ `DELETE§m ）
◎
The fact that request bodies on GET, HEAD, and DELETE are not interoperable has been clarified. (Sections 9.3.1, 9.3.2, and 9.3.5)
</p>

<p>
`Content-Range$h ~headerを `PUT^m 要請に対する改変子として利用することを許容した。
（ `PUT§m ）
◎
The use of the Content-Range header field (Section 14.4) as a request modifier on PUT is allowed. (Section 9.3.4)
</p>

<p>
`OPTIONS^m ~methodの記述から `Content-Length$h の設定についての過剰な要件を除去した。
（ `OPTIONS§m ）
◎
A superfluous requirement about setting Content-Length has been removed from the description of the OPTIONS method. (Section 9.3.7)
</p>

<p>
［
`TRACE$m 応答~内には~MIME型 `message/http＠~HTTPv1#media.type.message.http$c を利用する
］とする規範的な要件を除去した。
（ `TRACE§m ）
◎
The normative requirement to use the "message/http" media type in TRACE responses has been removed. (Section 9.3.8)
</p>

<p>
RFC 2616 との互換性を得るため、
`Expect^h 用に，~listに基づく文法を復旧した（ `Expect§h ）
◎
List-based grammar for Expect has been restored for compatibility with RFC 2616. (Section 10.1.1)
</p>

<p>
`応答~message$内にも［
`Accept$h ／ `Accept-Encoding$h
］を許容した
— 後者は `RFC7694$r により導入された。
（ `12.3§ ）
◎
Accept and Accept-Encoding are allowed in response messages; the latter was introduced by [RFC7694]. (Section 12.3)
</p>

<p>
`Accept^h ~fieldの定義から［
`accept-params^p, `accept-ext^p
］~ABNF生成規則を【その `weight^p のみを残して】除去した。
（ `Accept§h ）
◎
"Accept Parameters" (accept-params and accept-ext ABNF production) have been removed from the definition of the Accept field. (Section 12.5.1)
</p>

<p>
`Accept-Charset^h ~fieldは、
今や非推奨にされた。
（ `Accept-Charset§h ）
◎
The Accept-Charset field is now deprecated. (Section 12.5.2)
</p>

<p>
`Vary^h ~header内に［
"`*^c" が他の値とともに在るとき
］の意味論を明確化した。
（ `Vary§h ）
◎
The semantics of "*" in the Vary header field when other values are present was clarified. (Section 12.5.5)
</p>

<p>
`範囲~単位$は、
文字大小無視で比較するものとした。
（ `14.1§ ）
◎
Range units are compared in a case-insensitive fashion. (Section 14.1)
</p>

<p>
`Accept-Ranges^h ~fieldの利用は、
`生成元~server$のみに制約されないとした。
（ `Accept-Ranges§h ）
◎
The use of the Accept-Ranges field is not restricted to origin servers. (Section 14.3)
</p>

<p>
~redirectされた要請【に対し，送信し直す要請】を作成する処理nを明確化した。
（ `3xx§st0 ）
◎
The process of creating a redirected request has been clarified. (Section 15.4)
</p>

<p>
状態s~code `308^st0 を追加した（以前は `RFC7538$r にて定義されていた）
— 状態s~code `301$st0, `302$st0, `307$st0 の近くに定義されるよう。
（ `308§st0 ）
◎
Status code 308 (previously defined in [RFC7538]) has been added so that it's defined closer to status codes 301, 302, and 307. (Section 15.4.9)
</p>

<p>
状態s~code `421^st0 を追加した（以前は `7540/9.1.2$rfc にて定義されていた）
— それには、
一般的な適用能があるので。
`421^st0 は、
もはや`経験的に~cache可能$であるものとは定義されない
— 当の応答は、
（`~target資源$ではなく）当の接続に特有~なので（ `421§st0 ）
◎
Status code 421 (previously defined in Section 9.1.2 of [RFC7540]) has been added because of its general applicability. 421 is no longer defined as heuristically cacheable since the response is specific to the connection (not the target resource). (Section 15.5.20)
</p>

<p>
状態s~code `422^st0 を追加した（以前は `WEBDAV$r `11.2＠~RFCx/rfc4918#section-11.2§ にて定義されていた）
— それには、
一般的な適用能があるので。
（ `422§st0 ）
◎
Status code 422 (previously defined in Section 11.2 of [WEBDAV]) has been added because of its general applicability. (Section 15.5.21)
</p>

		</section>
		<section id="changes.from.rfc.7232">
<h3 title="Changes from RFC 7232">B.4. RFC 7232 からの変更点</h3>

<p>
~HTTPの以前の改訂では、［
`Last-Modified$h が強い検証子を与えているかどうかの決定
］に［
恣意的な上限 60 秒
］を課していた
— `Date$h 値と `Last-Modified$h 値が［
異なる`時計$から`生成-$されるアリ性, あるいは
応答を準備する間に時刻がずれること
］に抗して防護するために。
この仕様は、
適度な裁量を許容するよう，それを緩めた。
（ `8.8.2.2§ ）
◎
Previous revisions of HTTP imposed an arbitrary 60-second limit on the determination of whether Last-Modified was a strong validator to guard against the possibility that the Date and Last-Modified values are generated from different clocks or at somewhat different times during the preparation of the response. This specification has relaxed that to allow reasonable discretion. (Section 8.8.2.2)
</p>

<p>
［
`If-Match^h ／ `If-Unmodified-Since^h
］に対する際どい事例における要件を除去した
— それは、
当の変更~要請が すでに適用-済みであったため，検証に失敗したときには、
`2xx$st0 応答~内に検証子を送信しないことを要求していた。
（ `If-Match§h, `If-Unmodified-Since§h ）
◎
An edge-case requirement on If-Match and If-Unmodified-Since has been removed that required a validator not to be sent in a 2xx response if validation fails because the change request has already been applied. (Sections 13.1.1 and 13.1.4)
</p>

<p>
`If-Unmodified-Since^h は、
改変~時刻の概念が無い資源には，適用されない事実を明確化した。
（ `If-Unmodified-Since§h ）
【が、該当する記述は，後の更新により削除された。】
◎
The fact that If-Unmodified-Since does not apply to a resource without a concept of modification time has been clarified. (Section 13.1.4)
</p>

<p>
`事前条件$は，今や、
要請の`内容$が処理される前に
— 処理した結果，成功裡な応答になるかどうか待機することなく —
評価され得る。
（ `13.2§ ）
◎
Preconditions can now be evaluated before the request content is processed rather than waiting until the response would otherwise be successful. (Section 13.2)
</p>

		</section>
		<section id="changes.from.rfc.7233">
<h3 title="Changes from RFC 7233">B.5. RFC 7233 からの変更点</h3>

<p>
［
`range-unit$p,
`ranges-specifier$p
］文法を~~再構成して、
`bytes$c と他の（拡張）範囲~単位との間の人為的な区別を単純~化し，抑制した
— `範囲~単位$を汎用な `token$p として定義して，拡張（ `other-range$p ）を `range-spec$p の視野の中に置くことにより、
`other-range-unit^p の重合している文法は除去された。
これは，拡張~範囲~単位を含む すべての範囲~集合において、
~list構文（~comma）の役割を
— 複数個の範囲の `range-set$p を指示するよう —
一義化する。
拡張~文法を範囲~指定子の中に移動することは、
`~byte範囲$に特有な~protocolを別々に指定することも許容する。
◎
Refactored the range-unit and ranges-specifier grammars to simplify and reduce artificial distinctions between bytes and other (extension) range units, removing the overlapping grammar of other-range-unit by defining range units generically as a token and placing extensions within the scope of a range-spec (other-range). This disambiguates the role of list syntax (commas) in all range sets, including extension range units, for indicating a range-set of more than one range. Moving the extension grammar into range specifiers also allows protocol specific to byte ranges to be specified separately.
</p>

<p>
今や，拡張~methodに対しても`範囲~要請$の取扱いを定義することをアリにした。
（ `Range§h ）
◎
It is now possible to define Range handling on extension methods. (Section 14.2)
</p>

<p>
`Content-Range$h ~headerを
`PUT$m 要請に対する改変子として利用して，部分的な `PUT$m を遂行することについて述べた。
（ `14.5§ ）
◎
Described use of the Content-Range header field (Section 14.4) as a request modifier to perform a partial PUT. (Section 14.5)
</p>

		</section>
		<section id="changes.from.rfc.7235">
<h3 title="Changes from RFC 7235">B.6. RFC 7235 からの変更点</h3>

<p>
無い。
◎
None.
</p>

		</section>
		<section id="changes.from.rfc.7538">
<h3 title="Changes from RFC 7538">B.7. RFC 7538 からの変更点</h3>

<p>
無い。
◎
None.
</p>

		</section>
		<section id="changes.from.rfc.7615">
<h3 title="Changes from RFC 7615">B.8. RFC 7615 からの変更点</h3>

<p>
無い。
◎
None.
</p>

		</section>
		<section id="changes.from.rfc.7694">
<h3 title="Changes from RFC 7694">B.9. RFC 7694 からの変更点</h3>

<p>
この仕様は、
`RFC7694$r により定義された拡張を含む
— その［
§ 例,
§ 配備~上の考慮点
］は、
割愛するが。
◎
This specification includes the extension defined in [RFC7694] but leaves out examples and deployment considerations.
</p>

		</section>
	</section>
	<section id="acks">
<h2 title="Acknowledgements">謝辞</h2>

<p>
現在の編集者たちとは別に、
次に挙げる各個人による~HTTPを成す早期の側面と中核~仕様に対する貢献は，特別な認識に価する：
◎
Aside from the current editors, the following individuals deserve special recognition for their contributions to early aspects of HTTP and its core specifications:＼
</p>

<div lang="en">
Marc Andreessen, Tim Berners-Lee, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, Jim Gettys, Jean-François Groff, Phillip M. Hallam-Baker, Koen Holtman, Jeffery L. Hostetler, Shel Kaphan, Dave Kristol, Yves Lafon, Scott D. Lawrence, Paul J. Leach, Håkon W. Lie, Ari Luotonen, Larry Masinter, Rob McCool, Jeffrey C. Mogul, Lou Montulli, David Morris, Henrik Frystyk Nielsen, Dave Raggett, Eric Rescorla, Tony Sanders, Lawrence C. Stewart, Marc VanHeyningen, and Steve Zilles.
</div>

<p>
この文書は、［
次に挙げるものを含む，過去の~HTTP仕様
］に対する多くの貢献の上に築かれている
— それらの文書の中の謝辞もまた適用される
⇒＃
`HTTP/1.0$r,
`RFC2068$r,
`RFC2145$r,
`RFC2616$r,
`RFC2617$r,
`RFC2818$r,
`RFC7230$r,
`RFC7231$r,
`RFC7232$r,
`RFC7233$r,
`RFC7234$r,
`RFC7235$r
◎
This document builds on the many contributions that went into past specifications of HTTP, including [HTTP/1.0], [RFC2068], [RFC2145], [RFC2616], [RFC2617], [RFC2818], [RFC7230], [RFC7231], [RFC7232], [RFC7233], [RFC7234], and [RFC7235]. The acknowledgements within those documents still apply.
</p>

<p>
次に挙げる貢献者たちは、
2014年から，この仕様の改善に向けて助力された
— ~bugを報告して／
賢明な質問を依頼して／
~textを草案~化したり考査して／
課題を評価して：
◎
Since 2014, the following contributors have helped improve this specification by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating issues:
</p>

<div lang="en">
Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Duby, Asanka Herath, Asbjørn Ulsberg, Asta Olofsson, Attila Gulyas, Austin Wright, Barry Pollard, Ben Burkert, Benjamin Kaduk, Björn Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Dale Worley, Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla, Éric Vyncke, Erik Kline, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky, Florian Best, Francesca Palombini, Igor Lubashev, James Callahan, James Peach, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan, 奥 一穂 (Kazuho Oku), Ken Murchison, Krzysztof Maczyński, Lars Eggert, Lucas Pardue, Martin Duke, Martin Dürst, Martin Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Mattias Grenfeldt, Michael Osipov, Mike Bishop, Mike Pennisi, Mike Taylor, Mike West, Mohit Sethi, Murray Kucherawy, Nathaniel J. Smith, Nicholas Hurley, Nikita Prokhorov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van Rein, Robert Wilton, Roberto Polli, Roman Danyliw, Samuel Williams, Semyon Kholodnov, Simon Pieters, Simon Schüppel, Stefan Eissing, Taylor Hunt, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu, Yishuai Li, and Zaheduzzaman Sarker.
</div>

	</section>
	<section id="rfc.authors">
<h2 title="Authors' Addresses">著作者の~address</h2>

<p lang="en" style="white-space:pre;">
Roy T. Fielding (editor)
Adobe
345 Park Ave
San Jose, CA 95110
United States of America
EMail: fielding@gbiv.com
URI: https://roy.gbiv.com/

Mark Nottingham (editor)
Fastly
Prahran
Australia
EMail: mnot@mnot.net
URI: https://www.mnot.net/

Julian Reschke (editor)
greenbytes GmbH
Hafenweg 16
48155 Münster
Germany
EMail: julian.reschke@greenbytes.de
URI: https://greenbytes.de/tech/webdav/
</p>

	</section>
</main></div>