RFC7231-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>RFC 7231 — HTTP/1.1: Semantics and Content （日本語訳）</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="RFC723X.js"></script>
<script src="common1.js" async></script>

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


●●options

spec_title:RFC 7231 — HTTP/1.1: Semantics and Content
trans_update:2020-11-03
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc7231.html
spec_status:IETFPR
abbr_url:7231
no_original_dfn:true
trans_1st_pub:2014-12-07

●●mdn_urls
header.accept:HTTP/Headers/Accept
header.accept-charset:HTTP/Headers/Accept-Charset
header.accept-encoding:HTTP/Headers/Accept-Encoding
header.accept-language:HTTP/Headers/Accept-Language
header.allow:HTTP/Headers/Allow
header.content-type:HTTP/Headers/Content-Type
header.content-encoding:HTTP/Headers/Content-Encoding
header.content-language:HTTP/Headers/Content-Language
header.content-location:HTTP/Headers/Content-Location
header.date:HTTP/Headers/Date
header.expect:HTTP/Headers/Expect
header.from:HTTP/Headers/From
	header.max-forwards:HTTP/Headers/Max-Forwards
mime-version:HTTP/Headers/MIME-Version
	header.mime-version:HTTP/Headers/MIME-Version
header.location:HTTP/Headers/Location
header.referer:HTTP/Headers/Referer
header.retry-after:HTTP/Headers/Retry-After
header.server:HTTP/Headers/Server
header.user-agent:HTTP/Headers/User-Agent
header.vary:HTTP/Headers/Vary

CONNECT:HTTP/Methods/CONNECT
DELETE:HTTP/Methods/DELETE
GET:HTTP/Methods/GET
HEAD:HTTP/Methods/HEAD
OPTIONS:HTTP/Methods/OPTIONS
POST:HTTP/Methods/POST
PUT:HTTP/Methods/PUT
TRACE:HTTP/Methods/TRACE

status.codes:HTTP/Status
status.100:HTTP/Status/100
status.101:HTTP/Status/101
status.200:HTTP/Status/200
status.201:HTTP/Status/201
status.202:HTTP/Status/202
status.203:HTTP/Status/203
status.204:HTTP/Status/204
status.205:HTTP/Status/205
status.300:HTTP/Status/300
status.301:HTTP/Status/301
status.302:HTTP/Status/302
status.303:HTTP/Status/303
status.305:HTTP/Status/305
status.306:HTTP/Status/306
status.307:HTTP/Status/307
status.400:HTTP/Status/400
status.402:HTTP/Status/402
status.403:HTTP/Status/403
status.404:HTTP/Status/404
status.405:HTTP/Status/405
status.406:HTTP/Status/406
status.408:HTTP/Status/408
status.409:HTTP/Status/409
status.410:HTTP/Status/410
status.411:HTTP/Status/411
status.413:HTTP/Status/413
status.414:HTTP/Status/414
status.415:HTTP/Status/415
status.417:HTTP/Status/417
status.426:HTTP/Status/426
status.500:HTTP/Status/500
status.501:HTTP/Status/501
status.502:HTTP/Status/502
status.503:HTTP/Status/503
status.504:HTTP/Status/504
status.505:HTTP/Status/505

●●link_map

wc.214:~7234#warn.214

c.multipart:#multipart.types
c.identity:#identity-token

	TODO
	p.userinfo:~3986#section-3.2.1
	p.host:~7230#p.uri-host
	p.asctime
	p.orig-date

c.q:#c.q
	~cache検証~要請:~7234#section-4.3
	条件付き:~7232#section-3
最終~受信者:#final-recipient
既定の重み:#defult-weight
	絶対~形:~7230#section-5.3.2
	要請:#request
	応答:#response
	行~折返し:#folding
期待:#expectation
~trailer節:~7230#trailer


●●section_map


1:introduction
1.1:conformance
1.2:notation
2:resources
3:representations
3.1:representation.metadata
3.1.1:data.type
3.1.1.1:media.type
3.1.1.2:charset
3.1.1.3:canonicalization.and.text.defaults
3.1.1.4:multipart.types
3.1.1.5:header.content-type
3.1.2:data.encoding
3.1.2.1:content.codings
3.1.2.2:header.content-encoding
3.1.3:audience.language
3.1.3.1:language.tags
3.1.3.2:header.content-language
3.1.4:identification
3.1.4.1:identifying.payload
3.1.4.2:header.content-location
3.2:representation.data
3.3:payload
3.4:content.negotiation
3.4.1:proactive.negotiation
3.4.2:reactive.negotiation
4:methods
4.1:method.overview
4.2:method.properties
4.2.1:safe.methods
4.2.2:idempotent.methods
4.2.3:cacheable.methods
4.3:method.definitions
4.3.1:GET
4.3.2:HEAD
4.3.3:POST
4.3.4:PUT
4.3.5:DELETE
4.3.6:CONNECT
4.3.7:OPTIONS
4.3.8:TRACE
5:request.header.fields
5.1:request.controls
5.1.1:header.expect
5.1.2:header.max-forwards
5.2:request.conditionals
5.3:request.conneg
5.3.1:quality.values
5.3.2:header.accept
5.3.3:header.accept-charset
5.3.4:header.accept-encoding
5.3.5:header.accept-language
5.4:request.auth
5.5:request.context
5.5.1:header.from
5.5.2:header.referer
5.5.3:header.user-agent
6:status.codes
6.1:overview.of.status.codes
6.2:status.1xx
6.2.1:status.100
6.2.2:status.101
6.3:status.2xx
6.3.1:status.200
6.3.2:status.201
6.3.3:status.202
6.3.4:status.203
6.3.5:status.204
6.3.6:status.205
6.4:status.3xx
6.4.1:status.300
6.4.2:status.301
6.4.3:status.302
6.4.4:status.303
6.4.5:status.305
6.4.6:status.306
6.4.7:status.307
6.5:status.4xx
6.5.1:status.400
6.5.2:status.402
6.5.3:status.403
6.5.4:status.404
6.5.5:status.405
6.5.6:status.406
6.5.7:status.408
6.5.8:status.409
6.5.9:status.410
6.5.10:status.411
6.5.11:status.413
6.5.12:status.414
6.5.13:status.415
6.5.14:status.417
6.5.15:status.426
6.6:status.5xx
6.6.1:status.500
6.6.2:status.501
6.6.3:status.502
6.6.4:status.503
6.6.5:status.504
6.6.6:status.505
7:response.header.fields
7.1:response.control.data
7.1.1:origination.date
7.1.1.1:http.date
7.1.1.2:header.date
7.1.2:header.location
7.1.3:header.retry-after
7.1.4:header.vary
7.2:response.validator
7.3:response.auth
7.4:response.context
7.4.1:header.allow
7.4.2:header.server
8:IANA.considerations
8.1:method.registry
8.1.1:method.registry.procedure
8.1.2:considerations.for.new.methods
8.1.3:method.registration
8.2:status.code.registry
8.2.1:status.code.registry.procedure
8.2.2:considerations.for.new.status.codes
8.2.3:status.code.registration
8.3:header.field.registry
8.3.1:considerations.for.new.header.fields
8.3.2:header.field.registration
8.4:content.coding.registry
8.4.1:content.coding.procedure
8.4.2:content.coding.registration
9:security.considerations
9.1:attack.pathname
9.2:attack.injection
9.3:personal.information
9.4:sensitive.information.in.uris
9.5:fragment.disclosure
9.6:disclosure.product.information
9.7:fingerprinting
10:acks
11:rfc.references
A:differences.between.http.and.mime
A.1:mime-version
A.2:conversion.to.canonical.form
A.3:conversion.of.date.formats
A.4:conversion.content-encoding
A.5:conversion.content-transfer-encoding
A.6:mhtml.line.length
B:changes.from.rfc.2616
C:imported.abnf
D:collected.abnf
	rfc.index:＊
	rfc.authors:＊


●●words_table1

tim:~tim


●●words_table

製品:product::~
下位製品:subproduct::~
厳密的:strict::~
符号化形:coded form::~::コード化形
発行-:issue:~
引換関係:trade-off:引き換え関係
特殊用途の:special-purpose:~
理解度:intelligibility:~
直交的:orthogonal:独立
禁じら:banさ:~
紙:paper:~
視聴者:audience:~
解析:analytics:~
話者:-literate audience:~
言語上の:linguistic:~
記事:article:~
誤入力:mistype:~
購入:purchase:~
頭字語:abbreviation:~
予防策:precaution:~
入門書:primer:~
sniff:
初学者:beginner:~
分野:area:~
厄介な:annoying:~
奇妙な:bizarre:~
循環的:cyclical:~
成員:membership:~
投函-:post:~
指示命令:instruction:~
export:
notepad::::ノートパッド
directory::::ディレクトリ
deactivate:::非 active 化:非アクティブ化
想起-:envision:~
想定-:suppose:~
strict::
subscription:
user-friendliness::
disagreement::
checksum::::チェックサム
民族:ethnic group:~
highlight::::ハイライト
idiom::::イディオム
loop-back::::ループバック
malformed:::
前身:predecessor:~
proactive::::プロアクティブ
reactive::::リアクティブ
	~reactiveに:react
pipe::::パイプ
文0:statement::文
whitelist::::ホワイトリスト
周知:well-known:~
in-band::帯域内::インバンド
in-line::::インライン
解釈器:interpreter::~::インタープリタ
intranet::::イントラネット
	~cross::::クロス\n\
spam::::スパム
peer::::ピア
	~~期待して:hopeして
モノ:thing:~
MHTML:
SMTP:
時間帯:zone::~
real-time::::リアルタイム
	deep linking
無限loop:black hole:無限ループ
変動:variance:~
裁量:discretion:~
補足-:supplement:~
英国:British:~
自由度:freedom:~
臨時の:limited-time:~
綴り:spell:~
読取専用:read-only:読み取り専用
負担:burden:~
緩和-:alleviate:~
配達:deployment:~
領収書:receipt document:~
加工:craft:~

特典:benefit:~
無差別:indiscriminate:~
切落す:truncateする:切り落とす
変動-:vary:~
変動:variance:~
窓:window:~

誂えら:tailorさ:あつらえら
誂える:tailorする:あつらえる
改行:line break:~
ニュースグループ:newsgroup:::~
メーリングリスト:mailing list:::~
ブログ:blog:::~
課金:charge:~
広告料:advertising account:~
掲示板:bulletin board:~
特権拡大:privilege escalation:~
担い:playし:~
満杯:full:~
分解-:decompose:~

自然言語:natural language:~
Maori::マオリ語
Danish::デンマーク語
Canada::カナダ
会話-:communicate:~
無用:useless:~
継続中:continuing:~
傾向:tendency:~
傾向に:tendに:~
分散-:distribute:~
大文字頭字:capitalization:~
解凍-:decompress:~
初回便:initial flight:~
trace:::追跡
決定要因:determining factor:~
実行済みで:enactされて:~
	挙げ:mention
無視r:disregard:無視することに
個人識別可能:personally identifiable:~
時事的:topical:~
居る:resideする:~
主流に:prevalentに:~
仮装-:masquerade:~
仮想:virtual::~
保つ:keepする:~
心配:fear:~
排他的:mutually exclusive:~
支配的な:prevailing:~
構築0:building:構築
編集-:edit:~
編集:editing:~
介入-:intervene:~
巨大0:huge:巨大
再組成:recomposition:~
display::::ディスプレイ
事実調査:research:~
未保護:unprotected:~
転化-:translate::~
木目細かな:fine-grainedな:~
上書-:overwrite::上書き
最大化する:maximizeする:最大限に得る
中立的:neutral:~
乏しい:poorな:~
非効率:inefficient:~
制定-:prescribe:~
取戻され:reclaimされ:取り戻され
分類上の:categorization:~
	分類し直:reclassify:~
損なう:loseする:~
損失:loss:~
逐語的:verbatim:~
縛られ:tieされ:~
包括的:comprehensive:~
進捗状況:progress:~
係数:factor:~
分岐:divergent:~
慣行:convention:~
明白:obvious:~
拡げる:expandする:~
頻繁:frequent:~
監視器:monitor::~::モニタ
瞬間:moment:~
参照元:referring:refer 元:~
連絡:contact:~
応答待ち:outstanding::~
冪等性:idempotent property::~
外向けの:outgoing:~
英字:letter:~
空行:blank line:~
強化-:enhance:~
収束-:converge:~
開示-:disclose:~
開示:disclosure:~
総意:consensus:~
合意:agreement:~
	ついて合意が得られなかった:disagreement over
各個人:individual:~

●●
	他の語
かまわない:free to
イミを成し得る:sensible
広告-用:advertising
~linkし直す:re-link
多量:large amount
型~付け:typing
当り障りのないもの:noncommittal
性向:in nature
ワイタンギ条約:Treaty of Waitangi
話す:speak する
言って:speaking
〜に関係する:in relation to
二重に:a second time
一連の:a series of
全面的に:entirely
両面both
通して渡され:pass through
から来た:came from
初回に:first time
事前に:before actually doing so
してもらうよう:encourage
回数:the number of times
複数の:more than one
最も:the most
反して:against
いつまでも:any length of time
責務者:person responsible for
値する:worthwhile
見かけ上はapparent
見かけの:apparent
その他:同類のsimilar
記事群:group of articles
策定者／作者:author: 2
舞台裏:man behind the curtain
注意を向けないpays no attention
陥ったdescended into
fashion:やり方
gradually:徐々に
害を及ぼすcausing harm
分間:minutes
大多数:overwhelming majority
~知る:立場にある:privy
いわゆる:so-called
しがち:tempting
へ向けてtoward
~userが:perceiveするuser-perceived
~MIME準拠::MIME-compliant
amenable:~~受容され易い
要する:sufferする／requireする
quoteされない:unquoted
configurationを~~改める:reconfigure
小数点:decimal point
直後immediately after#4
safeか否かbetween safe and unsafe
~~正しい選択〜right choice
optionalなoptionally
〜を高度に~configureし得ることhigh degree of 〜 configurability
~whitelistに入れられたwhitelisted
再~submit:resubmit
~~単独のbare
〜とも呼ばれる a.k.a
短さ:as short as
〜と違って，:unlike〜
~~直前において:just prior to
保存:…Save as ...
英語の一方言:variety of English
~~正常に~~処理されました。It worked!
同じさ度合い:sameness
	非常な:unusual
~account
~~望ましくない:unfortunate
点にある:highlight
~~前提にする:presume
元に戻す:undo
それまでの:prior
まず〜ない:unlikely
~~落と:markdown
くだけて言えば，Verballyに
	反し:contrary
大きく:highly
上手くwell
	もちろん:obvious
の他に／は別として，:aside from
広く:wideに
入る:take place
日に一度だけ:once per day
離れて他へ辿るtraverse away from
〜し続ける:remain
あろうとし続ける:tries to remain
のときのように:as in the
委ねられる:left
こともあるoccasional
その時々on occasion
~~直前:just before
~~適量:appropriate amount
変わる:vary
代えて:supplant
組は，:together
文字大小の正規化:case-normalization
講じる／踏む:take
ほとんど予期していないleast expected
見込みが高まるimprove the likelihood of
見込みが高い:likely to
言い回しlanguage
	それに伴い:correspondingly
遂げられ:carry out
~~総称されるcollectively referred to as
利用者の~~馴染み易さ:user-friendliness
賢明でない:unwise
究極の~privacy保護措置:extreme privacy measure
当の:respective
埋める:fill
一連の:successive versions
ありふれている:extremely common
~~導く:drawする
関知できない:cannot held accountable
~~特徴がある:distinguished
It knows that:わかっている
考えられ:think
いずれにせよ、:Regardless
他にもある:(among others)
	〜から:by virtue of
戻れる:link back-links
	~~広-:broad／broaden／broader
~~代理する:take the place of
何故なら:because
何故:why
内に置かれ:place
時経過:over time
臨時の販促:limited-time, promotional
向こう側で 独立に動作する者:independent actor on the other side
施す:make
下す:make
~~確定していない。:might or might not。
~~一括:batch-oriented
解することが要求される:must-understand
方向付ける:has some direction
はるかに:far more
あり得る／なり得る:potential
~~可能性がある
絞り込む:identify the scope
し易くされた:readily
	誰かが〜たいていは:people
focus:力点が置かれる所
に宛てて:target
無分別:foolish::#1
特に関心が持たれる:of particular interest
もたらす:cause
	無為にする:circumvent
指す:point to
取掛かれ:initiateでき:取り掛かれ
分かれる:split
~~過去の:earlier
戻る~link:back link
~~一過性の:transitory
待ちにある:-transit
~~増やす:degrade
場:space
考えられるsuggested
記述するもの:descriptive
による:error／err
~~正しくない:malformed
誤認を誘うもの:deceptive
消失:gone
~~記録:mark
大文字使用:capitalization
~~注意:care
持ち続け:have over
再掲:restate
閉じて:close
~~仕向ける:telling
~~伝える:tell
~~生じさせた:resulted in
~~価する:deserve
価する:worthwhile
長さ無制限:unbounded
~~強いる:prevent
~hypertext:hypertext note
現在時:current instance
~~提案:suggested
~~処理:operation
返送:back
込み入った:elaborate:~
鶏と卵:chicken-and-egg
最終的に:ultimately
馴染んでいる:familiar
過度に:overly
帰属:vesting
~~働く:act する
類する:analogous な
link-editing
代わるもの:replacement
各用紙に刷られる:added to templates
定義し直:redefine
~~不必要に:needlessly
~~不必要に:Overly


●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 7231
<a href="~SPEC_URL">Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	7231
廃用
	<a href="https://www.rfc-editor.org/rfc/rfc2616">RFC 2616</a> を廃用にする
	<a href="https://www.rfc-editor.org/rfc/rfc9110">RFC 9110</a> により廃用にされた
更新
	<a href="https://www.rfc-editor.org/rfc/rfc2817">RFC 2817</a> を更新する
分類
	Standards Track
ISSN
	2070-1721
編集
	R. Fielding, Adobe
	J. Reschke, greenbytes
日付
	2014 年 6 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc7231

</script>

</head>

<body>

<header>
	<hgroup>
<h1>HTTP/1.1 — 意味論と内容</h1>
<p>RFC 7231 — Semantics and Content</p>
	</hgroup>
</header>

<div id="MAIN" hidden>

<p class="trans-note">【
この~RFCは、
今や，`現在の~HTTP中核~仕様＠~HTTPcommon#core-specifications$（ ~RFC 9110 ）により廃用にされた。
】</p>

	<section>
◎要約

<p>
~HTTP（ Hypertext Transfer Protocol ）は、分散型の協調的な~hypertext情報~system用の，`~stateless$な~app~levelの~protocolである。
この文書は、`~HTTP11$~messageの意味論を定義する
— それは：［
`要請~method$,
`要請~header$,
`応答~状態s~code$,
`応答~header$
］により，［
~messageの~payload（~metadata, および本体~内容）, および
`内容~折衝$の仕組み
］と伴に表出される。
◎
The Hypertext Transfer Protocol (HTTP) is a stateless application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.
</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 © 2014 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="section-1">
<h2 title="Introduction">1. 序論</h2>

<div class="p">

<p>
HTTP （ Hypertext Transfer Protocol ）における各`~message$は、
`要請@
,
`応答@
のどちらかになる：
◎
Each Hypertext Transfer Protocol (HTTP) message is either a request or a response.＼
</p>
<ul>
	<li>
<p>
`~server$は：
</p>

<ol><li>接続~上にて要請を~listenして，
</li><li>受信された各~messageを構文解析して，
</li><li>識別された`要請~target$に関係する~message意味論を解釈して，
</li><li>その要請に対し 1 個~以上の応答~messageで応答する。
</li></ol>

◎
A server listens on a connection for a request, parses each message received, interprets the message semantics in relation to the identified request target, and responds to that request with one or more response messages.＼
</li>
	<li>
<p>
`~client$は：
</p>

<ol><li>特定の意図nを通信するために 要請~messageを構築して，
</li><li>受信された応答を精査して，
</li><li>その意図nが遂げられたどうか~~確認して，
</li><li>結果を解釈する方法を決定する。
</li></ol>

◎
A client constructs request messages to communicate specific intentions, examines received responses to see if the intentions were carried out, and determines how to interpret the results.＼
</li>
</ul>

<p >
この文書は、［
`~HTTP11$における要請と応答の意味論
］を，
`7230$R にて定義される~architectureの用語で定義する。
◎
This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in [RFC7230].
</p>
</div>

<p>
~HTTPは、`資源$の［
型／資質／実装
］に関わらず，資源とヤリトリするための統一的~interfaceを［
`表現$の操作, 転送
］を介して供する。
◎
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (Section 3).
</p>

<div class="p">

<p>
~HTTP意味論には、次が含まれる：
◎
HTTP semantics include＼
</p>

<ul>
	<li>
各種 `要請~method$が定義する意図n
◎
the intentions defined by each request method (Section 4),＼
</li>
	<li>
`要請~header$にて述べ得るような，それらの意味論に対する拡張
◎
extensions to those semantics that might be described in request header fields (Section 5),＼
</li>
	<li>
~machineから読取n可能な応答を指示する，`状態s~code$の意味
◎
the meaning of status codes to indicate a machine-readable response (Section 6), and＼
</li>
	<li>
`応答~header$にて与え得る，他の［
`制御~data$／資源~metadata
］の意味
◎
the meaning of other control data and resource metadata that might be given in response header fields (Section 7).
</li>
</ul>
</div>

<div class="p">

<p>
この文書は、次も定義する：
◎
This document also defines＼
</p>

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

		<section id="section-1.1">
<h3 title="Conformance and Error Handling">1.1. 適合性, ~errorの取扱い</h3>

<p>
この文書~内の~keyword "MUST" …
【以下、この段落の内容は`~IETF日本語訳 共通~page＠~IETFcommon#requirements-notation$に移譲。】
◎
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
</p>

<p>
適合性の判定基準, および
~errorの取扱いに関する考慮点は、
`7230-2.5$rfc にて定義される。
◎
Conformance criteria and considerations regarding error handling are defined in Section 2.5 of [RFC7230].
</p>

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

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

<p>
`総集的~ABNF＠~723Xabnf#abnf-7231$
にて、他の文書から取込まれた規則, および
すべての`~list演算子$を標準な~ABNF表記法に展開した，総集的な文法を示す。
◎
This specification uses the Augmented Backus-Naur Form (ABNF) notation of [RFC5234] with a list extension, defined in Section 7 of [RFC7230], that allows for compact definition of comma-separated lists using a '#' operator (similar to how the '*' operator indicates repetition). Appendix C describes rules imported from other documents. Appendix D shows the collected grammar with all list operators expanded to standard ABNF notation.
◎
This specification uses the terms "character", "character encoding scheme", "charset", and "protocol element" as they are defined in [RFC6365].
</p>

		</section>
	</section>
	<section id="section-2">
<h2 title="Resources">2. 資源</h2>

<p>
~HTTP要請の~targetは、
`資源^dfn
と呼ばれる。
~HTTPは、資源の資質を制限しない
— 単に，資源とヤリトリするときに利用できる~interfaceを定義するに過ぎない。
各~資源は、`~URI$（ `Uniform Resource Identifier^en ）により識別される。
◎
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. Each resource is identified by a Uniform Resource Identifier (URI), as described in Section 2.7 of [RFC7230].
</p>

<p>
`~client$が，`~HTTP11$要請~messageを構築するときは、［
いずれかの`形式＠~7230#p.request-target$による`~target~URI$
］を送信する。
要請を受信した`~server$は、その~URIから［
`~target資源$用の`実効~要請~URI$
］を再構築する。
◎
When a client constructs an HTTP/1.1 request message, it sends the target URI in one of various forms, as defined in (Section 5.3 of [RFC7230]). When a request is received, the server reconstructs an effective request URI for the target resource (Section 5.5 of [RFC7230]).
</p>

<p>
~HTTPの設計~目標の一つは、`資源$の識別を 要請の意味論から分離することである
— それは、要請の意味論を［
`要請~method$, および 要請を改変する少数の`要請~header$
］に帰属させることにより，アリになる。
~method意味論と`~URI$自身が含意する意味論が競合する場合、
`4.2.1$sec
【の最後の段落】
にて述べるように，~method意味論が優先される。
◎
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 4) and a few request-modifying header fields (Section 5). If there is a conflict between the method semantics and any semantic implied by the URI itself, as described in Section 4.2.1, the method semantics take precedence.
</p>

	</section>
	<section id="section-3">
<h2 title="Representations">3. 表現</h2>

<p>
`資源$はどの様なモノにもなり得ること，および
~HTTPにより供される統一的~interfaceは， “窓” のようなもの
— ［
その窓の向こう側で 独立に動作する者との，~messageの通信
］を通してのみ、そのようなモノを観測して, 動作できるような窓 —
であることを考えるとき、その通信においては，そのモノの［
現在の状態
【すなわち，応答】
や, 欲される状態
【すなわち，要請】
］を表現する（ “~~代理する” ）ための抽象-化が必要になる。
そのような抽象-化は、
`表現^dfn
と呼ばれる。
`REST$r
◎
Considering that a resource could be anything, and that the uniform interface provided by HTTP is similar to a window through which one can observe and act upon such a thing only through the communication of messages to some independent actor on the other side, an abstraction is needed to represent ("take the place of") the current or desired state of that thing in our communications. That abstraction is called a representation [REST].
</p>

<p>
~HTTPの目的における
`表現@
とは、［
所与の`資源$の［
過去の／現在の／欲される
］状態を反映する
］ように意図された，［
~protocolを介して通信するに~~適した形式による情報
］であり，［
`表現~metadata$からなる集合, および
`表現~data$の~stream（~~長さ無制限にもなり得る）
］からなる。
◎
For the purposes of HTTP, 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, and that consists of a set of representation metadata and a potentially unbounded stream of representation data.
</p>

<p>
`生成元~server$は、同じ`~target資源$に対し，［
それぞれが`資源$の現在の状態を反映するものと意図された，複数の表現
］を［
供する／生成する
］能力を備えていることもある。
そのような事例では、生成元~serverにより，［
それらの表現のうち，所与の要請に最も適用-可能なもの
］を
— 通例的に，`内容~折衝$に基づいて —
選定するような、何らかの~algoが利用される。
このようにして一つに
`選定された表現@
が、［
`条件付き要請$を評価する
］ため, および ［
`GET$m に対する［
`200$st ／ `304$st
］応答の~payloadを構築する
］ための，［
~dataと~metadata
］を供するために利用される。
◎
An origin server might be provided with, or be capable of generating, multiple representations that are each intended to reflect the current state of a target resource. In such cases, some algorithm is used by the origin server to select one of those representations as most applicable to a given request, usually based on content negotiation. This "selected representation" is used to provide the data and metadata for evaluating conditional requests [RFC7232] and constructing the payload for 200 (OK) and 304 (Not Modified) responses to GET (Section 4.3.1).
</p>

		<section id="section-3.1">
<h3 title="Representation Metadata">3.1. 表現~metadata</h3>

<p>
`表現$についての~metadataを供する~headerは、
`表現~header^dfn
と呼ばれる。
~messageが`~payload本体$を内包するとき、一連の表現~headerは，［
~payload本体~内に同封される`表現~data$
］を解釈する方法を述べる。
`HEAD$m 要請に対する応答においては、一連の表現~headerは，［
同じ要請が `GET$m であったとするときに，~payload本体~内に同封される
］ことになる表現~dataを述べる。
◎
Representation header fields provide metadata about the representation. When a message includes a payload body, the representation header fields describe how to interpret the representation data enclosed in the payload body. In a response to a HEAD request, the representation header fields describe the representation data that would have been enclosed in the payload body if the same request had been a GET.
</p>

<p>
次の~headerは、表現~metadataを伝達する：
◎
The following header fields convey representation metadata:
</p>

<div>
<ul><li>`Content-Type$h
</li><li>`Content-Encoding$h
</li><li>`Content-Language$h
</li><li>`Content-Location$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+-----------------+
   | Header Field Name | Defined in...   |
   +-------------------+-----------------+
   | Content-Type      | Section 3.1.1.5 |
   | Content-Encoding  | Section 3.1.2.2 |
   | Content-Language  | Section 3.1.3.2 |
   | Content-Location  | Section 3.1.4.2 |
   +-------------------+-----------------+
</pre>

</div>

			<section id="section-3.1.1">
<h4 title="Processing Representation Data">3.1.1. 表現~dataの処理</h4>

				<section id="section-3.1.1.1">
<h5 title="Media Type">3.1.1.1. ~MIME型</h5>

<p class="trans-note">【
この訳では、原文の
`Internet media type^en, その略称 `media type^en
を，一律に “~MIME型” と表記する（ RFC 以外の他の~web標準と一貫させるため）。
】</p>

<p>
~HTTPは、［
~openかつ拡張できる，~dataの型~付けと型~折衝
］を供するため，［
`Content-Type$h, `Accept$h
］~header内で~MIME型 `2046$R を利用する。
`~MIME型^dfn
（ `media-type$p ）は、~data形式, および
様々な処理~model
— ~dataが受信された各~文脈に則って，~dataを処理する方法 —
を定義する。
◎
HTTP uses Internet media types [RFC2046] in the Content-Type (Section 3.1.1.5) and Accept (Section 5.3.2) header fields in order to provide open and extensible data typing and type negotiation. Media types define both a data format and various processing models: how to process that data in accordance with each context in which it is received.
</p>

<pre class="bnf">
`media-type@p
	= `type$p "/" `subtype$p *( `OWS$p ";" `OWS$p `parameter$p )
`type@p
	= `token$p
`subtype@p
	= `token$p
</pre>

【！Errata 4031 Rejected 】

<p>
`type/subtype^p には、 `名前^var=`値^var ~pairの形をとる，いくつかの `parameter$p が後続してもヨイ：
◎
The type/subtype MAY be followed by parameters in the form of name=value pairs.
</p>

<pre class="bnf">
`parameter@p
	= `token$p "=" ( `token$p / `quoted-string$p )
</pre>

<p>
［
`type$p, `subtype$p, ［
`parameter$p の `名前^var を与える `token$p
］］は、いずれも文字大小無視である。
`parameter$p の `値^var が文字大小区別になるかどうかは、
`名前^var の意味論に依存する。
`parameter$p の有無は、［
~MIME型~registryにおける その定義
］に依存して， `media-type$p の処理に有意になり得る。
◎
The type, subtype, and parameter name tokens are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. The presence or absence of a parameter might be significant to the processing of a media-type, depending on its definition within the media type registry.
</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. For example, the following examples are all equivalent, but the first is preferred for consistency:
</p>

<pre class="lang-http">
text/html;charset=utf-8
text/html;charset=UTF-8
Text/HTML;Charset="utf-8"
text/html; charset="utf-8"
</pre>

<p>
~MIME型は、`BCP13$rにて定義される手続-に則って，~IANAにより登録される~OUGHT。
◎
Internet media types ought to be registered with IANA according to the procedures defined in [BCP13].
</p>

<p class="note">注記：
他の~headerにおける，一部の類似な構成子と違って、`~MIME型~parameter$では，［
文字 "`=^c" の前後の`空白$
］は許容されない（ “不良” 空白（ `BWS$p ）であっても）。
◎
Note: Unlike some similar constructs in other header fields, media type parameters do not allow whitespace (even "bad" whitespace) around the "=" character.
</p>

				</section>
				<section id="section-3.1.1.2">
<h5 title="Charset">3.1.1.2. ~charset</h5>

<p>
~HTTPでは、［
~textな表現の，文字~符号化スキーム
`6365$R
］を指示したり折衝するときに，~charset名（ `charset$p ）を利用する。
`charset$p は、文字大小無視~tokenにより識別される。
◎
HTTP uses charset names to indicate or negotiate the character encoding scheme of a textual representation [RFC6365]. A charset is identified by a case-insensitive token.
</p>

<pre class="bnf">
`charset@p
	= `token$p
</pre>

<p class="trans-note">【
`4689$errataに報告あり（ Held for Document Update: 2017-02-23 ）：
詳細は参照先に。
】</p>

<p>
~charset名は、`2978$Rにて定義される手続-に則って，~IANA
`Character Sets＠~IANA-a/character-sets$
~registryに登録される~OUGHT。
◎
Charset names ought to be registered in the IANA "Character Sets" registry (&lt;http://www.iana.org/assignments/character-sets&gt;) according to the procedures defined in [RFC2978].
</p>

				</section>
				<section id="section-3.1.1.3">
<h5 title="Canonicalization and Text Defaults">3.1.1.3. 正準-化, ~textにおける既定</h5>

<p>
~MIME型は、［
~native符号化~形式が様々な~system
］間でも相互運用-可能にするため，正準-形で登録される。
［
~MIME（ Multipurpose Internet Mail Extensions ）`2045$R
］にて述べられている多くの理由と同じ理由から、［
~HTTPを介して 選定される／転送される`表現$
］は正準-形にされる~OUGHT。
しかしながら，［
~email配達（すなわち，~messageを格納して~peerへ回送する）の処理能 特性
］は、［
~HTTPや~Web（~server~based情報~service）において共通的なそれ
］からは有意に異なる。
更には、~MIMEによる拘束は，古い~mail転送~protocolとの互換性を~~目的にしており、~HTTPには適用されない（`付録 A＠#appendix-A$を見よ）。
◎
Internet media types are registered with a canonical form in order to be interoperable among systems with varying native encoding formats. Representations selected or transferred via HTTP ought to be in canonical form, for many of the same reasons described by the Multipurpose Internet Mail Extensions (MIME) [RFC2045]. However, the performance characteristics of email deployments (i.e., store and forward messages to peers) are significantly different from those common to HTTP and the Web (server-based information services). Furthermore, MIME's constraints for the sake of compatibility with older mail transfer protocols do not apply to HTTP (see Appendix A).
</p>

<p>
~MIMEの正準-形では、［
"`text^c" ~MIME型を成すすべての下位型
］において，~text改行に `CRLF$P を利用することが要求される。
一方で，~HTTPでは、［
改行が~~単独の `CR$P ／ `LF$P で表現された，~text~media
］の転送も，［
そのような改行が`表現$ 全体で一貫である
］ときには 許容される。
~HTTP［
`送信者$／`受信者$
］は、~text~media内に［
`CRLF$P 並びや, ~~単独の `CR$P ／ `LF$P による改行
］を`生成し$てヨイ
— また，構文解析できなければナラナイ。
加えて，~HTTPにおける~text~mediaは、［
`CR$P, `LF$P に，~octet %x0D, %x0A 【！13, 10】（同順）を利用する`~charset$
］に制限されない。
この，改行に関する柔軟性は、［
`表現$の中に，~MIME型 "`text^c" としてアテガわれた~text
］のみに適用され，［
"`multipart$c" 型や, `~payload本体$の外側の~HTTP要素（例：`~header$）
］には適用されない。
◎
MIME's canonical form requires that media subtypes of the "text" type use CRLF as the text line break. HTTP allows the transfer of text media with plain CR or LF alone representing a line break, when such line breaks are consistent for an entire representation. An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. In addition, text media in HTTP is not limited to charsets that use octets 13 and 10 for CR and LF, respectively. This flexibility regarding line breaks applies only to text within a representation that has been assigned a "text" media type; it does not apply to "multipart" types or HTTP elements outside the payload body (e.g., header fields).
</p>

<p>
`表現$が`内容~符号法$により符号化される場合、下層の~dataは，符号化されるに先立って，上で定義した形にされる~OUGHT。
◎
If a representation is encoded with a content-coding, the underlying data ought to be in a form defined above prior to being encoded.
</p>

				</section>
				<section id="section-3.1.1.4">
<h5 title="Multipart Types">3.1.1.4. "`multipart^c" 型</h5>

<p>
~MIMEは、［
単独の~message本体の中に， 1 個以上の`表現$が~capsule化される
］ような，いくつかの
"`multipart^c" 型
を供する。
すべての "`multipart^c" 型は、`2046-5.1.1$rfcにて定義される 共通な構文を共有し，`~MIME型$ 値の一部として 境界~parameterを内包する。
~message本体~自身は、~protocol要素である
— `送信者$は、本体の各 部分~間の改行を表現するときは， `CRLF$P のみを`生成し$なければナラナイ。
◎
MIME provides for a number of "multipart" types -- encapsulations of one or more representations within a single message body. All multipart types share a common syntax, as defined in Section 5.1.1 of [RFC2046], and include a boundary parameter as part of the media type value. The message body is itself a protocol element; a sender MUST generate only CRLF to represent line breaks between body parts.
</p>

<p>
~HTTP~message~frame法においては、 "`multipart^c" 境界が `~message本体~長さ$の指示子に利用されることはない
— ~payloadを生成する／処理する実装により，利用されることはあっても。
例えば， "`multipart/form-data^c" 型は、`2388$Rに述べられるように，要請~内に~form~dataを運ばせるために よく利用される。
また， "`multipart/byteranges$c" 型は、一部の `206$st 応答に利用するためとして，この仕様で定義される。
◎
HTTP message framing does not use the multipart boundary as an indicator of message body length, though it might be used by implementations that generate or process the payload. For example, the "multipart/form-data" type is often used for carrying form data in a request, as described in [RFC2388], and the "multipart/ byteranges" type is defined by this specification for use in some 206 (Partial Content) responses [RFC7233].
</p>

				</section>
				<section id="section-3.1.1.5">
<h5>3.1.1.5. `Content-Type^h</h5>

<p>
`Content-Type^h ~headerは、
結付けられた`表現$
— ~message意味論に従って決定された，［
~message~payload内に同封された表現, または
`選定された表現$
］ —
の`~MIME型$を指示する。
指示された~MIME型は、［
`Content-Encoding$h により指示される`内容~符号法$（たち）が復号された後
］の［
~data形式, および［
受信者は、その~dataをどう処理するものと意図されているか
］］を，受信された~message意味論の視野の中で定義する。
◎
The "Content-Type" header field indicates the media type of the associated representation: either the representation enclosed in the message payload or the selected representation, as determined by the message semantics. The indicated media type defines both the data format and how that data is intended to be processed by a recipient, within the scope of the received message semantics, after any content codings indicated by Content-Encoding are decoded.
</p>

<pre class="bnf">
`Content-Type@p
	= `media-type$p
</pre>

<div class="example">
<p>
【！~MIME型は 3.1.1.1 にて定義される。】
~headerの例：
◎
Media types are defined in Section 3.1.1.1. An example of the field is
</p>

<pre class="lang-http">
Content-Type: text/html; charset=ISO-8859-4
</pre>
</div>

<p>
［
`~payload本体$を包含している~message
］を`生成する$`送信者$は、［
自身が，同封された`表現$に意図された`~MIME型$について未知でない
］限り、その~message内に `Content-Type^h ~headerを`生成する$ベキである。
`Content-Type^h ~headerが無い場合、`受信者$は，その~MIME型を［
"`application/octet-stream^c" （`2046-4.5.1$rfc）である
］ものと見做すか, または
その~dataを精査して決定してもヨイ。
◎
A sender that generates a message containing a payload body SHOULD generate a Content-Type header field in that message unless the intended media type of the enclosed representation is unknown to the sender. If a Content-Type header field is not present, the recipient MAY either assume a media type of "application/octet-stream" ([RFC2046], Section 4.5.1) or examine the data to determine its type.
</p>

<p>
実施においては、`資源$の所有者は，［
`生成元~server$が［
所与の`表現$用に正しい `Content-Type^h を供する
］ように，常に適正に環境設定されている
］とは限らないため、~clientには，［
~payloadの内容を精査して，指定された型を上書きする
］ものもある【例： `MIME sniffing^en 】。
そのようにする~clientは、不正な結論を~~導く~riskを負い，追加的な~security~riskを公開し得る（例： “特権拡大” ）。
更には、送信者の意図を ~data形式を精査して決定するのは，不可能である：
多くの~data形式は、処理の意味論においてのみ相違するような，複数の`~MIME型$に合致する。
実装者には、そのような “内容~sniff法” を利用するときは，それを不能化する手段を供することが奨励される。
◎
In practice, resource owners do not always properly configure their origin server to provide the correct Content-Type for a given representation, with the result that some clients will examine a payload's content and override the specified type. Clients that do so risk drawing incorrect conclusions, which might expose additional security risks (e.g., "privilege escalation"). Furthermore, it is impossible to determine the sender's intent by examining the data format: many data formats match multiple media types that differ only in processing semantics. Implementers are encouraged to provide a means of disabling such "content sniffing" when it is used.
</p>

				</section>
			</section>
			<section id="section-3.1.2">
<h4 title="Encoding for Compression or Integrity">3.1.2. 圧縮／完全性のための符号化法</h4>

				<section id="section-3.1.2.1">
<h5 title="Content Codings">3.1.2.1. 内容~符号法</h5>

<p>
内容~符号法の値（ `content-coding$p ）は、［
`表現$に適用された／適用できる，符号化法による形式変換
］を指示する。
内容~符号法は，首に、［
表現の下層の`~MIME型$の，同一性, および情報
］を損なうことなく，表現を 圧縮したり, 有用に形式変換できるようにするために利用される。
表現が，［
符号化形で格納され, 直に伝送され，最終~受信者によってのみ復号される
］ことは、頻繁にある。
◎
Content coding values indicate an encoding transformation that has been or can be applied to a representation. Content codings are primarily used to allow a representation to be compressed or otherwise usefully transformed without losing the identity of its underlying media type and without loss of information. Frequently, the representation is stored in coded form, transmitted directly, and only decoded by the final recipient.
</p>

<pre class="bnf">
`content-coding@p
	= `token$p
</pre>

<p>
すべての `content-coding$p 値は、文字大小無視であり，
`8.4$secにて定義されるように
"HTTP Content Coding Registry"
に登録される~OUGHT。
それらは、
`Accept-Encoding$h や `Content-Encoding$h
~headerにて利用される。
◎
All content-coding values are case-insensitive and ought to be registered within the "HTTP Content Coding Registry", as defined in Section 8.4. They are used in the Accept-Encoding (Section 5.3.4) and Content-Encoding (Section 3.1.2.2) header fields.
</p>

<p>
この仕様では、次の内容~符号法 値が定義される：
◎
The following content-coding values are defined by this specification:
</p>

<ul>
	<li>
`compress$c（ `x-compress^c も同じ）
◎
compress (and x-compress): See Section 4.2.1 of [RFC7230].
</li>
	<li>
`deflate$c
◎
deflate: See Section 4.2.2 of [RFC7230].
</li>
	<li>
`gzip$c（ `x-gzip^c も同じ）
◎
gzip (and x-gzip): See Section 4.2.3 of [RFC7230].
</li>
</ul>

				</section>
				<section id="section-3.1.2.2">
<h5>3.1.2.2. `Content-Encoding^h</h5>

<p>
`Content-Encoding^h ~headerは、［
当該の`~MIME型$に内来的なものを超えて，`表現$に適用された`内容~符号法$
］を指示し、従って，［［［
`Content-Type$h ~headerにより参照されている~MIME型
］による~data
］を得するために 適用する必要がある，復号の仕組み
］を指示する。
`Content-Encoding^h は、首に，［
その下層の~MIME型の同一性を損なうことなく，表現の~dataを圧縮できる
］ようにするために利用される。
◎
The "Content-Encoding" header field indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type.
</p>

<pre class="bnf">
`Content-Encoding@p
	= 1#`content-coding$p
</pre>

<div class="example">
<p>
その利用~例：
◎
An example of its use is
</p>

<pre class="lang-http">
Content-Encoding: gzip
</pre>
</div>

<p>
`送信者$は、［
`表現$に一つ以上の符号化法を適用する
］ときには，［
各 `内容~符号法$を適用した順序で~listする，
`Content-Encoding^h ~header
］を`生成し$なければナラナイ。
［
符号化法の各種~parameterについての追加的な情報
］も［
この仕様では定義されない他の~header
］により供され得る。
◎
If one or more encodings have been applied to a representation, the sender that applied the encodings MUST generate a Content-Encoding header field that lists the content codings in the order in which they were applied. Additional information about the encoding parameters can be provided by other header fields not defined by this specification.
</p>

<p>
`Transfer-Encoding$h と違って，［
`Content-Encoding^h 内に~listされた符号法
］は、`表現$の特性である
— 表現は、符号化形の用語を通して定義される。
また，表現に関する他のすべての~metadataは、その~metadata定義にて注記されない限り，符号化形に関するものである。
表現が復号されるのは、概して，それを具現化する, またはそれに類する利用eの~~直前に限られる。
◎
Unlike Transfer-Encoding (Section 3.3.1 of [RFC7230]), the codings listed in Content-Encoding are a characteristic of the representation; the representation is defined in terms of the coded form, and all other metadata about the representation is about the coded form unless otherwise noted in the metadata definition. Typically, the representation is only decoded just prior to rendering or analogous usage.
</p>

<p>
［
常に圧縮されるような~data形式などの，`~MIME型$が含む内来的な符号化法
］は、それが［
いずれかの`内容~符号法$と たまたま同じ~algoである
］としても、
`Content-Encoding^h 内には再掲されない。
そのような内容~符号法が~listされるのは、`表現$を形成するときに，何らかの奇妙な理由から 二重に適用された場合に限られることになる。
同様に，`生成元~server$は、［
同じ~dataを［［
符号法が［
`Content-Type$h や `Content-Encoding^h
］の一部として定義されるかどうか
］においてのみ相違するような，複数の表現
］として公表する
］ことも，選択し得る
— 一部の~UAは、応答ごとに取扱いを違えるように挙動するので（例： 内容を自動的に解凍して具現化する代わりに， “保存…” ~dialogを開く）。
◎
If the media type includes an inherent encoding, such as a data format that is always compressed, then that encoding would not be restated in Content-Encoding even if it happens to be the same algorithm as one of the content codings. Such a content coding would only be listed if, for some bizarre reason, it is applied a second time to form the representation. Likewise, an origin server might choose to publish the same data as multiple representations that differ only in whether the coding is defined as part of Content-Type or Content-Encoding, since some user agents will behave differently in their handling of each response (e.g., open a "Save as ..." dialog instead of automatic decompression and rendering of content).
</p>

<p>
`生成元~server$は、［
要請~message内の`表現$が，受容-可能でない`内容~符号法$を持つ
］ときには， `415$st で応答してもヨイ。
◎
An origin server MAY respond with a status code of 415 (Unsupported Media Type) if a representation in the request message has a content coding that is not acceptable.
</p>

				</section>
			</section>
			<section id="section-3.1.3">
<h4 title="Audience Language">3.1.3. 視聴者~言語</h4>

				<section id="section-3.1.3.1">
<h5 title="Language Tags">3.1.3.1. 言語~tag</h5>

<p>
`言語~tag^dfn
は、 `5646$Rにて定義されるように，
他者と情報をやりとりするために，ヒトにより［
話され, 書かれ, あるいは伝達される
］自然言語を識別する。
~computer言語は，明示的に除外される。
◎
A language tag, as defined in [RFC5646], identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information to other human beings. Computer languages are explicitly excluded.
</p>

<p>
~HTTPでは、言語~tagを［
`Accept-Language$h ／ `Content-Language$h
］~headerの中で利用する。
`Accept-Language$h は，［
`5.3.5$secにて定義される，より~~広い `language-range$p 生成規則
］を利用する一方、
`Content-Language$h は，［
下に定義される `language-tag$p 生成規則
］を利用する：
◎
HTTP uses language tags within the Accept-Language and Content-Language header fields. Accept-Language uses the broader language-range production defined in Section 5.3.5, whereas Content-Language uses the language-tag production defined below.
</p>

<pre class="bnf">
`language-tag@p
	= &lt;Language-Tag, `5646-2.1$rfc&gt;
</pre>

<div class="p">
<p>
言語~tagは、文字~hyphen（ "`-^c", %x2D ）で互いに分離された， 1 個~以上の~subtag（文字大小無視）からなる並びである。
ほとんどの事例では、言語~tagは 次の並びからなる：
◎
A language tag is a sequence of one or more case-insensitive subtags, each separated by a hyphen character ("-", %x2D). In most cases, a language tag consists of＼
</p>

<ol>
	<li>
関係する言語の~~広い族を識別する，首な言語~subtag（例： "`en^c" ＝ 英語）
◎
a primary language subtag that identifies a broad family of related languages (e.g., "en" = English), which is＼
</li>
	<li>
その言語の範囲を 精緻化する／狭める，一連の~subtag（省略可能）
（例： "`en-CA^c" は、~Canadaで会話される英語の一方言）
◎
optionally followed by a series of subtags that refine or narrow that language's range (e.g., "en-CA" = the variety of English as communicated in Canada).＼
</li>
</ol>

<p>
言語~tagの中では、`空白$は許容されない。
◎
Whitespace is not allowed within a language tag.＼
</p>
</div>

<div class="example">
<p>
~tagの例：
◎
Example tags include:
</p>

<pre class="lang-http">
fr, en-US, es-419, az-Arab, x-pig-latin, man-Nkoo-GN
</pre>
</div>

<p>
更なる情報は、`5646$Rを見よ。
◎
See [RFC5646] for further information.
</p>

				</section>
				<section id="section-3.1.3.2">
<h5>3.1.3.2. `Content-Language^h</h5>

<p>
`Content-Language^h ~headerは、`表現$用に意図される視聴者の自然言語（たち）を述べる。
これは、［
表現の中で利用される どの言語にも等価にならない
］場合もあることに注意。
◎
The "Content-Language" header field describes the natural language(s) of the intended audience for the representation. Note that this might not be equivalent to all the languages used within the representation.
</p>

<pre class="bnf">
`Content-Language@p
	= 1#`language-tag$p
</pre>

<p>
【！言語~tagは、3.1.3.1にて定義される。】
`Content-Language^h の首な目的は、利用者が，自身が選好する言語に則って，表現を識別したり相違化できるようにすることである。
◎
Language tags are defined in Section 3.1.3.1. The primary purpose of Content-Language is to allow a user to identify and differentiate representations according to the users' own preferred language.＼
</p>

<div class="example">
<p>
したがって、~Danish話者~向けのみを意図した内容に適切になる~headerは：
◎
Thus, if the content is intended only for a Danish-literate audience, the appropriate field is
</p>

<pre class="lang-http">
Content-Language: da
</pre>
</div>

<p>
`Content-Language^h が指定されていない場合、［
内容は，すべての言語の視聴者~向けを意図する
］ことが，既定になる。
これは、送信者が［
内容は どの自然言語にも特有でないと見なしているか，内容に意図された言語を知らない
］ことを意味するであろう。
◎
If no Content-Language is specified, the default is that the content is intended for all language audiences. This might mean that the sender does not consider it to be specific to any natural language, or that the sender does not know for which language it is intended.
</p>

<p>
［
複数の言語の視聴者~向けに意図される内容
］用に、複数の言語が~listされてヨイ。
◎
Multiple languages MAY be listed for content that is intended for multiple audiences.＼
</p>

<div class="example">
<p>
例えば，
“ワイタンギ条約”
を，元の~Maoriと英語~versionで同時に呈示させたければ、次を用いることになるだろう：
◎
For example, a rendition of the "Treaty of Waitangi", presented simultaneously in the original Maori and English versions, would call for
</p>

<pre class="lang-http">
Content-Language: mi, en
</pre>
</div>

<p>
しかしながら、単に表現の中に 複数の言語が在るだけで，複数種の言語~話者~向けが意図されたことにはならない。
例えば、 “A First Lesson in Latin” のような，英語~話者~向けが明瞭な 初学者~向けの言語~入門書であれば、 `Content-Language^h は "`en^c" のみを内包する方が適正になるであろう。
◎
However, just because multiple languages are present within a representation does not mean that it is intended for multiple linguistic audiences. An example would be a beginner's language primer, such as "A First Lesson in Latin", which is clearly intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en".
</p>

<p>
`Content-Language^h は、どの`~MIME型$に適用されてもヨイ
— ~textな文書のみに制限されない。
◎
Content-Language MAY be applied to any media type -- it is not limited to textual documents.
</p>

				</section>
			</section>
			<section id="section-3.1.4">
<h4 title="Identification">3.1.4. 識別</h4>

				<section id="section-3.1.4.1">
<h5 title="Identifying a Representation">3.1.4.1. 表現の識別-法</h5>

<p>
~message~payload内に［
完全な, または部分的な`表現$
］が転送されるときに、［
その表現に対応する`資源$用の識別子
］を［
送信者が給する, または受信者が決定する
］ことが望ましいことはよくある。
◎
When a complete or partial representation is transferred in a message payload, it is often desirable for the sender to supply, or the recipient to determine, an identifier for a resource corresponding to that representation.
</p>

<p>
要請~messageに対しては：
◎
For a request message:
</p>

<dl class="switch">
	<dt>要請が `Content-Location$h ~headerを持つ場合：</dt>
	<dd>
`送信者$は，［
その~payloadが［
`Content-Location$h `~header値$により識別される`資源$
］の`表現$である
］ことを表明している。
しかしながら，そのような表明は、他の手段（この仕様では定義されない）により検証yされない限り，信用できない。
情報は、改訂~履歴~link用には，依然として有用になり得る。
◎
If the request has a Content-Location header field, then the sender asserts that the payload 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.
</dd>

	<dt>他の場合：</dt>
	<dd>
~payloadは識別されない。
◎
Otherwise, the payload is unidentified.
</dd>
</dl>

<p>
応答~messageに対しては、次の規則のうち，最初に合致するものが適用される：
◎
For a response message, the following rules are applied in order until a match is found:
</p>

<dl class="switch">
	<dt>
`要請~method$が［
`GET$m または `HEAD$m
］である場合：
</dt>
	<dd>
<p>
応答~状態s~codeに応じて：
</p>
		<dl class="switch">
			<dt>`200$st</dt>
			<dt>`204$st</dt>
			<dt>`206$st</dt>
			<dt>`304$st</dt>
			<dd>
~payloadは、［
`実効~要請~URI$により識別される`資源$
］の`表現$である。
◎
1. If the request method is GET or HEAD and the response status code is 200 (OK), 204 (No Content), 206 (Partial Content), or 304 (Not Modified), the payload is a representation of the resource identified by the effective request URI (Section 5.5 of [RFC7230]).
</dd>
			<dt>`203$st</dt>
			<dd>
~payloadは、［
`媒介者$により改変されたか増強されて
］供された~~可能性もある，`~target資源$の`表現$である。
◎
2. If the request method is GET or HEAD and the response status code is 203 (Non-Authoritative Information), the payload is a potentially modified or enhanced representation of the target resource as provided by an intermediary.
</dd>
			<dt>その他</dt>
			<dd>
後続の規則への合致-を試みる。
</dd>
		</dl>
	</dd>

	<dt>応答に `Content-Location$h ~headerがある場合：</dt>
	<dd>
<p>
その`~header値$が，`実効~要請~URI$と：
</p>
		<dl class="switch">
			<dt>同じ~URIへの参照である場合：</dt>
			<dd>
~payloadは、［
`実効~要請~URI$により，識別される`資源$
］の`表現$である。
◎
3. If the response has a Content-Location header field and its field-value is a reference to the same URI as the effective request URI, the payload is a representation of the resource identified by the effective request URI.
</dd>

			<dt>異なる~URIへの参照である場合：</dt>
			<dd>
`送信者$は、［
~payloadが，その`~header値$により識別される資源の`表現$である
］ことを表明している。
しかしながら，そのような表明は、他の手段（この仕様では定義されない）により検証yされない限り，信用できない。
◎
4. If the response has a Content-Location header field and its field-value is a reference to a URI different from the effective request URI, then the sender asserts that the payload 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).
</dd>
<!-- 
			<dt>【他の場合（すなわち、~header値が妥当な~URI参照でない）】</dt>
			<dd class="trans-note">【
この場合、下の “他の場合” に従うか、または，構文~errorの取扱い（`7230-2.5$rfc の最後の段落）に従う（実装に依存する）と考えられる。
】</dd>
 -->
		</dl>
	</dd>

	<dt>他の場合：</dt>
	<dd>
~payloadは、識別されない。
◎
5. Otherwise, the payload is unidentified.
</dd>
</dl>

				</section>
				<section id="section-3.1.4.2">
<h5>3.1.4.2. `Content-Location^h</h5>

<p>
`Content-Location^h ~headerは、［
この~messageの~payload内の`表現$に対応する，特定の`資源$
］用の識別子として利用できる`~URI$を参照する。
言い換えれば、この~messageの生成-時に，［
どこかから この~URIに向けて `GET$m 要請が遂行された
］ならば、それに対する `200$st 応答は，［
この~message内の~payloadに同封されるものと同じ表現
］を包含することになるであろう。
◎
The "Content-Location" header field references a URI that can be used as an identifier for a specific resource corresponding to the representation in this message's payload. In other words, if one were to perform a GET request on this URI at the time of this message's generation, then a 200 (OK) response would contain the same representation that is enclosed as payload in this message.
</p>

<pre class="bnf">
`Content-Location@p
	= `absolute-URI$p
	/ `partial-URI$p
</pre>

<p>
`Content-Location^h 値は、`実効~要請~URI$に代わるものではない。
それは、`表現~metadata$である。
その構文と意味論は、［
~MIME本体 部分~用に定義される同じ名前の~header `2557-4$rfc
］と同じである。
しかしながら，~HTTP~messageにおける
`Content-Location^h の出現は、~HTTP受信者にとっては，ある特別な含意がある
—
◎
The Content-Location value is not a replacement for the effective Request URI (Section 5.5 of [RFC7230]). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME body parts in Section 4 of [RFC2557]. However, its appearance in an HTTP message has some special implications for HTTP recipients.
</p>

<p>
それが， `2xx$st 応答~message内に内包されているならば、その`~header値$（を `absolute-form$p へ変換した†後の値）が：
◎
If Content-Location is included in a 2xx (Successful) response message and its value refers (after conversion to absolute form)＼
</p>

<p class="trans-note">【†
具体的にどう変換するのか記されていないが、実効~要請~URIの再構築（`7230-5.5$rfc）と同様に？
】</p>

<dl class="switch">
	<dt>
`実効~要請~URI$と同じ~URIを指す場合：
◎
to a URI that is the same as the effective request URI, then＼
</dt>
	<dd>
<p>
`受信者$は、その~payloadを［
`~messageの出生日時$で指示される時点における，その`資源$の現在の`表現$
］と見なしてもヨイ：
◎
the recipient MAY consider the payload to be a current representation of that resource at the time indicated by the message origination date.＼
</p>

		<ul>
			<li>
`GET$m ／ `HEAD$m 要請に対しては、これは，［
`~server$により `Content-Location^h が供されなかったとき
］の既定の意味論と同じである。
◎
For a GET (Section 4.3.1) or HEAD (Section 4.3.2) request, this is the same as the default semantics when no Content-Location is provided by the server.＼
</li>
			<li>
`PUT$m や `POST$m などの状態変更 要請に対しては、これは，［
`~server$の応答が，その`資源$の新たな`表現$を包含する
］ことを含意する
— したがって［
動作についてのみを報告し得るような`表現$（例： “~~正常に~~処理されました。” ）
］との違いを判別できる。
これにより、著作~用の~appは、後続な `GET$m 要請を要することなく，その局所的な複製を更新できるようになる。
◎
For a state-changing request like PUT (Section 4.3.4) or POST (Section 4.3.3), it implies that the server's response contains the new representation of that resource, thereby distinguishing it from representations that might only report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the need for a subsequent GET request.
</li>
		</ul>
	</dd>

	<dt>
`実効~要請~URI$と相違する`~URI$を指す場合：
◎
If Content-Location is included in a 2xx (Successful) response message and its field-value refers to a URI that differs from the effective request URI, then＼
</dt>
	<dd>
<p>
`生成元~server$は、［
その~URIが，同封された`表現$に対応する異なる`資源$用の識別子である
］ことを主張している。
そのような主張-を信用できるのは、［
両~識別子が同じ資源~所有者を共有する
］ときに限られる
— それは、~HTTPを介しては~programmaticに決定できない：
◎
the origin server claims that the URI is an identifier for a different resource corresponding to the enclosed representation. Such a claim can only be trusted if both identifiers share the same resource owner, which cannot be programmatically determined via HTTP.
</p>

<p>
（以下、 `Content-Location^h ~header値を単に `~header値^var と記す。）
</p>
		<ul>
			<li>
<p>
［
`GET$m ／ `HEAD$m
］要請に対する応答に対しては、これは，次の 2 つを指示する：
</p>
				<ul>
					<li>
`実効~要請~URI$は、`内容~折衝$の~subjectである`資源$を指している。
</li>
					<li>
`~header値^var は、`選定された表現$用の，より特定な識別子である。
</li>
				</ul>

◎
• For a response to a GET or HEAD request, this is an indication that the effective request URI refers to a resource that is subject to content negotiation and the Content-Location field-value is a more specific identifier for the selected representation.
</li>
			<li>
状態変更~methodに対する `201$st 応答に対しては、［
`Location$h ~header値と一致する `~header値^var
］は，［
この【応答の】~payloadは，新たに作成された`資源$の現在の`表現$である
］ことを指示する。
◎
• For a 201 (Created) response to a state-changing method, a Content-Location field-value that is identical to the Location field-value indicates that this payload is a current representation of the newly created resource.
</li>
			<li>
<p>
他の場合【他の応答に対しては？】、そのような `Content-Location^h は，次の 2 つを指示する：
◎
• Otherwise, such a Content-Location indicates that＼
</p>

				<ul>
					<li>
この【応答の】~payloadは、要請された動作の状態sを報告している`表現$である。
◎
this payload is a representation reporting on the requested action's status and that＼
</li>
					<li>
同じ報告が、 `~header値^var に与えられた`~URI$においても（ `GET$m による未来の~access用に）可用である。
◎
the same report is available (for future access with GET) at the given URI.＼
</li>
				</ul>
<p>
例えば，［
`POST$m 要請を介して為された購入~transaction
］は、［
`200$st 応答の~payload
］として，領収書を内包することもある
— このときの `~header値^var は、未来に 同じ領収書の複製を検索取得するための識別子を供する。
◎
For example, a purchase transaction made via a POST request might include a receipt document as the payload of the 200 (OK) response; the Content-Location field-value provides an identifier for retrieving a copy of that same receipt in the future.
</p>
			</li>
		</ul>
	</dd>
</dl>

<p>
`Content-Location^h を要請~message内に送信する`~UA$は、その値が［
~UAが（その~UAにより~~行われた改変に先立って，）同封された`表現$の内容を~~元々得した所
］を指していることを言明している。
言い換えれば、~UAは，［
元の表現の~sourceへ戻る~link
］を供している。
◎
A user agent that sends Content-Location in a request message is stating that its value refers to where the user agent originally obtained the content of the enclosed representation (prior to any modifications made by that user agent). In other words, the user agent is providing a back link to the source of the original representation.
</p>

<div class="p">
<p>
要請~message内に `Content-Location^h ~headerを受信した`生成元~server$は：
◎
An origin server that receives a Content-Location field in a request message＼
</p>

<ul>
	<li>
その情報を，~~一過性の要請~文脈として扱わなければナラナイ
— `表現$の一部として逐語的に保存されることになる~metadataとしてではなく。
◎
MUST treat the information as transitory request context rather than as metadata to be saved verbatim as part of the representation.＼
</li>
	<li>
その文脈を，要請の処理を手引きするために利用したり, 他の利用のために保存してもヨイ
— ~source~linkや~version付け~metadataの中など。
◎
An origin server MAY use that context to guide in processing the request or to save it for other uses, such as within source links or versioning metadata.＼
</li>
	<li>
しかしながら、そのような文脈~情報を，その要請の意味論を改めるために利用してはナラナイ。
◎
However, an origin server MUST NOT use such context information to alter the request semantics.
</li>
</ul>
</div>

<p>
例えば、~clientが，折衝された`資源$に対し `PUT$m 要請を為して、生成元~serverが，その `PUT$m を（~redirectionなしに）受容した場合、その資源の新たな状態は，その `PUT$m に給された一つの`表現$と整合するものと期待される。
`Content-Location^h は、［
折衝された表現のうち一つだけを更新する
］ための
“逆-内容~選定~識別子”
の形としては，利用できない
— ~UAがそのような意味論を求めていたなら、
`Content-Location^h の~URIに，直に `PUT$m を適用したであろう。
◎
For example, if a client makes a PUT request on a negotiated resource and the origin server accepts that PUT (without redirection), then the new state of that resource is expected to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse content selection identifier to update only one of the negotiated representations. If the user agent had wanted the latter semantics, it would have applied the PUT directly to the Content-Location URI.
</p>

				</section>
			</section>
		</section>
		<section id="section-3.2">
<h3 title="Representation Data">3.2. 表現~data</h3>

<p>
~HTTP~messageに結付けられる`表現$の~dataは、［
~messageの`~payload本体$として供される
］か, または［
~message意味論と`実効~要請~URI$から指される
］か，のいずれかになる。
表現~dataの［
形式と符号化法
］は、`表現~metadata$~headerにより定義される。
◎
The representation data associated with an HTTP message is either provided as the payload body of the message or referred to by the message semantics and the effective request URI. The representation data is in a format and encoding defined by the representation metadata header fields.
</p>

<p>
表現~dataの~data型は、［
`Content-Type$h, および `Content-Encoding$h 
］~headerを介して決定される。
これらは［
2 層の, 順序付けられた符号化~model
］を定義する：
◎
The data type of the representation data is determined via the header fields Content-Type and Content-Encoding. These define a two-layer, ordered encoding model:
</p>

<blockquote>
表現~data := `Content-Encoding^var ( `Content-Type^var ( ビット列 ) )
◎
representation-data := Content-Encoding( Content-Type( bits ) )
</blockquote>

		</section>
		<section id="section-3.3">
<h3 title="Payload Semantics">3.3. ~payloadの意味論</h3>

<p>
~HTTP~messageには、`表現$の全部または一部を，~message~payloadとして転送するものもある。
一部の事例では、~payloadは，［
結付けられた表現の~headerのみ（例： `HEAD$m に対する応答）
］を, あるいは［
`表現~data$の いくつかの部分のみ（例： 状態s~code `206$st ）
］を包含することもある。
◎
Some HTTP messages transfer a complete or partial representation as the message "payload". In some cases, a payload might contain only the associated representation's header fields (e.g., responses to HEAD) or only some part(s) of the representation data (e.g., the 206 (Partial Content) status code).
</p>

<div class="p">
<p>
要請における~payloadの目的は、~method意味論により定義される。
例えば：
◎
The purpose of a payload in a request is defined by the method semantics. For example,＼
</p>

<ul>
	<li>
`PUT$m 要請の~payload内の`表現$は、［
要請が成功裡に適用されたときに，`~target資源$に欲される状態
］を表現する一方で、
◎
a representation in the payload of a PUT request (Section 4.3.4) represents the desired state of the target resource if the request is successfully applied, whereas＼
</li>
	<li>
`POST$m 要請の~payload内の`表現$は、［
`~target資源$により処理されることになる情報
］を表現する。
◎
a representation in the payload of a POST request (Section 4.3.3) represents information to be processed by the target resource.
</li>
</ul>
</div>

<div class="p">

<p>
応答における~payloadの目的は、［
`要請~method$と`応答~状態s~code$
］の両者により定義される。
例えば：
◎
In a response, the payload's purpose is defined by both the request method and the response status code. For example,＼
</p>

<ul>
	<li>
`GET$m に対する `200$st 応答の~payloadは、［
`~messageの出生日時$の時点にて観測される，`~target資源$の現在の状態
］を表現する一方で、
◎
the payload of a 200 (OK) response to GET (Section 4.3.1) represents the current state of the target resource, as observed at the time of the message origination date (Section 7.1.1.2), whereas＼
</li>
	<li>
`POST$m に対する，同じ `200$st 応答の~payloadは、［
処理の結果
］を, あるいは［
処理を適用した後の，`~target資源$の新たな状態
］を表現することもある。
◎
the payload 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>
	<li>
~error状態s~codeを伴う応答~messageが包含する~payloadは、通例的に，［
その~error状態, および
その解決に示唆される次に行う手続き
］について述べるような，~error条件を表現する。
◎
Response messages with an error status code usually contain a payload that represents the error condition, such that it describes the error state and what next steps are suggested for resolving it.
</li>
</ul>
</div>

<p>
結付けられた`表現$ではなく，~payloadについて特に述べる~headerを指して、
`~payload~header@
という。
それらは，~messageの構文解析に影響iするので、この仕様の他所にて定義される：
◎
Header fields that specifically describe the payload, rather than the associated representation, are referred to as "payload header fields". Payload header fields are defined in other parts of this specification, due to their impact on message parsing.
</p>

<div>
<ul><li>`Content-Length$h
</li><li>`Content-Range$h
</li><li>`Trailer$h
</li><li>`Transfer-Encoding$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+----------------------------+
   | Header Field Name | Defined in...              |
   +-------------------+----------------------------+
   | Content-Length    | Section 3.3.2 of [RFC7230] |
   | Content-Range     | Section 4.2 of [RFC7233]   |
   | Trailer           | Section 4.4 of [RFC7230]   |
   | Transfer-Encoding | Section 3.3.1 of [RFC7230] |
   +-------------------+----------------------------+
</pre>

</div>

		</section>
		<section id="section-3.4">
<h3 title="Content Negotiation">3.4. 内容の折衝</h3>

<p>
`生成元~server$は、応答にて伝達する~payload情報を表現するときに
— その情報が成功か~errorのいずれを指示するにしても —
いくつか異なる仕方を備えていることが多い
— 例えば，異なる［
形式／言語／符号化法
］で。
また，利用者／~UA ごとに［
能力, 特性, 選好
］も異なり得るので、［
可用な`表現$のうち，どれを送達するのが最良になるか
］も変わり得る。
この理由から、~HTTPは，内容~折衝~用の仕組みをいくつか供する。
◎
When responses convey payload information, whether indicating a success or an error, the origin server often has different ways of representing that information; for example, in different formats, languages, or encodings. Likewise, different users or user agents might have differing capabilities, characteristics, or preferences that could influence which representation, among those available, would be best to deliver. For this reason, HTTP provides mechanisms for content negotiation.
</p>

<div class="p">

<p>
この仕様は、~protocolの中で可視にされ得るような，次の 2 種の~patternによる
`内容~折衝^dfn
を定義する：
◎
This specification defines two patterns of content negotiation that can be made visible within the protocol:＼
</p>

<ul>
	<li>
`~proactive折衝$
⇒
`~server$が、~UAが言明した選好に基づいて，`表現$を選定する。
◎
"proactive", where the server selects the representation based upon the user agent's stated preferences, and＼
</li>
	<li>
`~reactive折衝$
⇒
`~server$が、~UA向けに，選択-対象となる`表現$の~listを供する。
◎
"reactive" negotiation, where the server provides a list of representations for the user agent to choose from.＼
</li>
</ul>

<p>
他の~patternによる内容~折衝には、次のものが含まれる：
◎
Other patterns of content negotiation include＼
</p>

<ul>
	<li>
条件付き内容
⇒
`表現$は複数の部分からなっていて、各~部分は、~UAの各種~parameterに基づいて，選択的に具現化される。
◎
"conditional content", where the representation consists of multiple parts that are selectively rendered based on user agent parameters,＼
</li>
	<li>
作動中な内容
⇒
`表現$は~scriptを包含していて、それが、~UAの特性に基づいて，追加的な（より特定な）要請を為す。
◎
"active content", where the representation contains a script that makes additional (more specific) requests based on the user agent characteristics, and＼
</li>
	<li>
透過的な内容~折衝（ `Transparent Content Negotiation^en `2295$R ）
⇒
`媒介者$が、内容の選定を遂行する。
◎
"Transparent Content Negotiation" ([RFC2295]), where content selection is performed by an intermediary.＼
</li>
</ul>

<p>
これらの~patternは、排他的ではない
— それぞれ、適用能と実用性の引換関係にある。
◎
These patterns are not mutually exclusive, and each has trade-offs in applicability and practicality.
</p>

</div>

<p>
すべての事例において、~HTTPは，`資源$の意味論を自覚しないことに注意。
［
要請に対し応答する生成元~serverの［
時間~越し／`内容~折衝$の種々の次元
］にわたる一貫性、したがって［
時間~越し資源に観測される，`表現$の “同じさ度合い”
］は、全面的に，［
それらの応答を選定したり, 生成する，実体／~algo
］により決定される。
~HTTPは、舞台裏には注意を向けない。
◎
Note that, in all cases, HTTP is not aware of the resource semantics. The consistency with which an origin server responds to requests, over time and over the varying dimensions of content negotiation, and thus the "sameness" of a resource's observed representations over time, is determined entirely by whatever entity or algorithm selects or generates those responses. HTTP pays no attention to the man behind the curtain.
</p>

			<section id="section-3.4.1">
<h4 title="Proactive Negotiation">3.4.1. ~proactive折衝</h4>

<div class="p">
<p>
［
`~UA$が，［［
選好される`表現$を，`~server$に所在する~algoにより選定してもらう
］ような`内容~折衝$
］についての選好を，要請~内に送信する
］ような折衝は、
`~proactive折衝^dfn
【“~~先取り” 折衝】
と呼ばれる（ “~server駆動な折衝” としても知られている）。
選定は、次の 2 つの比較対照に基づく：
◎
When content negotiation preferences are sent by the user agent in a request to encourage an algorithm located at the server to select the preferred representation, it is called proactive negotiation (a.k.a., server-driven negotiation). Selection is based on＼
</p>

<ul>
	<li>
応答に可用な`表現$（選好の次元は、言語, `内容~符号法$, 等々，多様になり得る）。
◎
the available representations for a response (the dimensions over which it might vary, such as language, content-coding, etc.) compared to＼
</li>
	<li>
要請~内に給される様々な情報。
これには、明示的な折衝~header（`5.3$sec）や，暗黙的~特性
—  ~clientの~network~address, `User-Agent$h ~headerの各 部分など —
も含まれる。
◎
various information supplied in the request, including both the explicit negotiation fields of Section 5.3 and implicit characteristics, such as the client's network address or parts of the User-Agent field.
</li>
</ul>
</div>

<div class="p">
<p>
~proactive折衝は、次のときに有利になる：
◎
Proactive negotiation is advantageous when＼
</p>

<ul>
	<li>
［
可用な`表現$の中から一つを選定するための~algo
］を，~UAに向けて述べるのが困難であるとき。
◎
the algorithm for selecting from among the available representations is difficult to describe to a user agent, or＼
</li>
	<li>
`~server$が，最初の応答に［
~UAにとって “最良と推測される” もの
］を送信することを欲するとき（利用者にとり，その推測で十分良いときに、後続な要請の往復による遅延を避けることを~~期待して）。
◎
when the server desires to send its "best guess" to the user agent along with the first response (hoping to avoid the round trip delay of a subsequent request if the "best guess" is good enough for the user).＼
</li>
</ul>

<p>
`~UA$は、`~server$による推測を改善させるために，［
自身の選好を述べる`要請~header$
］を送信してもヨイ。
◎
In order to improve the server's guess, a user agent MAY send request header fields that describe its preferences.
</p>
</div>

<p>
~proactive折衝には、深刻な不利がある：
◎
Proactive negotiation has serious disadvantages:
</p>

<ul>
	<li>
`~server$にとっては、［
任意の利用者にとって，何が “最良” になるか
］を正確aに決定することは，不可能である
— そのためには、［
~UAに備わる能力,
応答に対し意図される利用（例： 利用者は，~screen上, 紙への印刷のどっちを求めているか？）
］の両者について，完全な知識を要求することになるので。
◎
• It is impossible for the server to accurately determine what might be "best" for any given user, since that would require complete knowledge of both the capabilities of the user agent and the intended use for the response (e.g., does the user want to view it on screen or print it on paper?);
</li>
	<li>
~UAが 毎~要請ごとに，自身に備わる能力を述べるとするなら、とても非効率になり得る（ごく小さな割合の応答のみが複数の`表現$を持つ下では）。
更に、利用者の~privacyに対する~riskも高める。
◎
• Having the user agent describe its capabilities in every request can be both very inefficient (given that only a small percentage of responses have multiple representations) and a potential risk to the user's privacy;
</li>
	<li>
［
`生成元~server$, および
要請に対する応答を生成する~algo
］の実装が複雑化する。
◎
• It complicates the implementation of an origin server and the algorithms for generating responses to a request; and,
</li>
	<li>
共用~cachingにおける応答の再利用性が，制限される。
◎
• It limits the reusability of responses for shared caching.
</li>
</ul>

<p>
`~UA$は、［
~proactive折衝による選好が一貫して尊守される
］ことに依拠できない
— `生成元~server$は、要請された`資源$用には ~proactive折衝を実装していなかったり，［
~UAの選好に適合しない応答を送信する方が， `406$st 応答を送信するより良い
］と裁定することもあるので。
◎
A user agent cannot rely on proactive negotiation preferences being consistently honored, since the origin server might not implement proactive negotiation for the requested resource or might decide that sending a response that doesn't conform to the user agent's preferences is better than sending a 406 (Not Acceptable) response.
</p>

<p>
`Vary$h ~headerは、［
要請のどの部分の情報が，選定~algoに利用されるか
］を指示するために，［
~proactive折衝を~subjectとする応答
］内に送信されることが多い。
◎
A Vary header field (Section 7.1.4) is often sent in a response subject to proactive negotiation to indicate what parts of the request information were used in the selection algorithm.
</p>

			</section>
			<section id="section-3.4.2">
<h4 title="Reactive Negotiation">3.4.2. ~reactive折衝</h4>

<div class="p">

<p>
`~reactive折衝^dfn
【“~~受け身の” 折衝】
においては、`表現$の選定は，~UAにより遂行される（ “~agent駆動な折衝” としても知られている）。
すなわち，`~UA$は：
◎
With reactive negotiation (a.k.a., agent-driven negotiation), selection of the best response representation (regardless of the status code) is performed by the user agent＼
</p>

<ol>
	<li>
`生成元~server$から［
代替~表現~用の`資源$の~listを包含する，初期~応答
］を受信した後に，（その状態s~codeに関わらず）最良な応答~表現を選定する。
◎
after receiving an initial response from the origin server that contains a list of resources for alternative representations.＼
</li>
	<li>
初期~応答の表現で充足されない場合には、［
その応答~用の，異なる形による表現
］を得するために，［
~list内に内包された~metadataに基づいて選定される，一つ以上の代替~資源
］へ向けて， `GET$m 要請を遂行できる。
◎
If the user agent is not satisfied by the initial response representation, it can perform a GET request on one or more of the alternative resources, selected based on metadata included in the list, to obtain a different form of representation for that response.＼
</li>
</ol>

<p>
代替の選定は、~UAにより自動的に遂行されることもあれば、利用者が，生成された（場合によっては~hypertextによる）~menuから手動で選定することもある。
◎
Selection of alternatives might be performed automatically by the user agent or manually by the user selecting from a generated (possibly hypertext) menu.
</p>
</div>

<div class="p">
<p>
上における表現は、一般には，応答の表現を指すことに注意
— `資源$の表現ではなく。
代替~表現は、［
それを供した応答が，次のいずれかの意味論を持つ
］場合に限り，`~target資源$の表現であると見なされる：
◎
Note that the above refers to representations of the response, in general, not representations of the resource. The alternative representations are only considered representations of the target resource if the response in which those alternatives are provided＼
</p>

<ul>
	<li>
~target資源の`表現$である（例： `GET$m 要請に対する `200$st 応答）
◎
has the semantics of being a representation of the target resource (e.g., a 200 (OK) response to a GET request) or＼
</li>
	<li>
~target資源~用の代替~表現への~linkを供する（例： `GET$m 要請に対する `300$st 応答）
◎
has the semantics of providing links to alternative representations for the target resource (e.g., a 300 (Multiple Choices) response to a GET request).
</li>
</ul>
</div>

<p>
`~server$は、［
代替~list以外の初期~表現を送信しない
— すなわち，`~UA$による~reactive折衝を選好することを指示する
］ことを選択してもよい。
例えば，［
`300$st ／ `406$st を伴う応答
］内に~listされる代替は、［
利用者または~UAが~reactiveに選定を行い得るような，可用な`表現$
］についての情報を内包する。
◎
A server might choose not to send an initial representation, other than the list of alternatives, and thereby indicate that reactive negotiation by the user agent is preferred. For example, the alternatives listed in responses with the 300 (Multiple Choices) and 406 (Not Acceptable) status codes include information about the available representations so that the user or user agent can react by making a selection.
</p>

<div class="p">

<p>
~reactive折衝は、次のときに有利になる：
◎
Reactive negotiation is advantageous＼
</p>

<ul>
	<li>
応答が、共通的に利用される次元（型【~MIME型】, 言語, 符号化法 など）にわたって，様々になり得るとき。
◎
when the response would vary over commonly used dimensions (such as type, language, or encoding),＼
</li>
	<li>
生成元~serverが、要請を精査しても，~UAに備わる能力を決定できないとき。
◎
when the origin server is unable to determine a user agent's capabilities from examining the request, and＼
</li>
	<li>
一般に、~server負荷を分散したり~network利用eを抑制するために，公共~cacheが利用されるとき。
◎
generally when public caches are used to distribute server load and reduce network usage.
</li>
</ul>
</div>

<p>
~reactive折衝には、代替~listを~UAへ伝送する手間を要する不利がある
— それは、［
~listを`~header節$~内に伝送し，代替-表現を得するために 2 度目の要請を要する
］場合に，利用者に知覚される待時間を~~増やす。
更には、この仕様は，自動的な選定を~supportする仕組みは定義しない
— そのような仕組みを拡張として開発することも~~止めないが。
◎
Reactive negotiation suffers from the disadvantages of transmitting a list of alternatives to the user agent, which degrades user-perceived latency if transmitted in the header section, and needing a second request to obtain an alternate representation. Furthermore, this specification does not define a mechanism for supporting automatic selection, though it does not prevent such a mechanism from being developed as an extension.
</p>

			</section>
		</section>
	</section>
	<section id="section-4">
<h2 title="Request Methods">4. 要請~method</h2>

		<section id="section-4.1">
<h3 title="Overview">4.1. 概観</h3>

<p>
要請 `method^p ~tokenが、要請の意味論の首な~sourceになる：
それは、`~client$が［
当の要請を為した目的, および成功裡な結果として期待するもの
］を指示する。
◎
The request method token is the primary source of request semantics; it indicates the purpose for which the client has made this request and what is expected by the client as a successful result.
</p>

<p>
`要請~method$の意味論は、要請~内に［
その~methodと競合しないような意味論を追加する，何らかの~header
］が在るときには、更に特化され得る（`5$sec）。
例えば，~clientは、［
`~target資源$の現在の状態に要請される動作
］を，`条件付きに$するために、
`条件付き要請~header＠#section-5.2$
を送信できる。
◎
The request method's semantics might be further specialized by the semantics of some header fields when present in a request (Section 5) if those additional semantics do not conflict with the method. For example, a client can send conditional request header fields (Section 5.2) to make the requested action conditional on the current state of the target resource ([RFC7232]).
</p>

<pre class="bnf">
`method$p
	= `token$p
</pre>

【！Errata 4224 Rejected】

<p>
~HTTPは、~~元々は，分散型の~obj~system用の~interfaceとして利用できるように設計された。
`要請~method$は、［
識別された~obj上に定義された~methodの呼出しが，意味論を適用することになる
］のと ほぼ同じように，［
`~target資源$に意味論を適用するもの
］として想起された。
そのため、 `method$p ~tokenは，文字大小区別である
— ［
~method名が文字大小区別であるような，~obj~based~system
］への~gatewayとしても，利用され得るので。
◎
HTTP was originally designed to be usable as an interface to distributed object systems. The request method was envisioned as applying semantics to a target resource in much the same way as invoking a defined method on an identified object would apply semantics. The method token is case-sensitive because it might be used as a gateway to object-based systems with case-sensitive method names.
</p>

<p>
分散型の~objと違って、［
~HTTPにおける標準~化された `要請~method$
］は，`資源$に特有ではない
— ~network~based~systemにおいては、統一的~interfaceが［
可視性と再利用
］をより良く供するので `REST$r 。
標準~化された~methodは、いったん定義されたなら，どの資源に適用されるときにも 同じ意味論を備える~OUGHT
— それらの意味論を，自身に
実装する／許容する
かどうかは、それぞれの資源が決定するが。
◎
Unlike distributed objects, the standardized request methods in HTTP are not resource-specific, since uniform interfaces provide for better visibility and reuse in network-based systems [REST]. Once defined, a standardized method ought to have the same semantics when applied to any resource, though each resource determines for itself whether those semantics are implemented or allowed.
</p>

<p>
この仕様は、~HTTPにおいて共通的に利用される，いくつかの標準~化された~methodを定義する。
慣行により、標準~化された~method名は，大文字のみからなる US-ASCII 英字で定義される。
それらは、次の表tに集約される：
◎
This specification defines a number of standardized methods that are commonly used in HTTP, as outlined by the following table. By convention, standardized methods are defined in all-uppercase US-ASCII letters.
</p>

<div>
<table><thead>
<tr><td>~method
<td>記述
<tbody>

<tr><td>`GET$m
<td>`~target資源$の現在の`表現$を転送する。

<tr><td>`HEAD$m
<td>`GET$m と同じだが，`状態s行l$と`~header節$のみを転送する。

<tr><td>`POST$m
<td>要請~payloadに対し，資源に特有な処理を遂行する。

<tr><td>`PUT$m
<td>~target資源の現在の表現~すべてを，要請~payloadに置換する。

<tr><td>`DELETE$m
<td>~target資源の現在の表現~すべてを，除去する。

<tr><td>`CONNECT$m
<td>~target資源で識別される`~server$へ，`~tunnel$を確立する。

<tr><td>`OPTIONS$m
<td>~target資源~用の通信~optionを述べる。

<tr><td>`TRACE$m
<td>~target資源への経路に沿って~message~loop-back~testを遂行する。
</table>

<pre lang="en" class="_en">
   +---------+-------------------------------------------------+-------+
   | Method  | Description                                     | Sec.  |
   +---------+-------------------------------------------------+-------+
   | GET     | Transfer a current representation of the target | 4.3.1 |
   |         | resource.                                       |       |
   | HEAD    | Same as GET, but only transfer the status line  | 4.3.2 |
   |         | and header section.                             |       |
   | POST    | Perform resource-specific processing on the     | 4.3.3 |
   |         | request payload.                                |       |
   | PUT     | Replace all current representations of the      | 4.3.4 |
   |         | target resource with the request payload.       |       |
   | DELETE  | Remove all current representations of the       | 4.3.5 |
   |         | target resource.                                |       |
   | CONNECT | Establish a tunnel to the server identified by  | 4.3.6 |
   |         | the target resource.                            |       |
   | OPTIONS | Describe the communication options for the      | 4.3.7 |
   |         | target resource.                                |       |
   | TRACE   | Perform a message loop-back test along the path | 4.3.8 |
   |         | to the target resource.                         |       |
   +---------+-------------------------------------------------+-------+
</pre>
</div>

<p>
すべての一般用`~server$は、
`GET$m および `HEAD$m を~supportしなければナラナイ。
他の~methodの~supportは、すべて`任意選択^2119である。
◎
All general-purpose servers MUST support the methods GET and HEAD. All other methods are OPTIONAL.
</p>

<p>
この仕様の視野から外れる，追加的な~methodも、~HTTPにおける利用のために標準~化されている。
そのような~methodは すべて，［
~IANAにより保守される
"Hypertext Transfer Protocol (HTTP)  Method Registry"
］の中に登録される~OUGHT（`8.1$sec）。
◎
Additional methods, outside the scope of this specification, have been standardized for use in HTTP. All such methods ought to be registered within the "Hypertext Transfer Protocol (HTTP) Method Registry" maintained by IANA, as defined in Section 8.1.
</p>

<div class="p">

<p>
`~target資源$に許容される~methodの集合は，
`Allow$h ~header内に~listできる／され得る。
加えて，その集合は、
【応答ごとに】
動的に変更できる／変化し得る。
◎
The set of methods allowed by a target resource can be listed in an Allow header field (Section 7.4.1). However, the set of allowed methods can change dynamically.＼
</p>

<p>
`生成元~server$は：
◎
＼
</p>

<ul>
	<li>
自身が未認識／実装していない `要請~method$を受信したときは、
`501$stで応答するベキである。
◎
When a request method is received that is unrecognized or not implemented by an origin server, the origin server SHOULD respond with the 501 (Not Implemented) status code.＼
</li>
	<li>
自身に既知であるが，~target資源には許容されない `要請~method$を受信したときは、
`405$stで応答するベキである。
◎
When a request method is received that is known by an origin server but not allowed for the target resource, the origin server SHOULD respond with the 405 (Method Not Allowed) status code.
</li>
</ul>

</div>

		</section>
		<section id="section-4.2">
<h3 title="Common Method Properties">4.2. 共通な~method~property</h3>

			<section id="section-4.2.1">
<h4 title="Safe Methods">4.2.1. 安全な~method</h4>

<p>
`要請~method$は、［
それに定義される意味論が本質的に読取専用
］であるとき，
`安全である^dfn
と見なされる
— すなわち，`~client$は、［
安全な~methodを`~target資源$に適用した結果
］として，`生成元~server$上の いかなる状態~変化も，要請しない／期待しない。
同様に，［
安全な~methodの適度な利用
］は、生成元~server上に，いかなる［
害／~propertyの損失／非常な負担
］も及ぼさないものと期待されている。
◎
Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.
</p>

<p>
この［
安全な~methodの定義
］は、その呼出しが［
有害にもなり得る ／
読取専用でない~~部分がある ／
副作用を及ぼす
］ような挙動を含まないことを 実装に~~強いるものではない。
しかしながら，重要な点は、`~client$は［
追加的な挙動を要請しないし, それについて~~関知できない
］ことにある。
例えば、ほとんどの~serverは，［
~methodに関わらず，応答が完了するごとに 要請~情報を~access~log~fileに付加する
］が、［
その~log~storageが満杯になり，~serverが~crashする可能性がある
］としても，安全と見なされる。
同様に，~Web広告を選定することにより起動される 安全な要請には、広告料を課金するような副作用があることが多い。
◎
This definition of safe methods does not prevent an implementation from including behavior that is potentially harmful, that is not entirely read-only, or that causes side effects while invoking a safe method. What is important, however, is that the client did not request that additional behavior and cannot be held accountable for it. For example, most servers append request information to access log files at the completion of every response, regardless of the method, and that is considered safe even though the log storage might become full and crash the server. Likewise, a safe request initiated by selecting an advertisement on the Web will often have the side effect of charging an advertising account.
</p>

<p>
この仕様で定義される`要請~method$のうち［
`GET$m ,
`HEAD$m ,
`OPTIONS$m ,
`TRACE$m
］は、安全であるものと定義される。
◎
Of the request methods defined by this specification, the GET, HEAD, OPTIONS, and TRACE methods are defined to be safe.
</p>

<p>
~methodが安全か否かを判別する目的は、自動化された検索取得~処理n（~spider）や, ~cache処理能の最適化（事前fetch）が，害を及ぼす心配なしに働けるようにすることである。
加えて，~UAが［
信用できない~~可能性もある内容
］を処理する際に、安全でない~methodが自動的に利用されないよう，適切な拘束を適用することも可能になる。
◎
The purpose of distinguishing between safe and unsafe methods is to allow automated retrieval processes (spiders) and cache performance optimization (pre-fetching) to work without fear of causing harm. In addition, it allows a user agent to apply appropriate constraints on the automated use of unsafe methods when processing potentially untrusted content.
</p>

<p>
`~UA$は、~methodが安全か否かを判別して、安全でない動作は要請される前に利用者が自覚できるよう，~~行われ得る動作を利用者に呈示するベキである。
◎
A user agent SHOULD distinguish between safe and unsafe methods when presenting potential actions to a user, such that the user can be made aware of an unsafe action before it is requested.
</p>

<p>
`資源$が［［
`実効~要請~URI$に~~埋め込まれた~parameter群
］が動作を選定する効果を持つ
］ように構築されているとき、［
その動作が，`要請~method$の意味論に整合する
］ことを確保することは，資源~所有者の責務である。
例えば、［
~Web~based内容~編集~softwareが，
`query$p ~parameterに~~埋め込まれた動作を利用する
］ことは，共通的にある
— "`page?do=delete^c" など。
そのような資源の目的が，安全でない動作の遂行-である場合、資源~所有者は，［
それが安全な要請~methodを利用して~accessされる
］ときには，その動作を不能化するか, 不許可にしなければナラナイ。
さもなければ、［
~link保守, 事前fetch, 探索~indexの構築0, 等々
］の~~目的で，［
どの`~URI$参照に対しても，自動化された処理により `GET$m が遂行される
］ときに、~~望ましくない副作用が~~生じることになる。
◎
When a resource is constructed such that parameters within the effective request URI have the effect of selecting an action, it is the resource owner's responsibility to ensure that the action is consistent with the request method semantics. For example, it is common for Web-based content editing software to use actions within query parameters, such as "page?do=delete". If the purpose of such a resource is to perform an unsafe action, then the resource owner MUST disable or disallow that action when it is accessed using a safe request method. Failure to do so will result in unfortunate side effects when automated processes perform a GET on every URI reference for the sake of link maintenance, pre-fetching, building a search index, etc.
</p>

			</section>
			<section id="section-4.2.2">
<h4 title="Idempotent Methods">4.2.2. 冪等~method</h4>

<p>
`要請~method$は、［
複数回の［
互いに一致する，その~methodを伴う要請
］により意図される，`~server$上の効果
］が［
単独の そのような要請による効果
］と同じになるとき，
`冪等である^dfn
と見なされる。
この仕様で定義される要請~methodのうち［
`PUT$m,
`DELETE$m,
`安全な$要請~method
］は、冪等である。
◎
A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
</p>

<p>
`安全$の定義と同様に、冪等性の定義が適用されるのは，［
利用者から何が要請されたか
］に限られる
— `~server$は、各 冪等な要請に対し，次を行ってもかまわない
⇒＃
その~logを別にとる／
改訂~制御~用の履歴を維持する／
他の非~冪等な副作用を実装する
◎
Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free to log each request separately, retain a revision control history, or implement other non-idempotent side effects for each idempotent request.
</p>

<p>
冪等~methodには、［
`~client$が`~server$の応答を読取れるようになる前に，通信が失敗した場合には、要請を自動的に繰返せる
］という~~特徴がある。
例えば、~clientが `PUT$m 要請を送信したとき，応答が受信される前に 下層の接続が~closeされた場合、~clientは，新たな接続を確立して冪等~要請を再試行できる。
元の要請が~成功していたとしても、その要請を繰返した結果が
— 応答は相違するかもしれないが —
意図された効果と同じになることがわかっているので。
◎
Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection is closed before any response is received, then the client can establish a new connection and retry the idempotent request. It knows that repeating the request will have the same intended effect, even if the original request succeeded, though the response might differ.
</p>

			</section>
			<section id="section-4.2.3">
<h4 title="Cacheable Methods">4.2.3. ~cache可能な~method</h4>

<p>
`要請~method$には、
`~cache可能^dfn
と定義されるものもある
— それは、［［
その要請に対する応答を未来の再利用のために格納する
］ことが許容されている
］ことを指示する。
特有な要件については、`7234$Rを見よ。
一般に，［［
現在の／権限的な
］応答に依存しない，`安全な$~method
］は、~cache可能として定義される
— この仕様は、［
`GET$m, `HEAD$m, `POST$m 
］を~cache可能として定義する —
ほとんどの~cache実装は、 `GET$m, `HEAD$m のみを~supportしているが。
◎
Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see [RFC7234]. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD.
</p>

			</section>
		</section>
		<section id="section-4.3">
<h3 title="Method Definitions">4.3. ~method定義</h3>

			<section id="section-4.3.1">
<h4>4.3.1. `GET^m</h4>

<p>
`GET^m ~methodは、［
現在の，`~target資源$用に`選定される表現$
］を転送するよう要請する。
`GET^m は、情報を検索取得する首な仕組みであり，ほぼすべての処理能 最適化の力点が置かれる所である。
よって、誰かが［
~HTTPを介して識別できる何らかの情報を検索取得する
］ことについて話すとき，たいていは `GET^m 要請を為すことを指している。
◎
The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
</p>

<p>
資源~識別子は ~remote~file~systemの~pathnameで，`表現$は そのような~file内容の複製であると、~~考えられがちである。
事実、多くの資源が実装されている方法でもある（関係する~securityの考慮点については`9.1$secを見よ）。
しかしながら、実施においてそのような制限は無い。
資源~用の~HTTP~interfaceは、単に［
内容~objの~tree ／
様々な~database~record上の~programmatic~view ／
他の情報~systemへの~gateway
］などとして実装される見込みも高い。
`~URI$対応付けの仕組みが，~file~systemに縛られているときでも、`生成元~server$は，［
~fileを直に転送するのではなく，［
要請を入力に~fileを実行して、その出力として，表現を送信する
］ように環境設定される
］こともある。
いずれにせよ、 `GET^m に対する応答において，［
その各~資源~識別子を，どの実装に対応させるか
］や, ［
各~実装が［
`~target資源$の現在の表現を選定して送信すること
］を，どう管理するか
］を知る必要があるのは、生成元~serverのみである。
◎
It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of the contents of such files. In fact, that is how many resources are implemented (see Section 9.1 for related security considerations). However, there are no such limitations in practice. The HTTP interface for a resource is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured to execute the files with the request as input and send the output as the representation rather than transfer the files directly. Regardless, only the origin server needs to know how each of its resource identifiers corresponds to an implementation and how each implementation manages to select and send a current representation of the target resource in a response to GET.
</p>

<p>
`~client$は、要請~内に `Range$h ~header （`7233$R）を送信することにより，
`GET^m の意味論を［［
`選定された表現$のいくつかの部分
］のみの転送を要請する
“範囲~要請”
］に改めることもできる。
◎
A client can alter the semantics of GET to be a "range request", requesting transfer of only some part(s) of the selected representation, by sending a Range header field in the request ([RFC7233]).
</p>

<p>
`GET^m 要請~messageの~payloadには、意味論は定義されない
— 既存の実装には、`~payload本体$を伴って送信されてきた `GET^m 要請を却下するものもある。
◎
A payload within a GET request message has no defined semantics; sending a payload body on a GET request might cause some existing implementations to reject the request.
</p>

<p>
`GET^m 要請に対する応答は，`~cache可能$である
— `Cache-Control$h ~headerから指示されない限り、［
後続な［
`GET^m ／ `HEAD$m
］要請を充足する
］ために，その応答を~cacheに利用してもヨイ。
◎
The response to a GET request is cacheable; a cache MAY use it to satisfy subsequent GET and HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [RFC7234]).
</p>

			</section>
			<section id="section-4.3.2">
<h4>4.3.2. `HEAD^m</h4>

<p>
`HEAD^m ~methodは、［
~serverが，応答~内に`~message本体$を送信してはナラナイ（すなわち，応答は、`~header節$の終端で終了する）
］ことを除いて、 `GET$m と一致する。
`~server$は、 `HEAD^m 要請に対する応答~内に，［
要請が `GET$m であったときに送信することになる~headerたち
］と同じ~headerたちを送信するベキである
— ただし、それらのうち`~payload~header$は省略されてヨイ。
この~methodは、［
`表現~data$を転送する
］ことなく，［
`選定された表現$についての~metadataを得する
］ために利用でき、また，［［
妥当性 ／ ~accessibility ／ 近過去の改変
］のために~hypertext~linkを~testする
］ときに，利用されることが多い。
◎
The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields (Section 3.3) MAY be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation data and is often used for testing hypertext links for validity, accessibility, and recent modification.
</p>

<p>
`HEAD^m 要請~messageの~payloadには、意味論は定義されない
— 既存の実装には、`~payload本体$を伴って送信されてきた `HEAD^m 要請を，却下するものもある。
◎
A payload within a HEAD request message has no defined semantics; sending a payload body on a HEAD request might cause some existing implementations to reject the request.
</p>

<p>
`HEAD^m 要請に対する応答は，`~cache可能$である
— `Cache-Control$h ~headerから指示されない限り、［
後続な `HEAD^m 要請を充足する
］ために~cacheが利用されてヨイ。
`HEAD^m 応答も，［
以前に~cacheされた `GET$m に対する応答
］に効果を持つことがある
— `7234-4.3.5$rfcを見よ。
◎
The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the Cache-Control header field (Section 5.2 of [RFC7234]). A HEAD response might also have an effect on previously cached responses to GET; see Section 4.3.5 of [RFC7234].
</p>

			</section>
			<section id="section-4.3.3">
<h4>4.3.3. `POST^m</h4>

<p>
`POST^m ~methodは、［
`~target資源$が，自前の特有な意味論に則って，要請~内に同封された`表現$を処理する
］ことを要請する。
例えば `POST^m は、次の機能~用に利用される（他にもある）:
◎
The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics. For example, POST is used for the following functions (among others):
</p>

<ul>
	<li>
［
HTML ~formに手入力された一連の~field
］などの~data~blockを，~data取扱い処理nに供する。
◎
Providing a block of data, such as the fields entered into an HTML form, to a data-handling process;
</li>
	<li>
［
掲示板,
ニュースグループ,
メーリングリスト,
ブログ,
その他~同類の記事群
］などへ，~messageを投函する。
◎
• Posting a message to a bulletin board, newsgroup, mailing list, blog, or similar group of articles;
</li>
	<li>
`生成元~server$により まだ識別されていない，新たな資源を作成する。
◎
• Creating a new resource that has yet to be identified by the origin server; and
</li>
	<li>
既存の資源の，いくつかの`表現$に、~dataを付加する。
◎
• Appending data to a resource's existing representation(s).
</li>
</ul>

<p>
`生成元~server$は、［
`POST^m 要請の処理~結果に依存して，適切な状態s~codeを選択する
］ことにより，応答の意味論を指示する
— `POST^m に対する応答~内には、この仕様で定義される ほとんどの状態s~codeが，受信され得る（例外は： `206$st, `304$st, `416$st ）。
◎
An origin server indicates response semantics by choosing an appropriate status code depending on the result of processing the POST request; almost all of the status codes defined by this specification might be received in a response to POST (the exceptions being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not Satisfiable)).
</p>

<div class="p">

<p>
`POST^m 要請が成功裡に処理された結果，`生成元~server$上にて一つ以上の資源が作成された場合、生成元~serverは，次を包含する `201$st 応答を送信するベキである：
◎
If one or more resources has been created on the origin server as a result of successfully processing a POST request, the origin server SHOULD send a 201 (Created) response containing＼
</p>

<ul>
	<li>
［
作成された`首な資源$用の識別子
］を供する `Location$h ~header,
◎
a Location header field that provides an identifier for the primary resource created (Section 7.1.2) and＼
</li>
	<li>
新たな資源（たち）を指しつつ, 要請の状態sも述べるような，`表現$。
◎
a representation that describes the status of the request while referring to the new resource(s).
</li>
</ul>
</div>

<p>
`POST^m 要請に対する応答は、［
それが，明示的な`鮮度~情報$を内包する
］ときに限り，`~cache可能$である。
しかしながら， `POST^m に対する~cachingは、まだ広範には実装されてはいない。
`生成元~server$は、［
`~client$が，今後の `GET$m により再利用し得るような仕方で［
`POST^m の結果
］を~cacheできる
］ようにしたいと望むならば、［［
`POST^m の`実効~要請~URI$と同じ値をとる， `Content-Location$h ~header
］を包含している `200$st 応答
］を送信してもヨイ。
◎
Responses to POST requests are only cacheable when they include explicit freshness information (see Section 4.2.1 of [RFC7234]). However, POST caching is not widely implemented. For cases where an origin server wishes the client to be able to cache the result of a POST in a way that can be reused by a later GET, the origin server MAY send a 200 (OK) response containing the result and a Content-Location header field that has the same value as the POST's effective request URI (Section 3.1.4.2).
</p>

<p>
`POST^m の処理~結果が，既存の資源の`表現$と等価になる場合、`生成元~server$は、［
その既存の資源の識別子を `Location$h ~header内に伴う， `303$st 応答
］を送信して，`~UA$を~redirectしてもヨイ。
これには、特典がある
— 資源~識別子を~UAに供して，表現を［
共用~cachingに，より~~受容され易い~method
］を介して転送させるような
— ~UAが~cache済み表現をまだ持っていない場合には，余分な要請~costがかかるが。
◎
If the result of processing a POST would be equivalent to a representation of an existing resource, an origin server MAY redirect the user agent to that resource by sending a 303 (See Other) response with the existing resource's identifier in the Location field. This has the benefits of providing the user agent a resource identifier and transferring the representation via a method more amenable to shared caching, though at the cost of an extra request if the user agent does not already have the representation cached.
</p>

			</section>
			<section id="section-4.3.4">
<h4>4.3.4. `PUT^m</h4>

<p>
`PUT^m ~methodは、［
`~target資源$の状態を，［
要請~message~payload内に同封された`表現$により定義される状態
］として作成する, あるいはその状態に置換する
］ことを要請する。
［
所与の表現に対する成功裡な `PUT^m
］は、［
同じ~target資源に対する後続な `GET$m の結果が，
`200$st 応答~内に送信されている表現と等価になる
］ことを示唆する。
しかしながら，［
そのような状態~変化が観測-可能になる
］ことは保証されない
— ~target資源は、［
後続な `GET$m が受信される前に，並列的な 他の~UAにより動作されたり
］, ［
`生成元~server$による動的~処理の~subjectである
］こともあるので。
成功裡な応答は、その処理~時点で［
~UAの意図が，生成元~serverにより達成された
］ことのみを含意する。
◎
The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.
</p>

<p>
`生成元~server$には、以下の要件が課される
— 以下、 `PUT^m された`表現$を `P^var と記す：
◎
↓</p>

<ul>
	<li>
<p>
`~target資源$が現在の`表現$を：
◎
↓</p>
		<ul>
			<li>
持たない場合
⇒
`PUT^m が何か一つを成功裡に作成したときは、
`201$st 応答を`~UA$に送信してその旨を伝えなければナラナイ。
◎
If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response.＼
</li>
			<li>
持つ場合
⇒
その表現が， `P^var の状態に則って 成功裡に改変されたときは、
`200$st または `204$st 応答を送信して，要請の成功裡な完了を指示しなければナラナイ。
◎
If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.
</li>
		</ul>
	</li>
	<li>
<p>
`PUT^m 要請~内に受信された，未認識~headerは、無視する（すなわち，資源~状態の一部として保存しない）ベキである。
◎
An origin server SHOULD ignore unrecognized header fields received in a PUT request (i.e., do not save them as part of the resource state).
</p>
</li>
	<li>

<div class="p">
<p>
［
`~target資源$に備わる［
`PUT^m により変更できない／されることにはならない
］ようにする，どの拘束
］にも， `P^var が整合することを検証yするベキである。
これは特に、`生成元~server$が［
`~URI$に関係する内部 環境設定~情報を利用して，
`GET$m 応答~上の`表現~metadata$用の値を設定している
］ときに，重要になる。
◎
An origin server SHOULD verify that the PUT representation is consistent with any constraints the server has for the target resource that cannot or will not be changed by the PUT. This is particularly important when the origin server uses internal configuration information related to the URI in order to set the values for representation metadata on GET responses.＼
</p>

<p>
`P^var が~target資源と整合でないときには、次のいずれかをするベキである：
◎
When a PUT representation is inconsistent with the target resource, the origin server SHOULD either＼
</p>
		<ul>
			<li>
［
`P^var を形式変換するか, 資源についての環境設定を変更する
］ことにより，それらを整合させる。
◎
make them consistent, by transforming the representation or changing the resource configuration, or＼
</li>
			<li>
［
何故 `P^var が相応でないかを説明するに足る情報
］を包含する，適切な~error~messageで応答する。
それが `Content-Type$h 値に対する拘束に特有であるときは、［
`409$st ／ `415$st
］が示唆される。
◎
respond with an appropriate error message containing sufficient information to explain why the representation is unsuitable. The 409 (Conflict) or 415 (Unsupported Media Type) status codes are suggested, with the latter being specific to constraints on Content-Type values.
</li>
		</ul>
</div>

<p>
例えば，［
`~target資源$が常に `Content-Type$h に "`text/html^c" を持つ
］ように環境設定されていて, ［
`P^var が `Content-Type$h に "`image/jpeg^c" を持つ
］場合、次のいずれかをする~OUGHT：
◎
For example, if the target resource is configured to always have a Content-Type of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of:
</p>

		<ul>
			<li>
~target資源が新たな`~MIME型$を反映するように，環境設定を~~改める。
◎
a. reconfigure the target resource to reflect the new media type;
</li>
			<li>
`P^var を新たな資源~状態として保存する前に、
`P^var の形式が資源の形式と整合するように，
`P^var を形式変換する。
◎
b. transform the PUT representation to a format consistent with that of the resource before saving it as the new resource state; or,
</li>
			<li>
要請に対し、［
~target資源が "`text/html^c" に制限されていることを指示する， `415$st 応答
］で却下する
— たぶん［
新たな`表現$に相応しい~targetになる，異なる資源への~link
］を内包するような。
◎
c. reject the request with a 415 (Unsupported Media Type) response indicating that the target resource is limited to "text/html", perhaps including a link to a different resource that would be a suitable target for the new representation.
</li>
		</ul>

	</li>
</ul>

<div class="p">

<p>
~HTTPは、次のものは定義しない：
◎
HTTP does not define＼
</p>

<ul>
	<li>
`PUT^m ~methodが `生成元~server$の状態に正確に どう影響するかについて
— ［
~UA要請の意図や, 生成元~serverによる応答の意味論により表出し得るもの
］を超えるような。
◎
exactly how a PUT method affects the state of an origin server beyond what can be expressed by the intent of the user agent request and＼
</li>
	<li>
資源が何になり得るかについて
— ［
~HTTPを介して供される~interface
］を超えるような，その言葉が表すいかなるイミにおいても。
◎
the semantics of the origin server response.＼
It does not define what a resource might be, in any sense of that word, beyond the interface provided via HTTP.＼
</li>
	<li>
資源~状態が どう “格納される” か。
◎
It does not define how resource state is "stored", nor＼
</li>
	<li>
資源~状態が変化した結果，そのような~storageが どう変化し得るか。
◎
how such storage might change as a result of a change in resource state, nor＼
</li>
	<li>
生成元~serverが，資源~状態を どう`表現$に翻訳するか。
◎
how the origin server translates resource state into representations.＼
</li>
</ul>

<p>
一般に、資源~interfaceの背後にある，実装の詳細すべては、~serverにより意図的に隠される。
◎
Generally speaking, all implementation details behind the resource interface are intentionally hidden by the server.
</p>
</div>

<div class="p">

<p>
`生成元~server$は、次の両者が~~満たされない限り，［
`PUT^m に対する成功裡な応答
］内に
— `ETag$h や `Last-Modified$h などの —
`検証子~header$を送信してはナラナイ：
◎
An origin server MUST NOT send a validator header field (Section 7.2), such as an ETag or Last-Modified field, in a successful response to PUT unless＼
</p>

<ul>
	<li>
要請の`表現~data$は、本体にいかなる形式変換も適用されずに，保存された（すなわち，資源の新たな表現~dataは、 `PUT^m 要請~内に受信された表現~dataと一致する）。
◎
the request's representation data was saved without any transformation applied to the body (i.e., the resource's new representation data is identical to the representation data received in the PUT request) and＼
</li>
	<li>
`検証子~header$の値は、新たな`表現$を反映している。
◎
the validator field value reflects the new representation.＼
</li>
</ul>

<p>
この要件により、`~UA$は，［
~memory内に持つ表現~本体が， `PUT^m の結果の現在の~~状態のままである
］時点を知れるようになる
— したがって，生成元~serverから再び検索取得する必要はなくなり、また，［
応答~内に受信した，新たな一連の`検証子$
］を未来の`条件付き要請$（`5.2$sec）に利用して，偶発的な上書-を防止できるようになる。
◎
This requirement allows a user agent to know when the representation body it has in memory remains current as a result of the PUT, thus not in need of being retrieved again from the origin server, and that the new validator(s) received in the response can be used for future conditional requests in order to prevent accidental overwrites (Section 5.2).
</p>
</div>

<div class="p">

<p>
`POST$m と `PUT^m の間の根本的な相違は、同封された`表現$の意図が異なることにある：
◎
The fundamental difference between the POST and PUT methods is highlighted by the different intent for the enclosed representation.＼
</p>

<ul>
	<li>
`POST$m 要請には、`~target資源$が［
同封された表現を，資源による自前の意味論に則って取扱う
］ことが意図される。
◎
The target resource in a POST request is intended to handle the enclosed representation according to the resource's own semantics, whereas＼
</li>
	<li>
`PUT^m 要請は、［
同封された表現が，~target資源の状態を置換する
］ものとして定義される。
◎
the enclosed representation in a PUT request is defined as replacing the state of the target resource.＼
</li>
</ul>

<p>
よって，`PUT^m の意図は、その正確な効果が 生成元~serverのみに既知であっても，`冪等$であり、`媒介者$からは可視になる。
◎
Hence, the intent of PUT is idempotent and visible to intermediaries, even though the exact effect is only known by the origin server.
</p>
</div>

<p>
`PUT^m 要請を適正に解釈するためには、［
~UAが，どの`~target資源$が
【利用者から】
欲されているかを知っている
］ことが前提になる。
［
~clientに利するために、状態変更 要請を受信した後，適正な`~URI$を選定する~service
］は、
`PUT^m ではなく， `POST$m ~methodを利用して 実装されるベキである。
`生成元~server$は、要請された `PUT^m により
`~target資源$の状態を変更する代わりに，異なる資源に適用させたい場合
— 資源が異なる~URIへ移動されたときなど —
には、適切な `3xx$st 応答を送信しなければナラナイ。
また，`~UA$は、要請を~redirectするかどうかに関して，自前の裁定を下してもヨイ。
◎
Proper interpretation of a PUT request presumes that the user agent knows which target resource is desired. A service that selects a proper URI on behalf of the client, after receiving a state-changing request, SHOULD be implemented using the POST method rather than PUT. If the origin server will not make the requested PUT state change to the target resource and instead wishes to have it applied to a different resource, such as when the resource has been moved to a different URI, then the origin server MUST send an appropriate 3xx (Redirection) response; the user agent MAY then make its own decision regarding whether or not to redirect the request.
</p>

<p>
`~target資源$に適用される `PUT^m 要請は、他の`資源$に副作用を及ぼし得る。
例えば、ある記事は， “種々の~version” （ある時点で他のいずれかの~versionと同じ状態を共有する，互いに異なる資源）を識別するために 別々な`~URI$を持ち得る。
したがって，
“現在の~version” の~URIに対する成功裡な `PUT^m 要請は、~target資源の状態を変化させた上で 新たな~versionの資源を作成し，更には、関係する資源~間の~linkを追加することもある。
◎
A PUT request applied to the target resource can have side effects on other resources. For example, an article might have a URI for identifying "the current version" (a resource) that is separate from the URIs identifying each particular version (different resources that at one point shared the same state as the current version resource). A successful PUT request on "the current version" URI might therefore create a new version resource in addition to changing the state of the target resource, and might also cause links to be added between the related resources.
</p>

<div class="p">

<p>
所与の`~target資源$に対し `PUT^m を許容する`生成元~server$は、［
`Content-Range$h ~headerを包含する `PUT^m 要請
］に対しては， `400$st 応答を送信しなければナラナイ
— その~payloadは、［
誤って全部的な`表現$として `PUT^m された，部分的~内容【！＊？】
］である見込みが高いので。
部分的な内容の更新は、次のいずれかによりアリである：
◎
An origin server that allows PUT on a given target resource MUST send a 400 (Bad Request) response to a PUT request that contains a Content-Range header field (Section 4.2 of [RFC7233]), since the payload is likely to be partial content that has been mistakenly PUT as a full representation. Partial content updates are possible＼
</p>

<ul>
	<li>
より大きい資源のある部位に重なるような状態にある，別々に識別される資源を~targetにする。
◎
by targeting a separately identified resource with state that overlaps a portion of the larger resource, or＼
</li>
	<li>
部分的な更新~用に特に定義された，異なる~methodを利用する（例えば，`5789$Rにて定義される `PATCH$m ~method）。
◎
by using a different method that has been specifically defined for partial updates (for example, the PATCH method defined in [RFC5789]).
</li>
</ul>
</div>

<p>
`PUT^m ~methodに対する応答は、`~cache可能$でない。
成功裡な `PUT^m 要請が，［
`実効~要請~URI$用に格納-済みな応答を，一つ以上~持つ~cache
］を通して渡された場合、それらの格納-済み応答は，
<a href="~7234#section-4.4" >無効化される</a>ことになる。
◎
Responses to the PUT method are not cacheable. If a successful PUT request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
</p>

			</section>
			<section id="section-4.3.5">
<h4>4.3.5. `DELETE^m</h4>

<p>
`DELETE^m ~methodは、［
`生成元~server$に，`~target資源$と，その現在の機能性との間の結付けを除去してもらう
］ことを要請する。
この~methodの効果は、 UNIX の rm ~commandに類似する：
それは、［
以前に結付けられた情報が削除される
］という期待ではなく，［
生成元~serverによる~URI対応付けにおける削除~演算
］を表出する。
◎
The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
</p>

<p>
`~target資源$が 現在の`表現$を一つ以上~持つ場合に，それらが［
`生成元~server$により破壊されたり, 結付けられた~storageが取戻される
］かどうかは、［
その資源の資質と, 生成元~serverによる その実装（この仕様の視野を超える）
］に全面的に依存する。
同様に、 `DELETE^m の結果として，［
~databaseや~gateway接続など，資源の他の実装~側面
］が［
~deactivateされる／~archiveされる
］必要が~~生じることもある。
一般に、生成元~serverは，［
削除を成遂げる仕組みが制定されている資源に限り， `DELETE^m を許容する
］ものと見做されている。
◎
If the target resource has one or more current representations, they might or might not be destroyed by the origin server, and the associated storage might or might not be reclaimed, depending entirely on the nature of the resource and its implementation by the origin server (which are beyond the scope of this specification). Likewise, other implementation aspects of a resource might need to be deactivated or archived as a result of a DELETE, such as database or gateway connections. In general, it is assumed that the origin server will only allow DELETE on resources for which it has a prescribed mechanism for accomplishing the deletion.
</p>

<p>
`DELETE^m ~methodを許容する資源は、相対的に少数である
— それは首に、［
利用者が，その効果に関して指令する
］ような，~remote著作~用の環境に利用される。
例えば，［
`PUT$m 要請を利用して，以前に作成された資源
］や, ［
`POST$m 要請に対する`201$st 応答の `Location$h ~headerを介して識別される資源
］は、それらの動作を~~元に戻すような，対応する `DELETE^m 要請を許容することもある。
~~同様に，［
~HTTP利用して改訂を制御する~clientなど，~remote運用~用の著作~機能を実装する~custom~UA実装
］では、［
~version~repositoryに対応するように加工されている，~serverの~URI 空間
］についての前提に基づいて， `DELETE^m を利用できることもある。
◎
Relatively few resources allow the DELETE method -- its primary use is for remote authoring environments, where the user has some direction regarding its effect. For example, a resource that was previously created using a PUT request, or identified via the Location header field after a 201 (Created) response to a POST request, might allow a corresponding DELETE request to undo those actions. Similarly, custom user agent implementations that implement an authoring function, such as revision control clients using HTTP for remote operations, might use DELETE based on an assumption that the server's URI space has been crafted to correspond to a version repository.
</p>

<div class="p">

<p>
`DELETE^m ~methodが成功裡に適用された場合、`生成元~server$は、動作~~状況に応じて，次のいずれかの状態s~codeを送信するベキである：
◎
If a DELETE method is successfully applied, the origin server SHOULD send＼
</p>

<ul>
	<li>
動作は成功する見込みが高いが、まだ実行済みでない場合
⇒
`202$st
◎
a 202 (Accepted) status code if the action will likely succeed but has not yet been enacted,＼
</li>
	<li>
動作は実行済みで、更なる情報は給されない場合
⇒
`204$st
◎
a 204 (No Content) status code if the action has been enacted and no further information is to be supplied, or＼
</li>
	<li>
動作は実行済みで、応答~messageが［
その状態sを述べる`表現$
］を内包する場合
⇒
`200$st
◎
a 200 (OK) status code if the action has been enacted and the response message includes a representation describing the status.
</li>
</ul>

【！Errata ID: 4436 "," → ";" 訳には影響なし】
</div>

<p>
`DELETE^m 要請~messageの~payloadには、意味論は定義されない
— 既存の実装には、`~payload本体$を伴って送信されてきた `DELETE^m 要請を却下するものもある。
◎
A payload within a DELETE request message has no defined semantics; sending a payload body on a DELETE request might cause some existing implementations to reject the request.
</p>

<p>
`DELETE^m ~methodに対する応答は、`~cache可能$でない。
<ins>成功裡な</ins>† `DELETE^m 要請が［
`実効~要請~URI$用に格納-済みな応答を，一つ以上~持つ~cache
］を通して渡される場合、それらの格納-済み応答は，<a href="~7234#section-4.4" >無効化する</a>ことになる。
【† `4689$errataによる挿入（ Held for Document Update: 2018-11-01 ）】
◎
Responses to the DELETE method are not cacheable. If a DELETE request passes through a cache that has one or more stored responses for the effective request URI, those stored responses will be invalidated (see Section 4.4 of [RFC7234]).
</p>

			</section>
			<section id="section-4.3.6">
<h4>4.3.6. `CONNECT^m</h4>

<p>
`CONNECT^m ~methodは、`受信者$に，［［
`request-target$p により識別される，行先の生成元~server
］への`~tunnel$を確立する
］こと, および［
それに成功したならば、~tunnelが~closeされるまで，受信者の挙動を［
両~方向とも，~packetの盲目的~回送
］に制約する
］ことを要請する。
~tunnelは、［
一つ以上の~proxyを通して，端点間の仮想~接続を作成する
］ときに共通的に利用される
— しかる後、 ~TLS（ Transport Layer Security, `5246$R）を利用して~secure化できるようになる。
◎
The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security, [RFC5246]).
</p>

<p>
`CONNECT^m は、~proxyへの要請に利用するためのみに意図されている。
`生成元~server$は，［
自身に向けられた `CONNECT^m 要請を受信した
］ときは、接続が確立されたことを指示するために，
`2xx$stで応答してもヨイ。
しかしながら，ほとんどの生成元~serverは、 `CONNECT^m を実装しない。
◎
CONNECT is intended only for use in requests to a proxy. An origin server that receives a CONNECT request for itself MAY respond with a 2xx (Successful) status code to indicate that a connection is established. However, most origin servers do not implement CONNECT.
</p>

<p>
 `~client$が［
`CONNECT^m 要請を送信する
］ときは、［
`authority-form$p による `request-target$p
］を送信しなければナラナイ
— すなわち，`request-target$p は、~colonで分離された，［
`~tunnel$の行先の~host名＆~port番号
］のみからなる。
◎
A client sending a CONNECT request MUST send the authority form of request-target (Section 5.3 of [RFC7230]); i.e., the request-target consists of only the host name and port number of the tunnel destination, separated by a colon.＼
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
</pre>
</div>

<div class="p">
<p>
`受信者$`~proxy$は、［
`request-target$p へ直に接続する
］か, あるいは［
別の~proxyを利用するよう環境設定されている場合は，
`CONNECT^m 要請を次の`内方$~proxyへ回送する
］ことにより，`~tunnel$を確立できる：
◎
The recipient proxy can establish a tunnel either by directly connecting to the request-target or, if configured to use another proxy, by forwarding the CONNECT request to the next inbound proxy.＼
</p>

<ul>
	<li>
どの `2xx$st 応答も、［
成功裡な応答の`~header節$を締めくくる空行
］の直後に，［
`送信者$（および すべての内方~proxy）が~tunnel~modeへ切替えることになる
］ことを指示する
— その空行より後に受信される~dataは、［
`request-target$p により識別される~server
］からのものになる。
◎
Any 2xx (Successful) response indicates that the sender (and all inbound proxies) will switch to tunnel mode immediately after the blank line that concludes the successful response's header section; data received after that blank line is from the server identified by the request-target.＼
</li>
	<li>
成功裡な応答 以外のどの応答も、［
~tunnelは まだ形成されておらず，接続は ~HTTPにより統治され続ける
］ことを指示する。
◎
Any response other than a successful response indicates that the tunnel has not yet been formed and that the connection remains governed by HTTP.
</li>
</ul>
</div>

<div class="p">

<p>
`~tunnel$は、［
~tunnel媒介者が，いずれかの側がその接続を~closeしたことを検出した
］とき，~closeされる
— その際には、`媒介者$は，順に次をしなければナラナイ：
◎
A tunnel is closed when a tunnel intermediary detects that either side has closed its connection: the intermediary MUST＼
</p>

<ol>
	<li>
~closeされた側から来た，応答待ち~dataすべてを、他の側へ送信することを試みる。
◎
attempt to send any outstanding data that came from the closed side to the other side,＼
</li>
	<li>
接続を両~側とも~closeする。
◎
close both connections, and＼
</li>
	<li>
送達されてない残りの~dataは、すべて破棄する。
◎
then discard any remaining data left undelivered.
</li>
</ol>

</div>

<p>
~proxy認証が，`~tunnel$を作成するための権限を確立するために利用されることもある。
◎
Proxy authentication might be used to establish the authority to create a tunnel.＼
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
CONNECT server.example.com:80 HTTP/1.1
Host: server.example.com:80
Proxy-Authorization: basic aGVsbG86d29ybGQ=
</pre>

</div>

<p>
任意な~serverへ`~tunnel$を確立することには、有意な~riskがある
— 特に、その行先が，~Web流通~用には意図されていない［
周知／予約-済み
］な~TCP~portであるときは。
例えば，［
`request-target$p "`example.com:25^c" への `CONNECT^m 
］は、~proxyに［
~SMTP流通~用に予約-済みな~port
］へ接続するよう示唆することになるであろう
— 許容された場合、~proxyを，~spam~emailを中継させるように騙せてしまう。
`CONNECT^m を~supportする`~proxy$は、その利用を［
既知~portの制限された集合
］または［
環境設定できる，安全な`要請~target$たちの~whitelist
］に制約するベキである。
◎
There are significant risks in establishing a tunnel to arbitrary servers, particularly when the destination is a well-known or reserved TCP port that is not intended for Web traffic. For example, a CONNECT to a request-target of "example.com:25" would suggest that the proxy connect to the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email. Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable whitelist of safe request targets.
</p>

<p>
`~server$は、［
`CONNECT^m に対する `2xx$st 応答
］内に［
`Transfer-Encoding$h ／ `Content-Length$h
］~headerを送信してはナラナイ。
`~client$は、［
`CONNECT^m に対する成功裡な応答
］にて受信された［
`Content-Length$h ／ `Transfer-Encoding$h
］~headerを，無視しなければナラナイ。
◎
A server MUST NOT send any Transfer-Encoding or Content-Length header fields in a 2xx (Successful) response to CONNECT. A client MUST ignore any Content-Length or Transfer-Encoding header fields received in a successful response to CONNECT.
</p>

<p>
`CONNECT^m 要請~messageの~payloadには、意味論は定義されない
— 既存の実装には、`~payload本体$を伴って送信されてきた `CONNECT^m 要請を却下するものもある。
◎
A payload within a CONNECT request message has no defined semantics; sending a payload body on a CONNECT request might cause some existing implementations to reject the request.
</p>

【！Errata 4351 Rejected ~ERRATA?rfc=7231&amp;eid=4351】

<p>
`CONNECT^m ~methodに対する応答は、`~cache可能$でない。
◎
Responses to the CONNECT method are not cacheable.
</p>

			</section>
			<section id="section-4.3.7">
<h4>4.3.7. `OPTIONS^m</h4>

<p>
`OPTIONS^m ~methodは、［
`生成元~server$／介在している`媒介者$
］に対し，［
`~target資源$に可用な通信~optionについての情報
］を要請する。
この~methodにより，`~client$は、資源に対する動作を含意することなく［［
資源に結付けられた，~optionや要件
］や, ［
~serverに備わる能力
］］を決定できるようになる。
◎
The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.
</p>

<p>
［
`request-target$p が~asterisk （ "`*^c" ）にされた， `OPTIONS^m 要請
］は、特定の資源に対してではなく，
`~server-wide@
に適用される。
`~server$の通信~optionは，概して資源に依存するので、この種の要請は，［
~clientが~serverに備わる能力を~testする以上のことは何もしない，
“ping” や “no-op” の類いの~method
］としてのみ有用になる。
例えば これを、［
`~HTTP11$への適合性（または その欠如）について，~proxyを~testする
］ときに利用できる。
◎
An OPTIONS request with an asterisk ("*") as the request-target (Section 5.3 of [RFC7230]) applies to the server in general rather than to a specific resource. Since a server's communication options typically depend on the resource, the "*" request is only useful as a "ping" or "no-op" type of method; it does nothing beyond allowing the client to test the capabilities of the server. For example, this can be used to test a proxy for HTTP/1.1 conformance (or lack thereof).
</p>

<p>
［
`request-target$p が~asterisk "`*^c" でない `OPTIONS^m 要請
］は、`~target資源$と通信するときに可用な~optionに，適用される。
◎
If the request-target is not an asterisk, the OPTIONS request applies to the options that are available when communicating with the target resource.
</p>

<div class="p">
<p>
`~server$は、そのような `OPTIONS^m に対し成功裡な応答を`生成する$ときは：
◎
A server generating a successful response to OPTIONS＼
</p>

<ul>
	<li>
［
自身が実装していて,
`~target資源$に適用-可能な，任意選択な特能を指示し得る
］ような，~header（例： `Allow$h ）すべてを
— この仕様では定義されない拡張があれば，それも含めて —
送信するベキである。
◎
SHOULD send any header fields that might indicate optional features implemented by the server and applicable to the target resource (e.g., Allow), including potential extensions not defined by this specification.＼
</li>
	<li>
<p>
応答~payloadも（もしあれば），［
~machine／ヒト
から読取n可能な，`表現$
］による通信~optionを述べ得る。
そのような表現~用の標準~形式は、この仕様では定義されないが，~HTTPの将来の拡張により定義され得る。
応答~内に`~payload本体$を送信しないときには，［
値 "`0^c" の `Content-Length$h ~header
］を`生成し$なければナラナイ。
</p>
<p class="trans-note">【
`5806$errataに報告あり（ Reported: 2019-08-21 ）：
“…送信しないときには，” の後に
“`204$st 生成するか, または”
を挿入する（ § `Content-Length^h の要件に矛盾するので）。
】</p>

◎
The response payload, if any, might also describe the communication options in a machine or human-readable representation. A standard format for such a representation is not defined by this specification, but might be defined by future extensions to HTTP. A server MUST generate a Content-Length field with a value of "0" if no payload body is to be sent in the response.
</li>
</ul>
</div>

<p>
`~client$は、 `OPTIONS^m 要請~内に，［
要請の`連鎖$にある，特定の`受信者$
］に宛てて `Max-Forwards$h ~headerを送信してもヨイ。
`~proxy$は、受信した要請を回送するときには，それが
`Max-Forwards$h ~headerを伴っていない限り，
`Max-Forwards$h ~headerを`生成し$てはナラナイ。
◎
A client MAY send a Max-Forwards header field in an OPTIONS request to target a specific recipient in the request chain (see Section 5.1.2). A proxy MUST NOT generate a Max-Forwards header field while forwarding a request unless that request was received with a Max-Forwards field.
</p>

<p>
`~client$は、［
`~payload本体$を包含する `OPTIONS^m 要請
］を`生成する$ときは，［
`表現$の`~MIME型$を述べる妥当な `Content-Type$h ~header
］を送信しなければナラナイ。
この仕様は，そのような~payloadのいかなる利用も定義しないが、
~HTTPの将来の拡張は，［
`~target資源$について，より詳細な~queryを為す
］ために `OPTIONS^m 要請の本体を利用し得る。
◎
A client that generates an OPTIONS request containing a payload body MUST send a valid Content-Type header field describing the representation media type. Although this specification does not define any use for such a payload, future extensions to HTTP might use the OPTIONS body to make more detailed queries about the target resource.
</p>

<p>
`OPTIONS^m ~methodに対する応答は、`~cache可能$でない。
◎
Responses to the OPTIONS method are not cacheable.
</p>

			</section>
			<section id="section-4.3.8">
<h4>4.3.8. `TRACE^m</h4>

<div class="p">
<p>
`TRACE^m ~methodは、［
~remoteの, ~app~levelの~loop-backによる，要請~message
］を要請する。
要請の`最終~受信者$は、受信された~messageを，次のような `200$st 応答で~clientへ返送するベキである：
</p>

<ul>
	<li>
応答には， `Content-Type$h 値に "`message/http$c" を伴わせる。
</li>
	<li>
受信された~messageを，応答の`~message本体$に含ませる。
</li>
	<li>
ただし、下に述べるいくつかの~headerは，~messageから除外する。
</li>
</ul>

◎
The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the message body of a 200 (OK) response with a Content-Type of "message/http" (Section 8.3.1 of [RFC7230]).＼
</div>

<p>
`最終~受信者@
とは、`生成元~server$であるか, または［
要請~内の `Max-Forwards$h 値に 0 を受信した，最初の`~server$
］である。
◎
The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request (Section 5.1.2).
</p>

<p>
`~client$は、 `TRACE^m 要請~内に，［
応答により開示され得るような，敏感な~dataを包含する~header
］を`生成し$てはナラナイ。
例えば，［
格納されている利用者 `資格証$や~cookie `6265$R
］を，`TRACE^m 要請~内に送信するような~UAは、無分別であろう。
要請の`最終~受信者$が，応答~本体を`生成する$ときには、［
敏感な~dataを包含しそうな どの`要請~header$
］も除外するベキである。
◎
A client MUST NOT generate header fields in a TRACE request containing sensitive data that might be disclosed by the response. For example, it would be foolish for a user agent to send stored user credentials [RFC7235] or cookies [RFC6265] in a TRACE request. The final recipient of the request SHOULD exclude any request header fields that are likely to contain sensitive data when that recipient generates the response body.
</p>

<p>
`TRACE^m により、`~client$は，［
要請の`連鎖$における，他方の終端で受信されているもの
］を見て，その~dataを［
~test用や診断~情報
］に利用できるようになる。
特に関心が持たれるものは、要請~連鎖を~traceする，
`Via$h ~headerの値である。
`Max-Forwards$h ~headerにより、~clientは，要請~連鎖の長さを制限できるようになる
— それは、［
~messageを回送している~proxyの`連鎖$が，無限~loopになっている
］かどうか，~testするときに有用になる。
◎
TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing or diagnostic information. The value of the Via header field (Section 5.7.1 of [RFC7230]) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an infinite loop.
</p>

<p>
`~client$は、 `TRACE^m 要請~内に`~message本体$を送信してはナラナイ。
◎
A client MUST NOT send a message body in a TRACE request.
</p>

<p>
`TRACE^m ~methodに対する応答は、`~cache可能$でない。
◎
Responses to the TRACE method are not cacheable.
</p>

			</section>
		</section>
	</section>
	<section id="section-5">
<h2 title="Request Header Fields">5. 要請~header</h2>

<div class="p">

<p>
`~client$は、次のいずれかのために
`要請~header^dfn
を送信する：
◎
A client sends request header fields to＼
</p>

<ul>
	<li>
要請~文脈についての更なる情報を供する。
◎
provide more information about the request context,＼
</li>
	<li>
`~target資源$の状態に基づいて，要請を`条件付きに$する。
◎
make the request conditional based on the target resource state,＼
</li>
	<li>
応答に選好される形式を示唆する。
◎
suggest preferred formats for the response,＼
</li>
	<li>
認証用の`資格証$を給する。
◎
supply authentication credentials, or＼
</li>
	<li>
期待される要請~処理を改変する。
◎
modify the expected request processing.＼
</li>
</ul>

<p>
これらの~headerは、~programming言語の~methodに渡す~parameterに類似な，要請の改変子として動作する。
◎
These fields act as request modifiers, similar to the parameters on a programming language method invocation.
</p>
</div>

		<section id="section-5.1">
<h3 title="Controls">5.1. 制御~header</h3>

<p>
`制御~header@
とは、要請に対し 特定の取扱いを指令する，`要請~header$である：
◎
Controls are request header fields that direct specific handling of the request.
</p>

<div>
<ul><li>`Cache-Control$h
</li><li>`Expect$h
</li><li>`Host$h
</li><li>`Max-Forwards$h
</li><li>`Pragma$h
</li><li>`Range$h
</li><li>`TE$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | Cache-Control     | Section 5.2 of [RFC7234] |
   | Expect            | Section 5.1.1            |
   | Host              | Section 5.4 of [RFC7230] |
   | Max-Forwards      | Section 5.1.2            |
   | Pragma            | Section 5.4 of [RFC7234] |
   | Range             | Section 3.1 of [RFC7233] |
   | TE                | Section 4.3 of [RFC7230] |
   +-------------------+--------------------------+
</pre>

</div>

			<section id="section-5.1.1">
<h4>5.1.1. `Expect^h</h4>

<p>
要請~内の `Expect^h ~headerは、
`期待@
— ［
当の要請を適正に取扱うために，~serverにより~supportされる必要がある
］ような，一定の挙動の集合 —
を指示する。
この仕様で定義される，そのような唯一の`期待$は、 "`100-continue^c" である：
◎
The "Expect" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request. The only such expectation defined by this specification is 100-continue.
</p>

<pre class="bnf">
`Expect@p
	= "100-continue"
</pre>

<p>
`Expect^h `~header値$は文字大小無視である。
◎
The Expect field-value is case-insensitive.
</p>

<p>
`Expect^h `~header値$に "`100-continue^c" 以外の値を受信した`~server$は、［
予期されない`期待$には応えられない
］ことを指示する， `417$st で応答してもヨイ。
◎
A server that receives an Expect field-value other than 100-continue MAY respond with a 417 (Expectation Failed) status code to indicate that the unexpected expectation cannot be met.
</p>

<p>
`~100cont 期待@
は、［
`~client$が，当の要請~内に（大概は巨大な）`~message本体$を送信しつつあり、
`request-line$p および各種~headerが，［
即時に成功をもたらすには足らない ／
~redirectする ／
~error応答になる
］かどうかについて，暫定的 `100$st 応答の受信-を望んでいる
］ことを，`受信者$に伝える。
これにより、~clientは，事前に［
~message本体を送信するに価するかどうかの指示
］があるまで待機できるようになり、~message本体が巨大0なときや,
~errorになる見込みが高いと~clientが見越すとき（例：以前に検証yされた認証用の`資格証$なしに，初回に状態変更~methodを送信するとき）に，効率を改善できる。
◎
A 100-continue expectation informs recipients that the client is about to send a (presumably large) message body in this request and wishes to receive a 100 (Continue) interim response if the request-line and header fields are not sufficient to cause an immediate success, redirect, or error response. This allows the client to wait for an indication that it is worthwhile to send the message body before actually doing so, which can improve efficiency when the message body is huge or when the client anticipates that an error is likely (e.g., when sending a state-changing method, for the first time, without previously verified authentication credentials).
</p>

<div class="example">
<p>
例えば，次で始まる要請により：
◎
For example, a request that begins with
</p>

<pre class="lang-http">
PUT /somewhere/fun HTTP/1.1
Host: origin.example.com
Content-Type: video/h264
Content-Length: 1234567890987
Expect: 100-continue
</pre>

</div>

<p>
`生成元~server$は、［
`~client$が，不必要な~data転送で~pipeを埋め~~始める
］前に，［
`401$st や `405$st などの~error~message
］で即時に応答できるようになる。
◎
allows the origin server to immediately respond with an error message, such as 401 (Unauthorized) or 405 (Method Not Allowed), before the client starts filling the pipes with an unnecessary data transfer.
</p>

<p>
`~client$に課される要件は：
◎
Requirements for clients:
</p>

<ul>
	<li>
`~message本体$を内包しない要請~内に
`~100cont 期待$を`生成し$てはナラナイ。
◎
• A client MUST NOT generate a 100-continue expectation in a request that does not include a message body.
</li>
	<li>
要請の`~message本体$を送信する前に， `100$st 応答を待機するつもりがあるときは、`~100cont 期待$を包含する `Expect^h ~headerを送信しなければナラナイ。
◎
• A client that will wait for a 100 (Continue) response before sending the request message body MUST send an Expect header field containing a 100-continue expectation.
</li>
	<li>
`~100cont 期待$を送信してから，特定の長さの時間 待機することは、要求されない
— 応答がまだ受信されないうちに，`~message本体$の送信を続行してもヨイ。
更には、`100$st 応答は，~HTTP10媒介者を通しては送信され得ないので、~message本体の送信~前に，不定~期間 待機するベキでない。
◎
• A client that sends a 100-continue expectation is not required to wait for any specific length of time; such a client MAY proceed to send the message body even if it has not yet received a response. Furthermore, since 100 (Continue) responses cannot be sent through an HTTP/1.0 intermediary, such a client SHOULD NOT wait for an indefinite period before sending the message body.
</li>
	<li>
`~100cont 期待$を包含する要請に対する応答~内に， `417$stを受信したときは、その要請を，~100cont 期待を除いた上で，繰返すベキである
— `417$st0 応答は、単に［
応答の`連鎖$が期待を~supportしていない（例：~HTTP10~serverを通して渡されるとき）
］ことを指示するので。
◎
• A client that receives a 417 (Expectation Failed) status code in response to a request containing a 100-continue expectation SHOULD repeat that request without a 100-continue expectation, since the 417 response merely indicates that the response chain does not support expectations (e.g., it passes through an HTTP/1.0 server).
</li>
</ul>

<p>
`~server$に課される要件は：
◎
Requirements for servers:
</p>

<ul>
	<li>
~HTTP10要請~内に受信された`~100cont 期待$は、無視しなければナラナイ。
◎
• A server that receives a 100-continue expectation in an HTTP/1.0 request MUST ignore that expectation.
</li>
	<li>
［
対応する要請の`~message本体$の一部をすでに受信している
］, または［
~frame法が，~message本体が無いことを指示している
］場合、`100$st 応答の送信を省略してもヨイ。
◎
• A server MAY omit sending a 100 (Continue) response if it has already received some or all of the message body for the corresponding request, or if the framing indicates that there is no message body.
</li>
	<li>
`100$st 応答を送信した後、`~message本体$を受信して処理したなら、接続が尚早に~closeされない限り，最終的には，最終~状態s~codeを送信しなければナラナイ。
◎
• A server that sends a 100 (Continue) response MUST ultimately send a final status code, once the message body is received and processed, unless the connection is closed prematurely.
</li>
	<li>
~message本体 全体を読取る前に，最終~状態s~codeで応答するときは、その応答~内にて，［
接続を~closeするのか, 読取りを継続するのか
］どちらを意図するか, および［
要請~messageを破棄するかどうか【！＊】
］について指示するベキである（`7230-6.6$rfcを見よ）。
◎
• A server that responds with a final status code before reading the entire message body SHOULD indicate in that response whether it intends to close the connection or continue reading and discarding the request message (see Section 6.6 of [RFC7230]).
</li>
</ul>

<p>
［
`生成元~server$／`~proxy$
］は、［
`~HTTP11$（以上の~versionの） `request-line$p, および
完全な`~header節$
］を受信したときに，それが［
`~100cont 期待$を包含していて，要請~message本体が後続することを指示している
］場合は：
◎
↓</p>

<ul>
	<li>
<p>
生成元~serverは、次のいずれかをしなければナラナイ：
◎
An origin server MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either＼
</p>

		<ul>
			<li>
［
`request-line$p と各~headerを精査するだけで，状態sを決定できる
］ならば、即時に 最終~状態s~codeを伴う応答を送信する。
◎
send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or＼
</li>
			<li>
`100$st 応答を送信して，~clientに要請の~message本体を送信してもらうよう奨励する
— この場合、この応答を送信する前に，~message本体を待機してはナラナイ。
◎
send an immediate 100 (Continue) response to encourage the client to send the request's message body. The origin server MUST NOT wait for the message body before sending the 100 (Continue) response.
</li>
		</ul>
	</li>
	<li>
<p>
~proxyは、次のいずれかをしなければナラナイ：
◎
A proxy MUST, upon receiving an HTTP/1.1 (or later) request-line and a complete header section that contains a 100-continue expectation and indicates a request message body will follow, either＼
</p>
		<ul>
			<li>
［
`request-line$p と各~headerを精査するだけで，状態sを決定できる
］ならば、即時に 最終~状態s~codeを伴う応答を送信する。
◎
send an immediate response with a final status code, if that status can be determined by examining just the request-line and header fields, or＼
</li>
			<li>
<p >
次の`内方$~serverへ［
対応する `request-line$p と~header節を送信する
］ことにより、`生成元~server$へ向けて，その要請の回送を始める。
◎
begin forwarding the request toward the origin server by sending a corresponding request-line and header section to the next inbound server.＼
</p>

<p >
［
次の内方~serverが~HTTP10のみを~supportする
］ことを（環境設定または過去のやりとりから）予見できるならば、~clientに~message本体を送信し始めてもらうよう，即時に `100$st 応答を`生成し$てもヨイ。
◎
If the proxy believes (from configuration or past interaction) that the next inbound server only supports HTTP/1.0, the proxy MAY generate an immediate 100 (Continue) response to encourage the client to begin sending the message body.
</p>
			</li>
		</ul>
	</li>
</ul>

<p class="note">注記：
`Expect^h ~headerは、
~~元々の~HTTP11`2068$Rが公表された後に，［
暫定的 `100$st 応答を要請する手段
］と［
解することが要求される拡張を指示するための一般的な仕組み
］の両者として追加された。
しかしながら，この拡張の仕組みは、未だ~clientたちから利用されておらず，また
その要件は，多くの~serverにて実装されていないため、拡張の仕組みの具現化は，無用と化している。
~100cont の定義とその処理を単純~化するため、この仕様は，その拡張の仕組みを除去した。
◎
Note: The Expect header field was added after the original publication of HTTP/1.1 [RFC2068] as both the means to request an interim 100 (Continue) response and the general mechanism for indicating must-understand extensions. However, the extension mechanism has not been used by clients and the must-understand requirements have not been implemented by many servers, rendering the extension mechanism useless. This specification has removed the extension mechanism in order to simplify the definition and processing of 100-continue.
</p>

			</section>
			<section id="section-5.1.2">
<h4>5.1.2. `Max-Forwards^h</h4>

<p>
`Max-Forwards^h ~headerは、`要請~method$［
`TRACE$m, `OPTIONS$m
］と伴に，［
要請が~proxyにより回送される回数
］を制限する仕組みを供する。
これは、`~client$が，`連鎖$の途上で［
失敗する／~loopする
］ように出現する要請を~traceしようと試みるときに、有用になり得る。
◎
The "Max-Forwards" header field provides a mechanism with the TRACE (Section 4.3.8) and OPTIONS (Section 4.3.7) request methods to limit the number of times that the request is forwarded by proxies. This can be useful when the client is attempting to trace a request that appears to be failing or looping mid-chain.
</p>

<pre class="bnf">
`Max-Forwards@p
	= 1*DIGIT
</pre>

<p>
`Max-Forwards^h は、［
当の要請~messageを回送できる残りの回数
］を指示する~decimal整数を値にとる。
◎
The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.
</p>

<div class="p">

<p>
各 `媒介者$は、
`Max-Forwards^h ~headerを包含している［
`TRACE$m ／ `OPTIONS$m
］要請を受信したときは、要請を回送するに先立って，その値 `N^var を検査して更新しなければナラナイ。
`媒介者$は、 `N^var に応じて：
◎
Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field MUST check and update its value prior to forwarding the request.＼
</p>

<ul class="switch">
	<li>
`N^var ~EQ 0 の場合
⇒
要請を回送してはナラナイ
— 代わりに、`最終~受信者$として応答しなければナラナイ。
◎
If the received value is zero (0), the intermediary MUST NOT forward the request; instead, the intermediary MUST respond as the final recipient.＼
</li>
	<li>
他の場合（ `N^var ≥ 1 ）
⇒
回送する~message内に［
`~header値$が次のうちの最小に更新された `Max-Forwards^h ~header
］を`生成し$なければナラナイ
⇒＃
`N^var − 1,
受信者が `Max-Forwards^h 用に~supportする最大~値
◎
If the received Max-Forwards value is greater than zero, the intermediary MUST generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of a) the received value decremented by one (1) or b) the recipient's maximum supported value for Max-Forwards.
</li>
</ul>

</div>

<p>
`受信者$は、［
他の要請~methodにて受信された `Max-Forwards^h ~header
］については，無視してもヨイ。
◎
A recipient MAY ignore a Max-Forwards header field received with any other request methods.
</p>

			</section>
		</section>
		<section id="section-5.2">
<h3 title="Conditionals">5.2. 条件付き~header</h3>

<p>
下に挙げる~HTTP`条件付き要請~header$により、`~client$は，`~target資源$の状態に対する
`事前条件@
— 偽に評価されたときには，［
~method意味論に対応する動作
］が適用されない†ようにする条件 —
を設置できるようになる。
この仕様で定義される各種 事前条件は、［
先立つ［
~target資源の`表現$
］から得された`検証子$の集合
］と, ［
`選定された表現$用の，それらの検証子の現在の状態
］との比較からなる。
よって，これらの事前条件は、~target資源の状態が［
~clientに既知である，所与の状態
］から変化したかどうかを，評価する。
そのような評価の効果は、`7232-5$rfcにて定義されるように，［
~method意味論と, `条件付き$の選択
］に依存する。
◎
The HTTP conditional request header fields [RFC7232] allow a client to place a precondition on the state of the target resource, so that the action corresponding to the method semantics will not be applied if the precondition evaluates to false. Each precondition defined by this specification consists of a comparison between a set of validators obtained from prior representations of the target resource to the current state of validators for the selected representation (Section 7.2). Hence, these preconditions evaluate whether the state of the target resource has changed since a given state known by the client. The effect of such an evaluation depends on the method semantics and choice of conditional, as defined in Section 5 of [RFC7232].
</p>

<p class="trans-note">【†
`If-Range^h については、適用-対象が（~method意味論に直に対応する動作ではなく） `Range$h ~headerになる点で，他の条件付き~headerと異なる。
】</p>

<div>
<ul><li>`If-Match$h
</li><li>`If-None-Match$h
</li><li>`If-Modified-Since$h
</li><li>`If-Unmodified-Since$h
</li><li>`If-Range$h†
</li></ul>

<pre lang="en" class="_en">
   +---------------------+--------------------------+
   | Header Field Name   | Defined in...            |
   +---------------------+--------------------------+
   | If-Match            | Section 3.1 of [RFC7232] |
   | If-None-Match       | Section 3.2 of [RFC7232] |
   | If-Modified-Since   | Section 3.3 of [RFC7232] |
   | If-Unmodified-Since | Section 3.4 of [RFC7232] |
   | If-Range            | Section 3.2 of [RFC7233] |
   +---------------------+--------------------------+
</pre>

</div>

		</section>
		<section id="section-5.3">
<h3 title="Content Negotiation">5.3. 内容~折衝</h3>

<div class="p">

<p>
次に挙げる`要請~header$が、［
応答~内容の`~proactive折衝$
］に参加するために，`~UA$により送信される：
</p>

<ul><li>`Accept$h
</li><li>`Accept-Charset$h
</li><li>`Accept-Encoding$h
</li><li>`Accept-Language$h
</li></ul>

<p>
これらの~header内に送信される選好は、次のものを含め，応答~内のどの内容にも適用される：
</p>

<ul>
	<li>
`~target資源$の`表現$
</li>
	<li>
~errorや処理~状態sの`表現$
</li>
	<li>
~protocolの中に出現し得る，諸々の~text文字列。
</li>
</ul>
◎
The following request header fields are sent by a user agent to engage in proactive negotiation of the response content, as defined in Section 3.4.1. The preferences sent in these fields apply to any content in the response, including representations of the target resource, representations of error or processing status, and potentially even the miscellaneous text strings that might appear within the protocol.
</div>

<pre lang="en" class="_en">
   +-------------------+---------------+
   | Header Field Name | Defined in... |
   +-------------------+---------------+
   | Accept            | Section 5.3.2 |
   | Accept-Charset    | Section 5.3.3 |
   | Accept-Encoding   | Section 5.3.4 |
   | Accept-Language   | Section 5.3.5 |
   +-------------------+---------------+
</pre>

			<section id="section-5.3.1">
<h4 title="Quality Values">5.3.1. 品質~値</h4>

<p>
［
`~proactive折衝$用の`要請~header$
］の多くは、［
相対的な選好の “重み” を，結付けられる内容の種類にアテガう
］ために，［
`q$c と命名される（文字大小無視な）共通な~parameter
］を利用する。
この重みは、同じ~parameter名が，~server環境設定の中で［
資源~用に選定され得る様々な`表現$の，相対的な品質の重み
］をアテガうために 利用されることが多いため、
`品質~値^dfn
（ あるいは “qvalue” ）と呼ばれる。
◎
Many of the request header fields for proactive negotiation use a common parameter, named "q" (case-insensitive), to assign a relative "weight" to the preference for that associated kind of content. This weight is referred to as a "quality value" (or "qvalue") because the same parameter name is often used within server configurations to assign a weight to the relative quality of the various representations that can be selected for a resource.
</p>

<p>
重みは、範囲 0 〜 1 の実数に正規化される
— ここで，［
値 0.001 は最も選好されず，
値 1 は最も選好され，
値 0 は “受容-可能でない”
］ことを意味する。
`q$c ~parameterが無い場合の
`既定の重み@
は 1 である。
◎
The weight is normalized to a real number in the range 0 through 1, where 0.001 is the least preferred and 1 is the most preferred; a value of 0 means "not acceptable". If no "q" parameter is present, the default weight is 1.
</p>

<pre class="bnf">
`weight@p
	= `OWS$p ";" `OWS$p "`q@c=" `qvalue$p
`qvalue@p
	= ( "0" [ "." 0*3DIGIT ] )
	/ ( "1" [ "." 0*3("0") ] )
</pre>

<p>
`送信者$が，小数点の後に`生成する$品質値の桁~数は、 3 以下でなければナラナイ。
これらの値による利用者~環境設定も，同じやり方で制限される~OUGHT。
◎
A sender of qvalue MUST NOT generate more than three digits after the decimal point. User configuration of these values ought to be limited in the same fashion.
</p>

			</section>
			<section id="section-5.3.2">
<h4>5.3.2. `Accept^h</h4>

<p>
`~UA$は、［
応答の`~MIME型$として受容-可能なもの
］を指定するために，
`Accept^h ~headerを利用できる。
`Accept^h ~headerは、［
要請が，欲される型からなる小さな集合に特に制限される
］ことを指示するときに利用できる
— 例えば，~in-line画像に対する要請など。
◎
The "Accept" header field can be used by user agents to specify response media types that are acceptable. Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
</p>

<pre class="bnf">
`Accept@p
	= #( `media-range$p [ `accept-params$p ] )

`media-range@p
	= ( "*/*"
		/ ( `type$p "/" "*" )
		/ ( `type$p "/" `subtype$p )
	  ) *( `OWS$p ";" `OWS$p `parameter$p )
`accept-params@p
	= `weight$p *( `accept-ext$p )
`accept-ext@p
	= `OWS$p ";" `OWS$p `token$p [ "=" ( `token$p / `quoted-string$p ) ]
</pre>

<p>
`media-range$p における文字~asterisk "`*^c" は、`~MIME型$をある範囲に~group化するために利用される
⇒＃
"`*/*^c" は，すべての~MIME型を指示する／
"`type^var`/*^c" は， `type^var 型を成すすべての下位型を指示する
◎
The asterisk "*" character is used to group media types into ranges, with "*/*" indicating all media types and "type/*" indicating all subtypes of that type.＼
</p>

<p>
`media-range$p には、［
その範囲の~MIME型に適用-可能な`~MIME型~parameter$
］も内包できる。
◎
The media-range can include media type parameters that are applicable to that range.
</p>

<div class="p">
<p>
各 `media-range$p には、順に，次のものが後続し得る：
◎
Each media-range might be followed by＼
</p>

<ol>
	<li>
0 個以上の，
適用-可能な`~MIME型~parameter$（ `parameter$p ）（例： "`charset^c" ）
◎
zero or more applicable media type parameters (e.g., charset),＼
</li>
	<li>
0 〜 1 個の，（ `weight$p を成す） `q$c ~parameter
— 相対的な重み（`品質~値$）を指示する
◎
an optional "q" parameter for indicating a relative weight (Section 5.3.1), and then＼
</li>
	<li>
0 個以上の，拡張~parameter（ `accept-ext$p ）
◎
zero or more extension parameters.＼
</li>
</ol>

<p>
`q$c ~parameterは，その前後の~parameter集合の分離子として~~働くので、拡張（ `accept-ext$p ）が在るならば，必要yである。
◎
The "q" parameter is necessary if any extensions (accept-ext) are present, since it acts as a separator between the two parameter sets.
</p>
</div>

<p class="note">注記：
［
`Accept^h の拡張~parameterから`~MIME型~parameter$を分離する，~parameter名 "`q^c"
］の利用は、歴史的な実施に因る。
これにより， `media-range$p においては［
"`q^c" と命名される`~MIME型~parameter$
］は利用できなくなるが、［
~IANA~MIME型~registryにおける `q$c ~parameterの欠如
］, および［
`Accept^h 内での`~MIME型~parameter$の稀な利用e
］の下では、そのような出来事は，まずないと予見されている。
将来の~MIME型においては、"`q^c" と命名されるどのような~parameterも登録しないことが奨励される。
◎
Note: Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters in Accept. Future media types are discouraged from registering any parameter named "q".
</p>

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

<pre class="lang-http">
Accept: audio/*; q=0.2, audio/basic
</pre>

<p>
これは、次の様に解釈される
⇒
“ `audio/basic^c を選好しますが、無いなら［
品質を 80% ~~落とした上で，最良に可用な `audio^c 型
］があれば，それを送信してください。”
◎
is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% markdown in quality".
</p>
</div>

<p>
`Accept^h ~headerを伴わない要請は、［
`~UA$が、どの`~MIME型$も，応答~内に受容することになる
］ことを含意する。
この~headerが要請~内に在るが，［
応答~用に可用な どの表現の~MIME型も，受容-可能として~listされていない
］場合、`生成元~server$は，［
`406$st 応答を送信して，この~headerを尊守する
］, あるいは［
応答を，`内容~折衝$の~subjectではないかのように扱って，この~headerを無視rする
］ことができる。
◎
A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
</p>

<div class="example">
<p>
より込み入った例：
◎
A more elaborate example is
</p>

<pre class="lang-http">
Accept: text/plain; q=0.5, text/html, text/x-dvi; q=0.8, text/x-c
</pre>

<p>
これは、くだけて言えば，次の様に解釈されるであろう
⇒
“`~MIME型$ `text/html^c と `text/x-c^c を等しく選好しますが、無ければ `text/x-dvi^c による表現を, それも無ければ `text/plain^c による表現を送信してください”
◎
Verbally, this would be interpreted as "text/html and text/x-c are the equally preferred media types, but if they do not exist, then send the text/x-dvi representation, and if that does not exist, send the text/plain representation".
</p>

</div>

<p>
`media-range$p は、より特定な［
`media-range$p ／ `~MIME型$
］で上書きできる。
所与の型に，複数の `media-range$p が適用されている場合、最も特定な参照が優先される。
◎
Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies to a given type, the most specific reference has precedence.＼
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
Accept: text/*, text/plain, text/plain;format=flowed, */*
</pre>

<p>
の優先順は、次になる：
◎
have the following precedence:
</p>

<ol ><li>`text/plain;format=flowed^c
</li><li>`text/plain^c
</li><li>`text/*^c
</li><li>`*/*^c
</li></ol>
</div>

<p>
所与の型に結付けられる`~MIME型$ 品質~係数は、［
型に合致する，最も優先される `media-range$p
］を見出すことにより決定される。
◎
The media type quality factor associated with a given type is determined by finding the media range with the highest precedence that matches the type.＼
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, text/html;level=2;q=0.4, */*;q=0.5
</pre>

<p>
に対しては、次に挙げる値が結付けられる：
◎
would cause the following values to be associated:
</p>

<div>
<table><thead>
<tr><td>~MIME型
<td>`品質~値$
<tbody>

<tr><td>`text/html;level=1^c
<td>`1^c

<tr><td>`text/html^c
<td>`0.7^c

<tr><td>`text/plain^c
<td>`0.3^c

<tr><td>`image/jpeg^c
<td>`0.5^c

<tr><td>`text/html;level=2^c
<td>`0.4^c

<tr><td>`text/html;level=3^c
<td>`0.7^c
</table>

<pre lang="en" class="_en">
   +-------------------+---------------+
   | Media Type        | Quality Value |
   +-------------------+---------------+
   | text/html;level=1 | 1             |
   | text/html         | 0.7           |
   | text/plain        | 0.3           |
   | image/jpeg        | 0.5           |
   | text/html;level=2 | 0.4           |
   | text/html;level=3 | 0.7           |
   +-------------------+---------------+
</pre>
</div>
</div>

<p class="note">注記：
~UAは、一定~範囲の~MIME型~用に，`品質~値$の既定の集合を供し得る。
しかしながら，~UAが［
他の具現化~agentとヤリトリし得ない閉じた~system
］でない限り、この既定の集合は，利用者により環境設定できる~OUGHT。
◎
Note: A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent is a closed system that cannot interact with other rendering agents, this default set ought to be configurable by the user.
</p>

			</section>
			<section id="section-5.3.3">
<h4>5.3.3. `Accept-Charset^h</h4>

<p>
`~UA$は、 `Accept-Charset^h ~headerを送信して，［
~textな応答~内容として受容-可能な，`~charset$
］を指示できる。
この~headerにより、~UAは，［
より［
包括的な／特殊用途の
］~charsetを解する能力を備える
］ならば，その能力を［
それらの~charsetで情報を表現する能力を備えている生成元~server
］へ通達できるようになる。
◎
The "Accept-Charset" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.
</p>

<pre class="bnf">
`Accept-Charset@p
	= 1#( ( `charset$p / "*" ) [ `weight$p ] )
</pre>

<p>
各~charset名は、`3.1.1.2$secにて定義される。
`~UA$は、各~charsetに［
利用者の相対的~選好を指示する`品質~値$
］を結付けてヨイ。
◎
Charset names are defined in Section 3.1.1.2. A user agent MAY associate a quality value with each charset to indicate the user's relative preference for that charset, as defined in Section 5.3.1.＼
</p>

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

<pre class="lang-http">
Accept-Charset: iso-8859-5, unicode-1-1;q=0.8
</pre>

</div>

<div class="p">

<p>
特別な値 "`*^c" は：
◎
The special value "*",＼
</p>

<ul>
	<li>
`Accept-Charset^h ~header内に在る場合、
`Accept-Charset^h ~header内に挙げられていない，どの`~charset$にも合致する。
◎
if present in the Accept-Charset field, matches every charset that is not mentioned elsewhere in the Accept-Charset field.＼
</li>
	<li>
無い場合、~header内に明示的に挙られていない どの`~charset$も，`~client$にとっては “受容-可能でない” と見なされる。
◎
If no "*" is present in an Accept-Charset field, then any charsets not explicitly mentioned in the field are considered "not acceptable" to the client.
</li>
</ul>
</div>

<p>
要請に `Accept-Charset^h ~headerが伴われないことは、［
`~UA$が，応答~内に どの`~charset$も受容する
］ことを含意する。
ほとんどの一般用~UAは、特に環境設定されない限り，
`Accept-Charset^h を送信しない
— ~serverにとっては，［
~supportされる`~charset$の詳細な~list
］があれば、~UAの要請の特性から，各個人を識別することがより容易になる（`9.7$sec）ので。
◎
A request without any Accept-Charset header field implies that the user agent will accept any charset in response. Most general-purpose user agents do not send Accept-Charset, unless specifically configured to do so, because a detailed list of supported charsets makes it easier for a server to identify an individual by virtue of the user agent's request characteristics (Section 9.7).
</p>

<p>
［
要請~内に `Accept-Charset^h ~headerが在る
］かつ［
応答に可用な どの`表現$も，受容-可能として~listされた`~charset$を持たない
］場合、`生成元~server$は，［
`406$st 応答を送信して，その~headerを尊守する
］か, あるいは［
資源を`内容~折衝$の~subjectではないかのように扱って，その~headerを無視rする
］こともできる。
◎
If an Accept-Charset header field is present in a request and none of the available representations for the response has a charset that is listed as acceptable, the origin server can either honor the header field, by sending a 406 (Not Acceptable) response, or disregard the header field by treating the resource as if it is not subject to content negotiation.
</p>

			</section>
			<section id="section-5.3.4">
<h4>5.3.4. `Accept-Encoding^h</h4>

<p>
`~UA$は、 `Accept-Encoding^h ~headerを利用して，［
応答にて受容-可能な，`内容~符号法$
］を指示できる。
"`identity@c"
~tokenは、符号化が選好されないときに通信するための，
“符号化しない” の同義語として利用される。
◎
The "Accept-Encoding" header field can be used by user agents to indicate what response content-codings (Section 3.1.2.1) are acceptable in the response. An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.
</p>

<pre class="bnf">
`Accept-Encoding@p
	= #( `codings$p [ `weight$p ] )
`codings@p
	= `content-coding$p
	/ "`identity$c"
	/ "*"
</pre>

<p>
各 符号法~値（ `codings$p ）には、［
その符号化法に結付けられる選好~度を表現する，`品質~値$
］も与えられてヨイ。
`Accept-Encoding^h ~header内の記号~asterisk "`*^c"
は、［
その~header内に明示的に~listされていない
］ような，可用な どの`内容~符号法$にも，合致する。†a
◎
Each codings value MAY be given an associated quality value representing the preference for that encoding, as defined in Section 5.3.1. The asterisk "*" symbol in an Accept-Encoding field matches any available content-coding not explicitly listed in the header field.
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
Accept-Encoding: compress, gzip
Accept-Encoding:
Accept-Encoding: *
Accept-Encoding: compress;q=0.5, gzip;q=1.0
Accept-Encoding: gzip;q=1.0, identity; q=0.5, *;q=0
</pre>

</div>

<p>
`Accept-Encoding^h ~headerを伴わない要請は、［
`~UA$が`内容~符号法$に関する選好を持たない
］ことを含意する。
これにより，［
`~server$は，応答~内に 任意の`内容~符号法$を利用できる
］ようになるが、［
~UAが，どの符号化法も正しく処理できる
］ことを含意するわけではない。
◎
A request without an Accept-Encoding header field implies that the user agent has no preferences regarding content-codings. Although this allows the server to use any content-coding in a response, it does not imply that the user agent will be able to correctly process all encodings.
</p>

<p>
`~server$は、次の規則を利用して，［
所与の`表現$用の`内容~符号法$
］が
【~UAにとって】
受容-可能になるかどうかを~testする：
◎
A server tests whether a content-coding for a given representation is acceptable using these rules:
</p>

<ol>
	<li>
要請~内に `Accept-Encoding^h ~headerが無い場合：
`~UA$は，どの`内容~符号法$も受容-可能である、と見なされる。†b
◎
1. If no Accept-Encoding field is in the request, any content-coding is considered acceptable by the user agent.
</li>
	<li>
<p>
`表現$が`内容~符号法$を持たない場合、
`Accept-Encoding^h ~header値が次のいずれかを充足する場合を除き，既定で受容-可能である†c：
◎
2. If the representation has no content-coding, then it is acceptable by default unless specifically excluded by the Accept-Encoding field stating either＼
</p>

		<ul>
			<li>
"`identity;q=0^c" を伴う。
◎
"identity;q=0" or＼
</li>
			<li>
"`*;q=0^c" を伴う, かつ［
明示的な品質値を伴う `identity^c
］は伴わない。
◎
"*;q=0" without a more specific entry for "identity".
</li>
		</ul>

<p class="trans-note">【
"`identity$c" も内容~符号法の一種（恒等変換）と見なした上で、表現が内容~符号法を持たないことを，
“表現は内容~符号法 "`identity^c" を持つ”
と解釈すれば、この規則は，次項による規則の特別な場合と見なせる。
】</p>

	</li>
	<li>
`表現$の`内容~符号法$が，［
`Accept-Encoding^h ~header内に~listされた`内容~符号法$
］のうち，いずれかである場合：
それに`品質値$ 0 が付随していない限り，受容-可能である。
（`5.3.1$secの定義により，品質値 0 は “受容-可能でない”ことを意味する）。†d
◎
3. If the representation's content-coding is one of the content-codings listed in the Accept-Encoding field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in Section 5.3.1, a qvalue of 0 means "not acceptable".)
</li>
	<li>
複数の `内容~符号法$が受容-可能である場合、［
最も高い非 0 `品質値$を伴う受容-可能な`内容~符号法$
］が選好される。†e
◎
4. If multiple content-codings are acceptable, then the acceptable content-coding with the highest non-zero qvalue is preferred.
</li>
</ol>

<div class="p">
<p>
［
`結合-$後の`~header値$が，空である `Accept-Encoding^h ~header
］は、［
`~UA$が，応答~内にどの`内容~符号法$も~~望まないこと
］を含意する。†f
◎
An Accept-Encoding header field with a combined field-value that is empty implies that the user agent does not want any content-coding in response.＼
</p>
<p>
`生成元~server$は、［
要請~内に `Accept-Encoding^h ~headerが在る
］かつ［
応答に可用な どの`表現$も
受容-可能として~listされた`内容~符号法$を持たない
］場合には，`内容~符号法$を伴わない応答を送信するベキである。†g
◎
If an Accept-Encoding header field is present in a request and none of the available representations for the response have a content-coding that is listed as acceptable, the origin server SHOULD send a response without any content-coding.
</p>
</div>

<p class="note">注記：
ほとんどの~HTTP10~appは、`内容~符号法$に結付けられた`品質値$を［
認識しない／順守しない
］。
これは、`品質値$が，おそらく働かず，［
`x-gzip^c や `x-compress^c
］との併用も許可されないことを意味する。
◎
Note: Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues might not work and are not permitted with x-gzip or x-compress.
</p>

<div class="trans-note">

<p>【
~serverが，選好される内容~符号法を選定する手続きは、以下のように定式化できるであろう：
】</p>

<p>
尚，ここでは、 "`identity^c" も内容~符号法の一種と見なす。
また、以下に現れる “（†…）” は，上のどの規則が反映されているかを表す。
</p>

<p>
まず、（表現に可用かどうかに関わらず，）~UAにとって受容-可能と見なされる内容~符号法の集合 `S^var, および その各 品質値を~~求める：
</p>

<ol>
	<li>
<p>
`V^var ~LET （`結合-$後の） `Accept-Encoding^h `~header値$
— ただし、
`Accept-Encoding^h が与えられていない場合の `V^var は、 "`*^c" と見なす（†b）。
</p>

<p>
上の規則には、
`V^var の中に同じ内容~符号法（ あるいは "`*^c" ）が複数 現れる場合の挙動が，規定されていない
— 例えば、次が考えられる：
</p>
		<ul>
			<li>
何らかの基準に従って，それらのうちの一つに絞り、残りは `V^var から除去する。
</li>
			<li>
それらをすべて `V^var から除去する。
</li>
			<li>
その他、~headerが与えられなかったときと同等に扱う，構文~errorとして扱う，等々。
</li>
		</ul>

<p>
以降、この種の競合は，上に示したような何らかの挙動により解消されていると見なす。
</p>

	</li>
	<li>
`V^var の中の，品質値を伴わない［
内容~符号法, および "`*^c"
］の品質値は、 1 と見なす（`既定の重み$）。
</li>
	<li>
`Q^var ~LET ［
`V^var の中に "`*^c" が現れるならば，その品質値 ／
他の場合は 0
］（†c, †d, †f）。
</li>
	<li>
`V^var に挙げられていない，どの内容~符号法の品質値も、 `Q^var と見なす（†a）。
</li>
	<li>
`S^var は、あらゆる内容~符号法の集合（ "`identity$c" も含む, 無限集合）の中で［
品質値が 0 でない内容~符号法
］すべてからなる集合である（†a, †c, †d）。
</li>
</ol>

<p>
応答に最も選好される内容~符号法は、
</p>

<ul>
	<li>
`T^var ~LET 応答に可用なすべての表現の，内容~符号法の集合††
</li>
	<li>
`R^var ~LET `S^var, `T^var の積集合
</li>
</ul>

<p>
とするとき：
</p>

<ul>
	<li>
`R^var が空集合ならば（どれも選好されないが） `identity^c と見なすべきである（†c, †g）（†f）††
</li>
	<li>
他の場合、 `R^var の中で，品質値が最~大なものたち（†e）。
</li>
</ul>

<p>††
通常は， `identity$c は常に `T^var に含まれると考えられるが、明言されていない
— ~serverが強制的に他の内容~符号法のみに限定することも，あるかもしれない。
</p>

</div>

			</section>
			<section id="section-5.3.5">
<h4>5.3.5. `Accept-Language^h</h4>

<p>
`~UA$は、 `Accept-Language^h ~headerを利用して［
応答において選好される自然言語（`言語~tag$）の集合
］を指示できる。
【！言語~tagは、3.1.3.1にて定義される。】
◎
The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the response. Language tags are defined in Section 3.1.3.1.
</p>

<pre class="bnf">
`Accept-Language@p
	= 1#( `language-range$p [ `weight$p ] )
`language-range@p
	= &lt;language-range, `4647-2.1$rfc&gt;
</pre>

【！Errata ID: 4734 Rejected】

<p>
各 `language-range$p には、［
それが指定する言語~範囲に結付けられる，利用者の選好~度を表現する，`品質~値$
］を与えれる。
◎
Each language-range can be given an associated quality value representing an estimate of the user's preference for the languages specified by that range, as defined in Section 5.3.1.＼
</p>

<div class="example">
<p>
例えば：
◎
For example,
</p>

<pre class="lang-http">
Accept-Language: da, en-gb;q=0.8, en;q=0.7
</pre>

<p>
は、次を意味することになる：
“~Danishを選好しますが，英国~英語 や他~種の英語も受容します”。
◎
would mean: "I prefer Danish, but will accept British English and other types of English".
</p>

</div>

<div class="p">
<p>
`Accept-Language^h ~headerを伴わない要請は、［
`~UA$は，応答~内にどの言語も受容する
］ことを含意する。
◎
A request without any Accept-Language header field implies that the user agent will accept any language in response.＼
</p>

<p>
［
この~headerが要請~内に在る
］, かつ［
応答に可用な どの`表現$も，合致する`言語~tag$を持たない
］場合、`生成元~server$は，次のいずれかを行える：
◎
If the header field is present in a request and none of the available representations for the response have a matching language tag, the origin server can either＼
</p>

<ul>
	<li>
要請は`内容~折衝$の~subjectではないかのように 応答を扱って，この~headerを無視rする。
◎
disregard the header field by treating the response as if it is not subject to content negotiation or＼
</li>
	<li>
`406$st 応答を送信して，この~headerを尊守する。
◎
honor the header field by sending a 406 (Not Acceptable) response.＼
</li>
</ul>

<p>
しかしながら，後者は奨励されない
— そうすると，利用者は、例えば，翻訳~softwareでは利用し得るような内容にも~accessできなくなるので。
◎
However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able to use (with translation software, for example).
</p>

</div>

<p>
一部の受信者は、特に，`品質~値$が等しくアテガわれた~tagに対し，［
`言語~tag$が~listされる順序を，優先度~順の指示として扱う
］ことに注意（どの~tagの品質値も 1 でなくなる）。
しかしながら、この挙動には依拠できない。
多くの~UAは、一貫性のため, および 相互運用能を最大化するため、各`言語~tag$に一意な`品質~値$をアテガった上で，それらを品質の降順で~listする。
言語~優先度~listについての追加的な論点は、`4647-2.3$rfcに。
◎
Note that some recipients treat the order in which language tags are listed as an indication of descending priority, particularly for tags that are assigned equal quality values (no value is the same as q=1). However, this behavior cannot be relied upon. For consistency and to maximize interoperability, many user agents assign each language tag a unique quality value while also listing them in order of decreasing quality. Additional discussion of language priority lists can be found in Section 2.3 of [RFC4647].
</p>

<p>
`4647-3$rfcは、数種の照合スキームを，照合~用に定義している。
実装は、自身の要件に最も適切な照合スキームを提供できる。
"Basic Filtering" スキーム（ `4647-3.3.1$rfc ）は、以前に［
`2616-14.4$rfcにて，~HTTP用として定義された照合スキーム
］と一致する。
◎
For matching, Section 3 of [RFC4647] defines several matching schemes. Implementations can offer the most appropriate matching scheme for their requirements. The "Basic Filtering" scheme ([RFC4647], Section 3.3.1) is identical to the matching scheme that was previously defined for HTTP in Section 14.4 of [RFC2616].
</p>

<p>
毎~要請ごとに［
利用者の，完全な言語上の選好
］を伴う `Accept-Language^h ~headerを送信することは、利用者が期待する~privacyに反し得る（`9.7$sec）。
◎
It might be contrary to the privacy expectations of the user to send an Accept-Language header field with the complete linguistic preferences of the user in every request (Section 9.7).
</p>

<p>
言語の理解度は，個々の利用者に大きく依存するので、`~UA$は，［
利用者が，言語上の選好を（~UA自身の環境設定を通して, あるいは 利用者が制御できる~system設定による既定により）制御できる
］ようにする必要がある。
そのような制御を利用者に供さない`~UA$は、
`Accept-Language^h ~headerを送信してはナラナイ。
◎
Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic preference (either through configuration of the user agent itself or by defaulting to a user controllable system setting). A user agent that does not provide such control to the user MUST NOT send an Accept-Language header field.
</p>

<p class="note">注記：
`~UA$は、［
選好の設定~時に，利用者~向けの指導
］を供する~OUGHT
— 利用者が、上に述べた言語~照合の詳細~について，馴染んでいることは稀なので。
例えば，利用者は、［
"`en-gb^c" を選定すれば、英国~英語が可用でなくても，どの種類の英語~文書であれ~serveされるようになる
］ものと見做すかもしれない。
~UAは、そのような事例では，［
照合の挙動をより良くするために，~listに "`en^c" を追加する
］ことを示唆できる。
◎
Note: User agents ought to provide guidance to users when setting a preference, since users are rarely familiar with the details of language matching as described above. For example, users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. A user agent might suggest, in such a case, to add "en" to the list for better matching behavior.
</p>

			</section>
		</section>
		<section id="section-5.4">
<h3 title="Authentication Credentials">5.4. 認証用の資格証</h3>

<p>
`7235$Rにて定義されるように、認証用の`資格証$を運ばせるために，次の 2 つの~headerが利用される。
利用者~認証~用の様々な~customな仕組みが、この目的に
`Cookie$h ~header `6265$R
を利用することに注意。
◎
Two header fields are used for carrying authentication credentials, as defined in [RFC7235]. Note that various custom mechanisms for user authentication use the Cookie header field for this purpose, as defined in [RFC6265].
</p>

<div>
<ul><li>`Authorization$h
</li><li>`Proxy-Authorization$h
</li></ul>

<pre lang="en" class="_en">
   +---------------------+--------------------------+
   | Header Field Name   | Defined in...            |
   +---------------------+--------------------------+
   | Authorization       | Section 4.2 of [RFC7235] |
   | Proxy-Authorization | Section 4.4 of [RFC7235] |
   +---------------------+--------------------------+
</pre>

</div>

		</section>
		<section id="section-5.5">
<h3 title="Request Context">5.5. 要請の文脈</h3>

<p>
次の`要請~header$は、［
利用者, ~UA, 要請の背後にある資源
］についての情報も含め，要請の文脈について 追加的な情報を供する：
◎
The following request header fields provide additional information about the request context, including information about the user, user agent, and resource behind the request.
</p>

<div>
<ul><li>`From$h
</li><li>`Referer$h
</li><li>`User-Agent$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+---------------+
   | Header Field Name | Defined in... |
   +-------------------+---------------+
   | From              | Section 5.5.1 |
   | Referer           | Section 5.5.2 |
   | User-Agent        | Section 5.5.3 |
   +-------------------+---------------+
</pre>

</div>

			<section id="section-5.5.1">
<h4>5.5.1. `From^h</h4>

<p>
`From^h ~headerは、［
要請を~~発行する~UAを制御するヒト利用者
］の~Internet~email~addressを包含する。
~addressは、~machineから利用-可能な，
`5322-3.4$rfcにて定義される `mailbox^p になる~OUGHT：
◎
The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322]:
</p>

<pre class="bnf">
`From@p
	= `mailbox$p

`mailbox@p
	= &lt;mailbox, `5322-3.4$rfc&gt;
</pre>

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

<pre class="lang-http">
From: webmaster@example.org
</pre>

</div>

<p>
`From^h ~headerが非~robotic~UAにより送信されることは稀である。
`~UA$は、利用者により明示的に環境設定されない限り，
`From^h ~headerを送信するベキでない
— ［
利用者の~privacyへの関心や, それらの~siteの~security施策
］と競合するであろうから。
◎
The From header field is rarely sent by non-robotic user agents. A user agent SHOULD NOT send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests or their site's security policy.
</p>

<p>
~robotic~UAは、自身が［
過度の／求まれていない／妥当でない
］要請を送信しているときなど，［
~server上に問題が生じた場合に，~robotを稼働させている責務者と連絡をとれる
］ような，［
妥当な `From^h ~header
］を送信するベキである。
◎
A robotic user agent SHOULD send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on servers, such as if the robot is sending excessive, unwanted, or invalid requests.
</p>

<p>
`~server$は、 `From^h ~headerを［
~access制御や認証
］用に利用するベキでない
— ほとんどの受信者は、この~headerの値を公な情報であると見做すことになるので。
◎
A server SHOULD NOT use the From header field for access control or authentication, since most recipients will assume that the field value is public information.
</p>

			</section>
			<section id="section-5.5.2">
<h4>5.5.2. `Referer^h</h4>

<p>
`Referer^h ~headerにより、`~UA$は［
`~target~URI$を得した所の資源
］用に，`~URI$参照を指定できるようになる（すなわち， “referrer（~~参照元）” — ~header名の綴りは誤っているが）。
`~UA$は、 `Referer^h `~header値$を`生成する$際に，~URI参照に［
`fragment$p ／ `userinfo$p
］成分`3986$Rを内包してはナラナイ。
◎
The "Referer" [sic] header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the "referrer", though the field name is misspelled). A user agent MUST NOT include the fragment and userinfo components of the URI reference [RFC3986], if any, when generating the Referer field value.
</p>

<pre class="bnf">
`Referer@p
	= `absolute-URI$p
	/ `partial-URI$p
</pre>

<p>
`Referer^h ~headerにより、`~server$は，［
単純~解析, ~log取り, 最適化された~caching, 等々
］のために，他の資源へ戻れる~linkを生成できるようになる。
それはまた、保守~用に［
廃用にされた／誤入力された
］~linkを見出すことも可能にする。
一部の~serverは、 `Referer^h ~headerを，［
他~siteからの~link（いわゆる “deep linking” ）を否認したり,
CSRF （ cross-site request forgery ）を制約する
］ための手段として利用するが、すべての要請がそれを包含するわけではない。
◎
The Referer header field allows servers to generate back-links to other resources for simple analytics, logging, optimized caching, etc. It also allows obsolete or mistyped links to be found for maintenance. Some servers use the Referer header field as a means of denying links from other sites (so-called "deep linking") or restricting cross-site request forgery (CSRF), but not all requests contain it.
</p>

<div class="example">
<p>
例：
◎
Example:
</p>

<pre class="lang-http">
Referer: http://www.example.org/hypertext/Overview.html
</pre>

</div>

<p>
`~target~URI$が［
~URIを持たない~sourceから得されたもの
］である場合（例：利用者~keyboardからの入力, 利用者の~bookmark）、
`Referer^h ~headerを除外するか, または その値に "`about:blank^c" を送信しなければナラナイ。
◎
If the target URI was obtained from a source that does not have its own URI (e.g., input from the user keyboard, or an entry within the user's bookmarks/favorites), the user agent MUST either exclude the Referer field or send it with a value of "about:blank".
</p>

<p>
`Referer^h ~headerが［
要請の文脈や, 利用者の閲覧~履歴についての情報
］を露呈し得る場合、それは，［
参照元~資源の識別子が（~account名などの）個人-情報を露呈したり
］, あるいは［
資源が機密的と想定される（~firewallの背後や, ~secure化された~serviceの内部など）
］場合に，~privacy上の懸念になる。
ほとんどの一般用~UAは、［
参照元~資源が局所的な［
"file" ／ "data"
］`~URI$である
］ときには， `Referer^h ~headerを送信しない。
`~UA$は、［
参照元~pageが~secure~protocolで受信されていた
］場合には，~secure化されてない~HTTP要請~内に
`Referer^h ~headerを送信してはナラナイ。
追加的な~securityの考慮点については `9.4$secを見よ。
◎
The Referer field has the potential to reveal information about the request context or browsing history of the user, which is a privacy concern if the referring resource's identifier reveals personal information (such as an account name) or a resource that is supposed to be confidential (such as behind a firewall or internal to a secured service). Most general-purpose user agents do not send the Referer header field when the referring resource is a local "file" or "data" URI. A user agent MUST NOT send a Referer header field in an unsecured HTTP request if the referring page was received with a secure protocol. See Section 9.4 for additional security considerations.
</p>

<p>
一部の`媒介者$は，［
外向けの要請から `Referer^h ~headerを無差別に除去する
］ことが、既知である。
これは、 CSRF 攻撃に対する保護に干渉するような，~~望ましくない副作用を及ぼす
— それは、利用者にとり，はるかに有害になる。
`Referer^h 内への情報~開示を制限したいと望む［
`媒介者$／`~UA$拡張
］は、それらの変更を［
内部~domain名を `pseudonym$p に置換したり，
`query$p や`path$p 成分を切落す
］などの，特定の編集-に制約する~OUGHT。
`媒介者$は、［
~header値が，`要請~target$と同じ `scheme$p ＆ `host$p を共有する
］ときは， `Referer^h ~headerを改変したり削除するベキでない。
◎
Some intermediaries have been known to indiscriminately remove Referer header fields from outgoing requests. This has the unfortunate side effect of interfering with protection against CSRF attacks, which can be far more harmful to their users. Intermediaries and user agent extensions that wish to limit information disclosure in Referer ought to restrict their changes to specific edits, such as replacing internal domain names with pseudonyms or truncating the query and/or path components. An intermediary SHOULD NOT modify or delete the Referer header field when the field value shares the same scheme and host as the request target.
</p>

			</section>
			<section id="section-5.5.3">
<h4>5.5.3. `User-Agent^h</h4>

<div class="p">

<p>
`User-Agent^h ~headerは、［
要請を出生した`~UA$
］についての情報を包含する
— `~server$は、次のために，これを利用することが多い：
◎
The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers＼
</p>

<ul>
	<li>
報告された相互運用能の問題を絞り込むための補助。
◎
to help identify the scope of reported interoperability problems,＼
</li>
	<li>
特定0の~UA制限を避けるために，［
対処する／応答を誂える
］。
◎
to work around or tailor responses to avoid particular user agent limitations, and＼
</li>
	<li>
利用されている~browserや OS に関する解析。
◎
for analytics regarding browser or operating system use.＼
</li>
</ul>

<p>
`~UA$は、特に環境設定されていない限り，各~要請~内に `User-Agent^h ~headerを送信するベキである。
◎
A user agent SHOULD send a User-Agent field in each request unless specifically configured not to do so.
</p>
</div>

<pre class="bnf">
`User-Agent@p
	= `product$p *( `RWS$p ( `product$p / `comment$p ) )
</pre>

<p>
`User-Agent^h `~header値$は、 1 個~以上の［
`製品~識別子@
（ `product$p ）と,
後続する 0 個以上の `comment$p
］からなる。
それらは組で，［
~UA~software, および その有意な下位製品
］を識別する。
慣行により，製品~識別子は、~UA~softwareを識別するために［
それらの有意度の降順
］で~listされる。
各 `製品~識別子$は、名前, および~version（ `product-version$p, 省略可能）からなる。
◎
The User-Agent field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), which together identify the user agent software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the user agent software. Each product identifier consists of a name and optional version.
</p>

<pre class="bnf">
`product@p
	= `token$p ["/" `product-version$p]
`product-version@p
	= `token$p
</pre>

<div class="p">
<p>
`送信者$は：
◎
↓</p>

<ul>
	<li>
`生成する$`製品~識別子$を［
製品を識別するために必要yなもの
］に制限するベキである。
◎
A sender SHOULD limit generated product identifiers to what is necessary to identify the product;＼
</li>
	<li>
`製品~識別子$の中に［
広告-用その他の本質的でない情報
］を`生成し$てはナラナイ。
◎
a sender MUST NOT generate advertising or other nonessential information within the product identifier.＼
</li>
	<li>
`product-version$p 内に，~version識別子でない情報を`生成する$ベキでない（すなわち，［
同じ製品~名の 一連の~version
］は、［
製品~識別子の `product-version$p 部位
］においてのみ相違する~OUGHT）。
◎
A sender SHOULD NOT generate information in product-version that is not a version identifier (i.e., successive versions of the same product name ought to differ only in the product-version portion of the product identifier).
</li>
</ul>
</div>

<div class="example">
<p>
例：
◎
Example:
</p>

<pre class="lang-http">
User-Agent: CERN-LineMode/2.15 libwww/2.17b3
</pre>

</div>

<div class="p">
<p>
`~UA$は：
◎
A user agent＼
</p>

<ul>
	<li>
~~不必要に木目細かな詳細を包含する `User-Agent^h ~headerを，`生成する$ベキでない。
◎
SHOULD NOT generate a User-Agent field containing needlessly fine-grained detail and＼
</li>
	<li>
第三者-主体による下位製品の追加を，制限するベキである。
◎
SHOULD limit the addition of subproducts by third parties.＼
</li>
</ul>

<p>
~~不必要に長く詳細な `User-Agent^h `~header値$は、要請の待時間を増大させ，利用者の望みに反して, 識別される~risk（ “`指紋収集$” ）を高める。
◎
Overly long and detailed User-Agent field values increase request latency and the risk of a user being identified against their wishes ("fingerprinting").
</p>
</div>

<p>
同様に，実装には、［
他の実装の製品~tokenを，互換性を宣言するために利用する
］ことは奨励されない
— そうすると，この~headerの目的を~~無為にするので。
別の~UAとして仮装する~UAに対しては、`受信者$は，［
利用者が意図的に，その別の~UA用に誂えられた応答を見たいと欲している
］ものと見做せる
— その応答が、実際に利用されている~UAで働くかどうかに関わらず。
◎
Likewise, implementations are encouraged not to use the product tokens of other implementations in order to declare compatibility with them, as this circumvents the purpose of the field. If a user agent masquerades as a different user agent, recipients can assume that the user intentionally desires to see responses tailored for that identified user agent, even if they might not work as well for the actual user agent being used.
</p>

			</section>
		</section>
	</section>
	<section id="section-6">
<h2 title="Response Status Codes">6. 応答~状態s~code</h2>

<p>
応答の
`状態s~code^dfn
（ `status-code$p 要素）は、 3 桁の整数~codeであり，［
要請を解して それを充足しようと試みた結果
］を与える。
◎
The status-code element is a three-digit integer code giving the result of the attempt to understand and satisfy the request.
</p>

<p>
~HTTP状態s~codeは、拡張できる。
~HTTP`~client$には、［
登録-済みな状態s~codeすべての意味を解する
］ことは要求されない
— もちろん、解する方が望ましいが。
しかしながら，`~client$は、［
最初の桁により指示される，
どの［
状態s~codeの`応答class$
］］に対しても，それを解した上で，未認識~状態s~codeを［
その`応答class$の状態s~code `x00^st0に等価である
］ものとして，扱わなければナラナイ。
ただし 例外として、`受信者$は，そのような応答を~cacheしてはナラナイ。
◎
HTTP status codes are extensible. HTTP clients are not required to understand the meaning of all registered status codes, though such understanding is obviously desirable. However, a client MUST understand the class of any status code, as indicated by the first digit, and treat an unrecognized status code as being equivalent to the x00 status code of that class, with the exception that a recipient MUST NOT cache a response with an unrecognized status code.
</p>

<p>
例えば，~clientが［
未認識~状態s~code `471^st0
］を受信したときは、［
その要請に何か誤りがある
］ものと見做した上で，［
応答を `400$stを受信したかのように扱う
］ことができる。
応答~messageは、通例的に，その状態sを説明する`表現$を包含することになる。
◎
For example, if an unrecognized status code of 471 is received by a client, the client can assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) status code. The response message will usually contain a representation that explains the status.
</p>

<p>
`status-code$p の最初の桁は、応答の
`応答class@
を定義する。
下位 2 桁には、分類上の役割はない。
`応答class$には、次に挙げる 5 種がある：
◎
The first digit of the status-code defines the class of response. The last two digits do not have any categorization role. There are five values for the first digit:
</p>

<dl>
	<dt>`1xx$st</dt>
	<dd>
要請は受信され、その処理nは継続中にある。
◎
• 1xx (Informational): The request was received, continuing process
</dd>

	<dt>`2xx$st</dt>
	<dd>
要請は、成功裡に［
受信され,
解され,
受容された
］。
◎
• 2xx (Successful): The request was successfully received, understood, and accepted
</dd>

	<dt>`3xx$st</dt>
	<dd>
要請を完了するためには、更なる動作がとられる必要がある。
◎
• 3xx (Redirection): Further action needs to be taken in order to complete the request
</dd>

	<dt>`4xx$st</dt>
	<dd>
要請は、不良な構文を包含しているか, または履行できない。
◎
• 4xx (Client Error): The request contains bad syntax or cannot be fulfilled
</dd>

	<dt>`5xx$st</dt>
	<dd>
要請は 見かけ上は妥当であるが、`~server$はその履行-に失敗した。
◎
• 5xx (Server Error): The server failed to fulfill an apparently valid request
</dd>
</dl>

		<section id="section-6.1">
<h3 title="Overview of Status Codes">6.1. 状態s~codeの概観</h3>

<p>
下に挙げる`状態s~code$は、この仕様の各所にて定義される。
括弧内に挙げる各種
`事由~句@（ `reason-phrase$p ）
は、推奨に過ぎない
— それらは、~protocolに影響することなく，局所的な等価~物に置換できる。
◎
The status codes listed below are defined in this specification, Section 4 of [RFC7232], Section 4 of [RFC7233], and Section 3 of [RFC7235]. The reason phrases listed here are only recommendations -- they can be replaced by local equivalents without affecting the protocol.
</p>

<p>
`既定で~cache可能である@
と定義されている状態s~code（例： この仕様では
`200$st0 , `203$st0 , `204$st0 , `206$st0 , `300$st0 , `301$st0 , `404$st0 , `405$st0 , `410$st0 , `414$st0 , `501$st0
）を伴う応答は、［
~method定義や明示的~cache制御
］から指示されない限り，［
<a href="~7234#section-4.2.2" >経験的~失効</a>を伴う~cache
］により再利用できる。
他のすべての状態s~codeは、既定では，~cache可能でない。
◎
Responses with status codes that are defined as cacheable by default (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in this specification) can be reused by a cache with heuristic expiration unless otherwise indicated by the method definition or explicit cache controls [RFC7234]; all other status codes are not cacheable by default.
</p>

<div>
<ul><li>`100$st
</li><li>`101$st
</li><li>`200$st
</li><li>`201$st
</li><li>`202$st
</li><li>`203$st
</li><li>`204$st
</li><li>`205$st
</li><li>`206$st `7233$R
</li><li>`300$st
</li><li>`301$st
</li><li>`302$st
</li><li>`303$st
</li><li>`304$st `7232$R
</li><li>`305$st
</li><li>`307$st
</li><li>`400$st
</li><li>`401$st `7235$R
</li><li>`402$st
</li><li>`403$st
</li><li>`404$st
</li><li>`405$st
</li><li>`406$st
</li><li>`407$st `7235$R
</li><li>`408$st
</li><li>`409$st
</li><li>`410$st
</li><li>`411$st
</li><li>`412$st `7232$R
</li><li>`413$st
</li><li>`414$st
</li><li>`415$st
</li><li>`416$st `7233$R
</li><li>`417$st
</li><li>`426$st
</li><li>`500$st
</li><li>`501$st
</li><li>`502$st
</li><li>`503$st
</li><li>`504$st
</li><li>`505$st
</li></ul>

<pre lang="en" class="_en">
   +------+-------------------------------+--------------------------+
   | Code | Reason-Phrase                 | Defined in...            |
   +------+-------------------------------+--------------------------+
   | 100  | Continue                      | Section 6.2.1            |
   | 101  | Switching Protocols           | Section 6.2.2            |
   | 200  | OK                            | Section 6.3.1            |
   | 201  | Created                       | Section 6.3.2            |
   | 202  | Accepted                      | Section 6.3.3            |
   | 203  | Non-Authoritative Information | Section 6.3.4            |
   | 204  | No Content                    | Section 6.3.5            |
   | 205  | Reset Content                 | Section 6.3.6            |
   | 206  | Partial Content               | Section 4.1 of [RFC7233] |
   | 300  | Multiple Choices              | Section 6.4.1            |
   | 301  | Moved Permanently             | Section 6.4.2            |
   | 302  | Found                         | Section 6.4.3            |
   | 303  | See Other                     | Section 6.4.4            |
   | 304  | Not Modified                  | Section 4.1 of [RFC7232] |
   | 305  | Use Proxy                     | Section 6.4.5            |
   | 307  | Temporary Redirect            | Section 6.4.7            |
   | 400  | Bad Request                   | Section 6.5.1            |
   | 401  | Unauthorized                  | Section 3.1 of [RFC7235] |
   | 402  | Payment Required              | Section 6.5.2            |
   | 403  | Forbidden                     | Section 6.5.3            |
   | 404  | Not Found                     | Section 6.5.4            |
   | 405  | Method Not Allowed            | Section 6.5.5            |
   | 406  | Not Acceptable                | Section 6.5.6            |
   | 407  | Proxy Authentication Required | Section 3.2 of [RFC7235] |
   | 408  | Request Timeout               | Section 6.5.7            |
   | 409  | Conflict                      | Section 6.5.8            |
   | 410  | Gone                          | Section 6.5.9            |
   | 411  | Length Required               | Section 6.5.10           |
   | 412  | Precondition Failed           | Section 4.2 of [RFC7232] |
   | 413  | Payload Too Large             | Section 6.5.11           |
   | 414  | URI Too Long                  | Section 6.5.12           |
   | 415  | Unsupported Media Type        | Section 6.5.13           |
   | 416  | Range Not Satisfiable         | Section 4.4 of [RFC7233] |
   | 417  | Expectation Failed            | Section 6.5.14           |
   | 426  | Upgrade Required              | Section 6.5.15           |
   | 500  | Internal Server Error         | Section 6.6.1            |
   | 501  | Not Implemented               | Section 6.6.2            |
   | 502  | Bad Gateway                   | Section 6.6.3            |
   | 503  | Service Unavailable           | Section 6.6.4            |
   | 504  | Gateway Timeout               | Section 6.6.5            |
   | 505  | HTTP Version Not Supported    | Section 6.6.6            |
   +------+-------------------------------+--------------------------+
</pre>

</div>

<p>
この~listは、網羅的ではないことに注意
— 他の仕様にて定義される拡張~状態s~codeは，含まれていない。
状態s~codeの完全な~listは、~IANAにより保守されている。
詳細は、`8.2$secを見よ。
◎
Note that this list is not exhaustive -- it does not include extension status codes defined in other specifications. The complete list of status codes is maintained by IANA. See Section 8.2 for details.
</p>

		</section>
		<section id="section-6.2">
<h3 title="Informational 1xx">6.2. 情報~的： `1xx^st0</h3>

<p>
`応答class$ `1xx^st の`状態s~code$は、
暫定的な応答を指示する
— すなわち、［
要請された動作, および
その最終~応答の送信
］を完了するに先立って，［
接続の状態s／要請の進捗状況
］を通信するためにある。
`1xx^st0 応答は、［
`status-line$p の後の最初の空~行l（`~header節$の終端を通達する空~行l）
］で終了される。
~HTTP10は，この応答classの状態s~codeを定義しないので、`~server$は，~HTTP10~clientに対しては `1xx^st0 応答を送信してはナラナイ。
◎
The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. 1xx responses are terminated by the first empty line after the status-line (the empty line signaling the end of the header section). Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.
</p>

<p>
`~client$は、最終~応答に先立って受信された，［
一つ以上の `1xx^st0 応答
］を，自身が予期していないとしても，構文解析できなければナラナイ。
`~UA$は、予期していない `1xx^st0 応答を無視してもヨイ。
◎
A client MUST be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.
</p>

<p>
`~proxy$は、［
自身が `1xx^st0 応答の生成を要請した
］のでない限り，
`1xx^st0 応答を回送しなければナラナイ。
例えば，~proxyが要請を回送するときに
`Expect: 100-continue^c
~headerを追加した場合には、対応する `100^st 応答（たち）を回送する必要はない。
◎
A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).
</p>

			<section id="section-6.2.1">
<h4>6.2.1. `100^st</h4>

<p>
状態s~code `100^stは、［
要請の初期~部分が受信され，まだ，~serverにより却下されていない
］ことを指示する。
~serverは、［
要請を全部的に受信して, 動作した後に，最終~応答を送信する
］ことを意図している。
◎
The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.
</p>

<p>
［
`~100cont 期待$を内包する `Expect$h ~header
］を包含する要請に対する `100^st0 応答は、［
~serverが要請`~payload本体$の受信を望んでいる
］ことを指示する
— `~client$は、要請の送信を継続する~OUGHT —
`100^st0 応答は破棄して。
この暫定的~応答が，そうでない要請に対するものであれば、`~client$は，単純にそれを破棄できる。
◎
When the request contains an Expect header field that includes a 100-continue expectation, the 100 response indicates that the server wishes to receive the request payload body, as described in Section 5.1.1. The client ought to continue sending the request and discard the 100 response.
◎
If the request did not contain an Expect header field containing the 100-continue expectation, the client can simply discard this interim response.
</p>

			</section>
			<section id="section-6.2.2">
<h4>6.2.2. `101^st</h4>

<p>
状態s~code `101^stは、［
`~server$が`~client$の要請を解すること, および［
この接続に利用されている応用~protocol
］を変更するために，
`Upgrade$h ~header を介して，要請に準拠する用意がある
］ことを指示する。
`~server$は、 `101^st0 応答~内に，［［
その応答を終了させる空~行lの直後から 切替わることになる，~protocol（たち）
］を指示する， `Upgrade$h ~header
］を`生成し$なければナラナイ。
◎
The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field (Section 6.7 of [RFC7230]), for a change in the application protocol being used on this connection. The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.
</p>

<p>
~serverが~protocolの切替に同意するのは、その方が有利なときに限られるものと見做されている。
例えば、［
より新しい~versionの~HTTPへの切替
］は，より古い~versionより有利であろうし、［
~real-time, 同期的~protocolへの切替
］は，そのような特能を利用する資源を送達するときに有利になるであろう。
◎
It is assumed that the server will only agree to switch protocols when it is advantageous to do so. For example, switching to a newer version of HTTP might be advantageous over older versions, and switching to a real-time, synchronous protocol might be advantageous when delivering resources that use such features.
</p>

			</section>
		</section>
		<section id="section-6.3">
<h3 title="Successful 2xx">6.3. 成功裡： `2xx^st0</h3>

<p>
`応答class$ `2xx^st の`状態s~code$は、`~client$の要請が，成功裡に［
受信され, 解され, 受容された
］ことを指示する。
◎
The 2xx (Successful) class of status code indicates that the client's request was successfully received, understood, and accepted.
</p>

			<section id="section-6.3.1">
<h4>6.3.1. `200^st</h4>

<p>
状態s~code `200^stは、［
要請が~成功した
］ことを指示する。
`200^st0 応答~内に送信される~payloadは、`要請~method$に依存する。
この仕様で定義される~methodに対しては、~payloadに意図される意味は，次の様に要約できる：
◎
The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method. For the methods defined by this specification, the intended meaning of the payload can be summarized as:
</p>

<table><tbody>

<tr><th>`GET$m
<td>
`~target資源$の`表現$。
◎
a representation of the target resource;

<tr><th>`HEAD$m
<td>
`表現~data$は伴わないことを除いて、 `GET$m のときと同じ表現。
◎
the same representation as GET, but without the representation data;

<tr><th>`POST$m
<td>
［
動作の状態s,
または動作により得された結果
］の`表現$。
◎
a representation of the status of, or results obtained from, the action;

<tr><th>`PUT$m, `DELETE$m
<td>
［
動作の状態s
］の`表現$。
◎
a representation of the status of the action;

<tr><th>`OPTIONS$m
<td>
各種~通信~optionの`表現$。
◎
a representation of the communications options;

<tr><th>`TRACE$m
<td>
［
終端~serverにより受信された時点での，要請~message
］の`表現$。
◎
a representation of the request message as received by the end server.
</table>

<p>
`CONNECT$m に対する応答は別として、
`200^st0 応答は，常に~payloadを持つ
— `生成元~server$は、長さ 0 の`~payload本体$を`生成し$てヨイが。
~payloadが欲されていない場合、生成元~serverは代わりに
`204$st を送信する~OUGHT。
`CONNECT$m に対しては，~payloadは許容されない
— その成功裡な結果は、`~tunnel$であり，
`200^st0 応答の`~header節$の直後から始まるので。
◎
Aside from responses to CONNECT, a 200 response always has a payload, though an origin server MAY generate a payload body of zero length. If no payload is desired, an origin server ought to send 204 (No Content) instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the 200 response header section.
</p>

<p>
`200^st0 応答は、`既定で~cache可能である$。
◎
A 200 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.3.2">
<h4>6.3.2. `201^st</h4>

<p>
状態s~code `201^stは、［
要請は履行され，その結果 一つ以上の新たな`資源$が作成されている
］ことを指示する。
［
要請により作成された`首な資源$
］は、［
応答~内に `Location$h ~headerが受信されたならば その値 ／
他の場合は `実効~要請~URI$
］により識別される。
◎
The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.
</p>

<p>
`201^st0 応答の~payloadは、概して，作成された`資源$（たち）を述べ, それらへ~linkする。
`201^st0 応答~内の［
`ETag$h や `Last-Modified$h などの`検証子~header$
］の意味と目的についての論点は、`7.2$secを見よ。
◎
The 201 response payload typically describes and links to the resource(s) created. See Section 7.2 for a discussion of the meaning and purpose of validator header fields, such as ETag and Last-Modified, in a 201 response.
</p>

			</section>
			<section id="section-6.3.3">
<h4>6.3.3. `202^st</h4>

<p>
状態s~code `202^stは、［
要請は処理~用に受容されたが，処理はまだ完了していない
］ことを指示する。
最終的に要請が動作するかどうかは、実際の処理に入るときに許容されなくなることもあるので，~~確定していない。
~HTTPには、［
非同期的な~~処理から状態s~codeを再~送信する
］ような便宜性はない。
◎
The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.
</p>

<p>
`202^st0 応答は、意図的に当り障りのないもの（ noncommittal ）にされている。
その目的は、`~server$が［
何らかの処理n（たぶん，日に一度だけ稼働する~~一括~処理n）用の要請
］を，［
`~UA$に，その処理の完了まで~serverへの接続を持続する
］ことを要求することなく，受容できるようにすることである。
この応答に伴って送信される`表現$は、要請の現在の状態sを述べ，［
利用者に 要請がいつ履行されるかの見積もりを供せるような，状態s監視器
］を指す（または埋込む）~OUGHT。
◎
The 202 response is intentionally noncommittal. Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent's connection to the server persist until the process is completed. The representation sent with this response ought to describe the request's current status and point to (or embed) a status monitor that can provide the user with an estimate of when the request will be fulfilled.
</p>

			</section>
			<section id="section-6.3.4">
<h4>6.3.4. `203^st</h4>

<p>
状態s~code `203^stは、［
要請は成功したが、同封された~payloadは，`形式変換ng~proxy$により［
生成元~serverの `200^st 応答のそれ
］から改変されている（`7230-5.7.2$rfc）
］ことを指示する。
この状態s~codeにより、`形式変換$を適用した~proxyは，その旨を受信者たちに通知できるようになる
— その知識は，内容に関する今後の裁定に影響iすることがある。
例えば，［
内容に対する，未来の~cache検証~要請
］が適用-可能になるのは、同じ要請~経路に沿うもの（同じ~proxyたちを通して）に限られるようになり得る。
◎
The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy (Section 5.7.2 of [RFC7230]). This status code allows the proxy to notify recipients when a transformation has been applied, since that knowledge might impact later decisions regarding the content. For example, future cache validation requests for the content might only be applicable along the same request path (through the same proxies).
</p>

<p>
`203^st0 応答は、［［
どの状態s~codeを伴う応答にも適用-可能である利点
］を持つ `Warning$h ~code `214$wc
］に類似する。
◎
The 203 response is similar to the Warning code of 214 Transformation Applied (Section 5.5 of [RFC7234]), which has the advantage of being applicable to responses with any status code.
</p>

<p>
`203^st0 応答は、`既定で~cache可能である$。
◎
A 203 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.3.5">
<h4>6.3.5. `204^st</h4>

<p>
状態s~code `204^stは、［
`~server$が，要請を成功裡に履行した
］こと, および［
その応答`~payload本体$~内に送信する追加的な内容は無い
］ことを指示する。
`応答~header$内の~metadataは、`~target資源$, および［
要請された動作が適用された後に`選定された表現$
］を指す。
◎
The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.
</p>

<p>
例えば、
`PUT$m 要請に対する応答~内に `204^st0が受信され，応答が `ETag$h ~headerを包含する場合、
`PUT$m は成功していて，
`ETag$h `~header値$が，［
その`~target資源$の新たな`表現$用の `entity-tag$p
］を包含する。
◎
For example, if a 204 status code is received in response to a PUT request and the response contains an ETag header field, then the PUT was successful and the ETag field-value contains the entity-tag for the new representation of that target resource.
</p>

<p>
`204^st0 応答により、`~server$は，`~UA$に向けて［［
~UAは，自身の現在の “文書~view” （もしあれば）から離れて他へ辿る必要はない
］ことを含意しつつ，動作が`~target資源$に成功裡に適用された
］ことを指示できるようになる。
`~server$は、［
~UAが、自身の~interfaceに則って，利用者に何らかの成功の指示を供した上で、［
応答~内の新たな／更新された~metadata
］を，~UAにて作動中な表現に適用することになる
］ものと見做している。
◎
The 204 response allows a server to indicate that the action has been successfully applied to the target resource, while implying that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or updated metadata in the response to its active representation.
</p>

<p>
例えば， `204^st0は、［
“保存” 動作に対応する文書~編集~interface
］と伴に共通的に利用され，［
保存した文書が，利用者による編集~用に可用であり続ける
］ようにする。
それはまた、分散型の~version制御~systemの中など，［
自動化された~data転送が主流になると予期される~interface
］と伴に利用されることが多い。
◎
For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that the document being saved remains available to the user for editing. It is also frequently used with interfaces that expect automated data transfers to be prevalent, such as within distributed version control systems.
</p>

<p>
`204^st0 応答は、`~message本体$を包含できない。
そのため、`~header節$の後の最初の空~行lで終了される。
◎
A 204 response is terminated by the first empty line after the header fields because it cannot contain a message body.
</p>

<p>
`204^st0 応答は、`既定で~cache可能である$。
◎
A 204 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.3.6">
<h4>6.3.6. `205^st</h4>

<p>
状態s~code `205^stは、［
`~server$は，要請を履行した
］こと, および［
`~UA$は，［
要請を送信させた “文書~view”
］を［
その，`生成元~server$から受信された元の状態に~resetする
］ことを欲している
］ことを指示する。
◎
The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the "document view", which caused the request to be sent, to its original state as received from the origin server.
</p>

<p>
この応答は、［
共通的な~data手入力の利用事例
］を~supportすることが意図されている：
そこでは、［［
~data手入力（~form, ~notepad, ~canvas, 等々）を~supportする内容
］を受信した利用者が，その場で手入力したり操作した~data
］が，要請にて提出されたとき、［
利用者が別の入力~動作に容易に取り掛かれる
］ように［
次回の手入力~用に，~data手入力の仕組みを~resetさせる
］ような。
◎
This response is intended to support a common data entry use case where the user receives content that supports data entry (a form, notepad, canvas, etc.), enters or manipulates data in that space, causes the entered data to be submitted in a request, and then the data entry mechanism is reset for the next entry so that the user can easily initiate another input action.
</p>

<div class="p">

<p>
状態s~code `205^st0は，［
追加的な内容は供されない
］ことを含意するので、`~server$は，
`205^st0 応答~内に~payloadを`生成し$てはナラナイ。
言い換えれば，`~server$は、`205^st0 応答に際しては，次のいずれかを~行わなければナラナイ：
◎
Since the 205 status code implies that no additional content will be provided, a server MUST NOT generate a payload in a 205 response. In other words, a server MUST do one of the following for a 205 response:＼
</p>

<ul>
	<li>
応答に［
値 `0^c をとる `Content-Length$h ~header
］を内包させて，［
その本体の長さは 0 である
］ことを指示する。
◎
a) indicate a zero-length body for the response by including a Content-Length header field with a value of 0;＼
</li>
	<li>
応答に［
値 `chunked$c をとる `Transfer-Encoding$h ~header
］, および［
長さ 0 の単独の~chunk
］からなる`~message本体$を内包させて，［
~payloadの長さは 0 である
］ことを指示する。
◎
b) indicate a zero-length payload for the response by including a Transfer-Encoding header field with a value of chunked and a message body consisting of a single chunk of zero-length; or,＼
</li>
	<li>
`~header節$を終了させる空~行lを送信した直後に接続を~closeする。
◎
c) close the connection immediately after sending the blank line terminating the header section.
</li>
</ul>

</div>

			</section>
		</section>
		<section id="section-6.4">
<h3 title="Redirection 3xx">6.4. ~redirection： `3xx^st0</h3>

<p>
`応答class$ `3xx^st の`状態s~code$は、［
要請が履行されるためには，~UAによる更なる動作がとられる必要がある
］ことを指示する。
応答に `Location$h ~headerが供されている場合、`~UA$は、［
その特定の状態s~codeを解せない
］ときでも，［
その~header値により参照される`~URI$
］へ向けて 要請を自動的に~redirectして
【“~directし直して”】
もヨイ。
自動的な~redirectionは、［
`安全$であると既知でない~method
］に対しては，［
利用者がその~redirectを望まないこともある
］ので、~~注意して行われる必要がある。
◎
The 3xx (Redirection) class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. If a Location header field (Section 7.1.2) is provided, the user agent MAY automatically redirect its request to the URI referenced by the Location field value, even if the specific status code is not understood. Automatic redirection needs to done with care for methods not known to be safe, as defined in Section 4.2.1, since the user might not wish to redirect an unsafe request.
</p>
【！Errata ID: 4452 "to done" → "to be done"】

<p>
~redirectには数種の型がある：
◎
There are several types of redirects:
</p>

<ul>
	<li>
［
`資源$が［
`Location$h ~headerにより供される，異なる~URI
］にて可用であり得る
］ことを指示する~redirect
— `301$st, `302$st, `307$st が該当する。
◎
1. Redirects that indicate the resource might be available at a different URI, as provided by the Location field, as in the status codes 301 (Moved Permanently), 302 (Found), and 307 (Temporary Redirect).
</li>
	<li>
［［
それぞれが，元の`要請~target$を表現する能力を備えている
］ような，いくつかの合致した`資源$
］の選択肢を提供する~redirection
— `300$st が該当する。
◎
2. Redirection that offers a choice of matching resources, each capable of representing the original request target, as in the 300 (Multiple Choices) status code.
</li>
	<li>
［
要請に対する間接的な応答を表現し得る
］ような，［
`Location$h ~headerにより識別される，異なる`資源$
］への~redirection
— `303$st が該当する。
◎
3. Redirection to a different resource, identified by the Location field, that can represent an indirect response to the request, as in the 303 (See Other) status code.
</li>
	<li>
［
以前に~cache済みな結果
］への~redirection
— `304$st が該当する。
◎
4. Redirection to a previously cached result, as in the 304 (Not Modified) status code.
</li>
</ul>

<p class="note">注記：
~HTTP10においては、
`301$st, `302$st は，［
~~上述の最初の型の~redirect（`1945-9.3$rfc）
］として定義されていた。
早期の~UAは、~redirect~targetに適用するときに，［
~methodを，元の要請と同じにするものと, `GET$m に書換えるもの
］に分かれる。
~HTTPは~~元々は、［
`301$st0, `302$st に対しては前者の意味論
］に, ［
`303$st に対しては後者の意味論
］に合致するように定義されていたが、支配的な実施から［
`301$st0, `302$st0 に対しても後者の意味論
］になるように徐々に収束してきた。
`~HTTP11$の最初の改訂には、実施の分岐に影響iされないものとして，前者の意味論を指示する `307$st が追加された。
10 年が経過した今でも、ほとんどの~UAは，［
`301$st0 ／ `302$st0
］に対しては，依然として~methodを書換えている
— したがって，この仕様は、元の要請が `POST$m であるときには，その挙動を適合とする。
◎
Note: In HTTP/1.0, the status codes 301 (Moved Permanently) and 302 (Found) were defined for the first type of redirect ([RFC1945], Section 9.3). Early user agents split on whether the method applied to the redirect target would be the same as the original request or would be rewritten as GET. Although HTTP originally defined the former semantics for 301 and 302 (to match its original implementation at CERN), and defined 303 (See Other) to match the latter semantics, prevailing practice gradually converged on the latter semantics for 301 and 302 as well. The first revision of HTTP/1.1 added 307 (Temporary Redirect) to indicate the former semantics without being impacted by divergent practice. Over 10 years later, most user agents still do method rewriting for 301 and 302; therefore, this specification makes that behavior conformant when the original request is POST.
</p>

<p>
`~client$は、循環的~redirection（すなわち， “無限” ~redirection~loop）を，検出して, 介入するベキである。
◎
A client SHOULD detect and intervene in cyclical redirections (i.e., "infinite" redirection loops).
</p>

<p class="note">注記：［
この仕様の~~過去の~version
］では、
~redirection回数として最大 5 回までが推奨されていた （`2068-10.3$rfc）。
内容~開発者は、［
そのような固定的な制限を実装する~clientもあり得る
］ことを自覚しておく必要がある。
◎
Note: An earlier version of this specification recommended a maximum of five redirections ([RFC2068], Section 10.3). Content developers need to be aware that some clients might implement such a fixed limitation.
</p>

			<section id="section-6.4.1">
<h4>6.4.1. `300^st</h4>

<p>
状態s~code `300^stは、［
`~target資源$は複数の`表現$を持ち，そのそれぞれが［
自前の，より特定な識別子
］を伴う
］こと，および［
それらの代替についての情報が供されていて、利用者（または~UA）は，［
それらの識別子のうち 一つ以上のものへ，要請を~redirectする
］ことにより，選好する表現を選定できる
］ことを指示する。
言い換えれば、`~server$は，［
`~UA$が`~reactive折衝$に参加して，その必要性に合わせて，最も適切な表現（たち）を選定する
］ことを欲している。
◎
The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs (Section 3.4).
</p>

<p>
`~server$は、それらの選択肢のうち 選好するものがあるならば，［
その選択肢の~URI参照を包含する `Location$h ~header
］を`生成する$ベキである。
`~UA$は、その `Location$h ~headerの値を，自動的な~redirectionに利用してもヨイ。
◎
If the server has a preferred choice, the server SHOULD generate a Location header field containing a preferred choice's URI reference. The user agent MAY use the Location field value for automatic redirection.
</p>

<p>
［
`HEAD$m 以外の`要請~method$
］に対しては、`~server$は， `300^st0 応答~内に［［
利用者や~UAが，最も選好するものを選択できる
］ような，［
`表現~metadata$と~URI参照（たち）
］の~list
］を包含する~payloadを`生成する$ベキである。
`~UA$は、供された`~MIME型$を解するならば，その~listから自動的に選定してもヨイ。
［
自動的な選定~用の特定の形式
］は、この仕様では，定義されない。
何故なら、~HTTPは，~payloadの定義に直交的であろうとし続けるので。
実施においては、`表現$は，［
共有されている 設計や`内容~折衝$により決定され，~UAに受容-可能と予見される，何らかの容易に構文解析できる形式
］か, あるいは［
何らかの共通的に受容される~hypertext形式
］により，供される。
◎
For request methods other than HEAD, the server SHOULD generate a payload in the 300 response containing a list of representation metadata and URI reference(s) from which the user or user agent can choose the one most preferred. The user agent MAY make a selection from that list automatically if it understands the provided media type. A specific format for automatic selection is not defined by this specification because HTTP tries to remain orthogonal to the definition of its payloads. In practice, the representation is provided in some easily parsed format believed to be acceptable to the user agent, as determined by shared design or content negotiation, or in some commonly accepted hypertext format.
</p>

<p>
`300^st0 応答は、`既定で~cache可能である$。
◎
A 300 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

<p class="note">注記：
`300^st0に対する元の提案では、 `URI^h ~headerを［［
`200$st0 ／ `300^st0 ／ `406$st0
］応答に利用でき，［
`HEAD$m ~methodに対する応答~内に転送される，代替~表現の~list
］を供するもの
］として，定義していた。
しかしながら，［
配備の欠如と，構文について合意が得られなかった
］ため、 `URI^h, および `Alternates^h（後続な提案）のいずれも，この仕様からは落とされることになった。
配備については 鶏と卵の問題であるが、［
互いを “代替する” 関係性にある，一連の `Link$h ~header `5988$R
］を利用して，~listを通信することはアリである。
◎
Note: The original proposal for the 300 status code defined the URI header field as providing a list of alternative representations, such that it would be usable for 200, 300, and 406 responses and be transferred in responses to the HEAD method. However, lack of deployment and disagreement over syntax led to both URI and Alternates (a subsequent proposal) being dropped from this specification. It is possible to communicate the list using a set of Link header fields [RFC5988], each with a relationship of "alternate", though deployment is a chicken-and-egg problem.
</p>

			</section>
			<section id="section-6.4.2">
<h4>6.4.2. `301^st</h4>

<p>
状態s~code `301^stは、［
`~target資源$に，新たな恒久的~URIがアテガわれていて、この資源への未来の参照は，同封された いずれかの~URIを利用する~OUGHT
］ことを指示する。
~link編集~能力を備えている`~client$は、アリな所では，［
`実効~要請~URI$への参照
］を［
~serverから送信されてきた，一つ以上の新たな参照
］に，自動的に~linkし直す~OUGHT。
◎
The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.
</p>

<p>
`~server$は、応答~内に，［［
新たな恒久的~URIとして選好される，~URI参照
］を包含する， `Location$h ~header
］を`生成する$ベキである。
`~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。
~serverの応答~payloadは、通例的に，［
新たな~URI（たち）への~hyperlinkを伴う，短い~hypertext
］を包含する。
◎
The server SHOULD generate a Location header field in the response containing a preferred URI reference for the new permanent URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s).
</p>

<p class="note">注記：
歴史的な理由のため、~UAは、後続な要請~用の`要請~method$を
`POST$m から `GET$m へ変更してもヨイ。
この挙動が欲されない場合、代わりに `307$stを利用できる。
◎
Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.
</p>

<p>
`301^st0 応答は、`既定で~cache可能である$。
◎
A 301 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.4.3">
<h4>6.4.3. `302^st</h4>

<p>
状態s~code `302^stは、［
`~target資源$が，一時的に，異なる~URIの下に居る
］ことを指示する。
~redirectionは，その時々で改められ得るので、`~client$は，未来の要請には `実効~要請~URI$を利用し続ける~OUGHT。
◎
The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.
</p>

<p>
`~server$は、応答~内に，［［
その異なる~URI用の~URI参照
］を包含する `Location$h ~header
］を`生成する$ベキである。
`~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。
~serverの応答~payloadは、通例的に，［
異なる~URI（たち）への~hyperlinkを伴う，短い~hypertext
］を包含する。
◎
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
</p>

<p class="note">注記：
歴史的な理由のため、`~UA$は、後続な要請~用の`要請~method$を
`POST$m から `GET$m へ変更してもヨイ。
この挙動が欲されない場合、代わりに `307$stを利用できる。
◎
Note: For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request. If this behavior is undesired, the 307 (Temporary Redirect) status code can be used instead.
</p>

			</section>
			<section id="section-6.4.4">
<h4>6.4.4. `303^st</h4>

<p>
状態s~code `303^stは、［
~serverが，~UAを［
`Location$h ~header内の~URIにより指示される，異なる`資源$
］へ~redirectしている
］ことを指示する
— その意図は、［
元の要請に対する間接的な応答を供する
］ことである。
`~UA$は、［
その~URIを~targetにする検索取得~要請（ ~HTTPを利用しているなら `GET$m または `HEAD$m 要請）
］を遂行できる
— それは、［
元の要請に対する回答として最終的な結果を呈示する
］ために，また~redirectされ得る。
`Location$h ~header内の新たな~URIは、`実効~要請~URI$に等価なものとは見なされないことに注意。
◎
The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.
</p>

<p>
この状態s~codeは、どの~HTTP~methodにも適用-可能である。
これは首に、［
`POST$m 動作の出力により，`~UA$を選定された`資源$へ~redirectできるようにする
］ために利用される
— そうすることにより、［
~formにおける `POST$m 応答に対応する情報
］は、元の要請からは独立に, ［
別々に［
識別する／~bookmarkする／~cacheする
］ことができる形
］で，供されるようになる。
◎
This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that can be separately identified, bookmarked, and cached, independent of the original request.
</p>

<p>
`GET$m 要請に対する `303^st0 応答は、［
`生成元~server$は［
~serverにより~HTTP越しに転送できるような［
`~target資源$の`表現$
］を持たないが、
`Location$h `~header値$は［
元の~target資源 `A^var を~~記述するものである，資源 `B^var
］を指している
］ことを指示する
— その資源 `B^var への検索取得~要請を為した結果が、資源 `A^var を表現することを含意することなく，受信者に有用な表現になり得るような。
［
何を表現し得るか？ ／
どのような表現であれば必要十分になるか？ ／
何が有用な~~記述になり得るか？
］に対する回答は、~HTTPの視野から外れることに注意。
◎
A 303 response to a GET request indicates that the origin server does not have a representation of the target resource that can be transferred by the server over HTTP. However, the Location field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that other resource might result in a representation that is useful to recipients without implying that it represents the original target resource. Note that answers to the questions of what can be represented, what representations are adequate, and what might be a useful description are outside the scope of HTTP.
</p>

<p>
`HEAD$m 要請に対する応答を除いて、［
`303^st0 応答の`表現$
］は、［［
`Location$h ~header内に供されたものと同じ~URI参照
］への~hyperlinkを伴う，短い~hypertext
］を包含する~OUGHT。
◎
Except for responses to a HEAD request, the representation of a 303 response ought to contain a short hypertext note with a hyperlink to the same URI reference provided in the Location header field.
</p>

			</section>
			<section id="section-6.4.5">
<h4>6.4.5. `305^st</h4>

<p>
状態s~code `305^stは，この仕様の以前の~versionにて定義されていたが、今や非推奨にされた（`付録 B＠#appendix-B$）。
◎
The 305 (Use Proxy) status code was defined in a previous version of this specification and is now deprecated (Appendix B).
</p>

			</section>
			<section id="section-6.4.6">
<h4 title="306 (Unused)">6.4.6. `306^st0 （未使用）</h4>

<p>
状態s~code `306^st0は，この仕様の以前の~versionにて定義されていたが、
もはや利用されず，この~codeは予約-済みにされた。
◎
The 306 status code was defined in a previous version of this specification, is no longer used, and the code is reserved.
</p>

			</section>
			<section id="section-6.4.7">
<h4>6.4.7. `307^st</h4>

<p>
状態s~code `307^stは、［
`~target資源$が，一時的に異なる~URIの下に居る
］ことに加えて, ［
`~UA$は、［
その~URIへの自動的な~redirectionを遂行する
］ときに，`要請~method$を変更してはナラナイ
］ことを指示する。
~redirectionは，時間~越し変化し得るので、`~client$は，未来の要請にも 元の`実効~要請~URI$を利用し続ける~OUGHT。
◎
The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.
</p>

<p>
`~server$は、応答~内に，［
その異なる~URI用の~URI参照を包含する， `Location$h ~header
］を`生成する$ベキである。
`~UA$は、その`~header値$を自動的な~redirectionに利用してもヨイ。
~serverの応答~payloadは、通例的に，［
その異なる~URI（たち）への~hyperlinkを伴う，短い~hypertext
］を包含する。
◎
The server SHOULD generate a Location header field in the response containing a URI reference for the different URI. The user agent MAY use the Location field value for automatic redirection. The server's response payload usually contains a short hypertext note with a hyperlink to the different URI(s).
</p>

<p class="note">注記：
この状態s~codeは， `302$st に似るが、［
その`要請~method$を `POST$m から `GET$m へ変更する
］ことは許容されない。
この仕様は、 `301$st に対しては，~~相当するものを定義しない
（しかしながら、 `7238$R が，この目的に `308＠~HTTPsem#status.308$st を定義する）。
◎
Note: This status code is similar to 302 (Found), except that it does not allow changing the request method from POST to GET. This specification defines no equivalent counterpart for 301 (Moved Permanently) ([RFC7238], however, defines the status code 308 (Permanent Redirect) for this purpose).
</p>

			</section>
		</section>
		<section id="section-6.5">
<h3 title="Client Error 4xx">6.5. ~client~error： `4xx^st0</h3>

<p>
`応答class$ `4xx^st の`状態s~code$は、［
~clientによる~errorに見える
］ことを指示する。
`HEAD$m 要請に対し応答するときを除いて、`~server$は，［［
その~error状況の説明，および
その条件は［
一時的, 恒久的
］のどちらなのか
］を包含している`表現$
］を送信するベキである。
これらの状態s~codeは、どの`要請~method$にも適用-可能である。
`~UA$は、内包された どの表現も，利用者に表示するベキである。
◎
The 4xx (Client Error) class of status code indicates that the client seems to have erred. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. These status codes are applicable to any request method. User agents SHOULD display any included representation to the user.
</p>

			<section id="section-6.5.1">
<h4>6.5.1. `400^st</h4>

<p>
状態s~code `400^stは、［
~serverは、~client~errorに知覚される何かに因り，要請を処理できない／するつもりがない
］ことを指示する（例：
要請の構文が~~正しくない ／
要請~message~frame法が妥当でない ／
要請の経路制御が~~誤認を誘うものである，など）。
◎
The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).
</p>

			</section>
			<section id="section-6.5.2">
<h4>6.5.2. `402^st</h4>

<p>
状態s~code `402^stは、将来~利用のために予約-済みにされる。
◎
The 402 (Payment Required) status code is reserved for future use.
</p>

			</section>
			<section id="section-6.5.3">
<h4>6.5.3. `403^st</h4>

<p>
状態s~code `403^stは、［
~serverは、要請を解したが，それに対する権限付与-を拒否している
］ことを指示する。
`~server$は、要請が何故 禁止されたか 公にしたいと望むならば，［
その理由を，応答の~payload（もしあれば）内に述べる
］ことができる。
◎
The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).
</p>

<p>
［
要請~内に認証用の`資格証$が供されていた
］場合、~serverは，［
それは，~accessを是認するには足らない
］と見なしている。
`~client$は、［
同じ資格証を伴わせた要請
］を，自動的に繰返すベキでない。
~clientは、［
新たな／異なる
］資格証を伴わせるのであれば，要請を繰返してもヨイ。
しかしながら、資格証に無関係な理由により，要請が禁止されることもある。
◎
If authentication credentials were provided in the request, the server considers them insufficient to grant access. The client SHOULD NOT automatically repeat the request with the same credentials. The client MAY repeat the request with new or different credentials. However, a request might be forbidden for reasons unrelated to the credentials.
</p>

<p>
`生成元~server$は、禁止された`~target資源$の現在の存在を “隠し” たいと望むときは，代わりに［
`404$st
］で応答してもヨイ。
◎
An origin server that wishes to "hide" the current existence of a forbidden target resource MAY instead respond with a status code of 404 (Not Found).
</p>

			</section>
			<section id="section-6.5.4">
<h4>6.5.4. `404^st</h4>

<p>
状態s~code `404^stは、［
`生成元~server$は、［
`~target資源$用に現在の`表現$を見出せなかった
］か, ［
~target資源が存在することを開示するつもりがない
］］ことを指示する。
`404^st0は、［
この，表現の欠如が、［
一時的, 恒久的
］のどちらなのか
］は，指示しない。
`生成元~server$が，その条件は恒久的になる見込みが高いことを
— 大概は何らかの環境設定し得る手段を通して —
知る場合、 `404^st0よりも`410$stが選好される。
◎
The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.
</p>

<p>
`404^st0 応答は、`既定で~cache可能である$。
◎
A 404 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.5.5">
<h4>6.5.5. `405^st</h4>

<p>
状態s~code `405^stは、［
`request-line$p 内に受信された~methodは、`生成元~server$に既知ではあるが，`~target資源$においては~supportされない
］ことを指示する。
`生成元~server$は、 `405^st0 応答~内に［［
~target資源にて現在~supportされる~method
］の~listを包含する， `Allow$h ~header
］を`生成し$なければナラナイ。
◎
The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.
</p>

<p>
`405^st0 応答は、`既定で~cache可能である$。
◎
A 405 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.5.6">
<h4>6.5.6. `406^st</h4>

<p>
状態s~code `406^stは、［
`~target資源$には，［
要請~内に受信された`~proactive折衝~header$に則って，~UAに受容-可能になる
］ような現在の`表現$は無い
］ことに加えて，［
~serverは、既定の表現を給するつもりがない
］ことを指示する。
◎
The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request (Section 5.3), and the server is unwilling to supply a default representation.
</p>

<p>
`~server$は、［［
利用者や~UAが その中から最も適切なものを選択できる
］ような，［
可用な表現~特性の~listと，そのそれぞれに対応する資源~識別子
］］を包含する~payloadを，`生成する$ベキである。
`~UA$は、その~listから［
最も適切な選択肢
］を自動的に選定してもヨイ。
しかしながら，`6.4.1$secにて述べたように、この仕様は，そのような自動的な選定~用の どのような標準も，定義しない。
◎
The server SHOULD generate a payload containing a list of available representation characteristics and corresponding resource identifiers from which the user or user agent can choose the one most appropriate. A user agent MAY automatically select the most appropriate choice from that list. However, this specification does not define any standard for such automatic selection, as described in Section 6.4.1.
</p>

			</section>
			<section id="section-6.5.7">
<h4>6.5.7. `408^st</h4>

<p>
状態s~code `408^stは、［
~serverは、待機するよう準備された時間~内に，要請~messageを`完全$に受信しなかった
］ことを指示する。
`~server$は、応答~内に，`~close_接続~option$を送信するベキである
— `408^st0 は［
~serverが，待機し続けずに接続を~closeすると裁定した
］ことを含意するので。
`~client$は、応答待ち要請があれば，その要請を新たな接続~上にて繰返してもヨイ。
◎
The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the "close" connection option (Section 6.1 of [RFC7230]) in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.
</p>

			</section>
			<section id="section-6.5.8">
<h4>6.5.8. `409^st</h4>

<p>
状態s~code `409^stは、［［
`~target資源$の現在の状態との競合
］に因り，要請を完了できなかった
］ことを指示する。
この~codeは、［
利用者は、競合を解決して，要請を再~提出し得る
］ような状況で利用される。
`~server$は、［
利用者が競合の~sourceを認識するに十分な情報
］を内包する~payloadを，`生成する$ベキである。
◎
The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.
</p>

<p>
競合は、［
`PUT$m 要請に対する応答
］で生じる見込みが最も高い。
例えば，`生成元~server$は、~version付けが利用されている下で［
`PUT$m している`表現$が，［
~~以前に（第三者-主体からの）要請により~~行われたもの
］と競合するような，資源への変更を含む
］場合に，［
要請を完了できないことを指示する `409^st0 応答
］を利用し得る。
この事例では、応答の`表現$は，［
改訂~履歴に基づいて相違点を併合するために有用になる情報
］を包含することになる見込みが高い。
◎
Conflicts are most likely to occur in response to a PUT request. For example, if versioning were being used and the representation being PUT included changes to a resource that conflict with those made by an earlier (third-party) request, the origin server might use a 409 response to indicate that it can't complete the request. In this case, the response representation would likely contain information useful for merging the differences based on the revision history.
</p>

			</section>
			<section id="section-6.5.9">
<h4>6.5.9. `410^st</h4>

<p>
状態s~code `410^stは、［
`~target資源$への~accessが，`生成元~server$にて もはや可用でなく、
その条件が恒久的になる見込みが高い
］ことを指示する。
`生成元~server$は、条件が恒久的になるかどうかについて判らない場合は，代わりに `404$stを利用する~OUGHT。
◎
The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.
</p>

<p>
`410^st0 応答は、首に，~web保守の~taskを支援するために意図されており、`受信者$に向けて，［
資源は意図的に可用でなくされ，~server所有者が［
その資源への~remote~linkは除去される
］ことを欲している
］ことを通知する。
そのような~eventは、臨時の販促~serviceや, ［
各個人に所属する資源が，もはや`生成元~server$の~siteに結付けられなくなったとき
］に，共通的にある。
恒久的に可用でない資源すべてを，［
“消失した” ものと~markしたり，その~markをいつまでも保つ
］ことは、必要yでない
— それは、~server所有者の裁量に~~委ねられる。
◎
The 410 response is primarily intended to assist the task of web maintenance by notifying the recipient that the resource is intentionally unavailable and that the server owners desire that remote links to that resource be removed. Such an event is common for limited-time, promotional services and for resources belonging to individuals no longer associated with the origin server's site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time -- that is left to the discretion of the server owner.
</p>

<p>
`410^st0 応答は、`既定で~cache可能である$。
◎
A 410 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.5.10">
<h4>6.5.10. `411^st</h4>

<p>
状態s~code `411^stは、［
~serverは、 `Content-Length$h が定義されてない要請の受容-を拒否した
］ことを指示する。
`~client$は、要請~message内に［
`~message本体~長さ$を包含する，妥当な `Content-Length$h ~header
］を追加した上で，要請を繰返してもヨイ。
◎
The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length (Section 3.3.2 of [RFC7230]). The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.
</p>

			</section>
			<section id="section-6.5.11">
<h4>6.5.11. `413^st</h4>

<p>
状態s~code `413^stは、［
要請の~payloadが，~serverが処理n［
する用意がある／できる
］ものより巨大なため、~serverは 要請を処理するのを拒否している
］ことを指示する。
`~server$は、`~client$に要請を継続させないように，接続を~closeしてもヨイ。
◎
The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.
</p>

<p>
条件が一時的である場合，`~server$は、
`Retry-After$h ~headerを`生成し$て，条件が一時的であること, および~clientが いつ再び試行してよいかを指示するベキである。
◎
If the condition is temporary, the server SHOULD generate a Retry-After header field to indicate that it is temporary and after what time the client MAY try again.
</p>

			</section>
			<section id="section-6.5.12">
<h4>6.5.12. `414^st</h4>

<div class="p">

<p>
状態s~code `414^stは、［
`request-target$p が［
~serverが解釈する用意がある~~長さ
］より長いため、~serverは 要請に対する~serviceを拒否している
］ことを指示する。
この稀な条件が生じるのは、ほぼ，次のときに限られる：
◎
The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target (Section 5.3 of [RFC7230]) is longer than the server is willing to interpret. This rare condition is only likely to occur＼
</p>

<ul>
	<li>
~clientが `POST$m 要請を，不適正に，長い `query$p 情報を伴う `GET$m 要請に変換した。
◎
when a client has improperly converted a POST request to a GET request with long query information,＼
</li>
	<li>
~clientが~redirectionの “無限loop” に陥った（例：
~URI接頭辞の~redirect先が，接頭辞~自身に接尾辞を付加したものになっている）。
◎
when the client has descended into a "black hole" of redirection (e.g., a redirected URI prefix that points to a suffix of itself) or＼
</li>
	<li>
~clientが~~可能性のある~securityの穴を悪用しようと，~serverを攻撃している。
◎
when the server is under attack by a client attempting to exploit potential security holes.
</li>
</ul>
</div>

<p>
`414^st0 応答は、`既定で~cache可能である$。
◎
A 414 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.5.13">
<h4>6.5.13. `415^st</h4>

<p>
状態s~code `415^stは、［
`~target資源$上では，［
要請の~payloadは，要請の~methodにより~supportされる形式ではない
］ため、`生成元~server$は 要請に対する~serviceを拒否している
］ことを指示する。
形式の問題は、［
要請が指示した `Content-Type$h ／ `Content-Encoding$h
］に因ることもあれば, ［
要請の~dataを直に検分した結果
］に因ることもある。
◎
The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.
</p>

			</section>
			<section id="section-6.5.14">
<h4>6.5.14. `417^st</h4>

<p>
状態s~code `417^stは、［
`内方$にある いずれかの~serverにて，［
要請の `Expect$h ~header内に与えられた`期待$
］に応えられなかった
］ことを指示する。
◎
The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field (Section 5.1.1) could not be met by at least one of the inbound servers.
</p>

			</section>
			<section id="section-6.5.15">
<h4>6.5.15. `426^st</h4>

<p>
状態s~code `426^stは、［
~serverは、［
現在の~protocolの下では，要請の遂行-を拒否した
］が，［
~clientが異なる~protocolに昇格した後には，その用意がある
］であろう
］ことを指示する。
`~server$は、 `426^st0 応答~内に［
要求される~protocol（たち）を指示する， `Upgrade$h ~header
］を送信しなければナラナイ。
◎
The 426 (Upgrade Required) status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s) (Section 6.7 of [RFC7230]).
</p>

<div class="example">
<p>
例：
◎
Example:
</p>

<pre class="lang-http">
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/3.0
Connection: Upgrade
Content-Length: 53
Content-Type: text/plain

This service requires use of the HTTP/3.0 protocol.
</pre>

</div>

			</section>
		</section>
		<section id="section-6.6">
<h3 title="Server Error 5xx">6.6. ~server~error： `5xx^st0</h3>

<p>
`応答class$ `5xx^st の`状態s~code$は、［
~serverは、［
自身の~errorを自覚した
］または［
要請された~methodを遂行する能力を備えていない
］］ことを指示する。
【！複製】
`HEAD$m 要請に対し応答するときを除いて、`~server$は，［［
その~error状況の説明，および
その条件は［
一時的, 恒久的
］のどちらなのか
］を包含している`表現$
］を送信するベキである。
`~UA$は、内包された表現があれば，それを利用者に表示するベキである。
これらの状態s~codeは、どの`要請~method$にも適用-可能である。
◎
The 5xx (Server Error) class of status code indicates that the server is aware that it has erred or is incapable of performing the requested method. Except when responding to a HEAD request, the server SHOULD send a representation containing an explanation of the error situation, and whether it is a temporary or permanent condition. A user agent SHOULD display any included representation to the user. These response codes are applicable to any request method.
</p>

			<section id="section-6.6.1">
<h4>6.6.1. `500^st</h4>

<p>
状態s~code `500^stは、［
~serverは、予期しない条件に遭遇して，要請を履行できなくなった
］ことを指示する。
◎
The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.
</p>

			</section>
			<section id="section-6.6.2">
<h4>6.6.2. `501^st</h4>

<p>
状態s~code `501^stは、［
~serverは、要請を履行するために要求される機能性を~supportしない
］ことを指示する。
これは、［
~serverは、`要請~method$を認識せず，どの資源も それを~supportする能力を備えていない
］ときに適切な応答になる。
◎
The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.
</p>

<p>
`501^st0 応答は、`既定で~cache可能である$。
◎
A 501 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see Section 4.2.2 of [RFC7234]).
</p>

			</section>
			<section id="section-6.6.3">
<h4>6.6.3. `502^st</h4>

<p>
状態s~code `502^stは、［［
`~gateway$／`~proxy$
］として動作している~serverが、要請を履行しようと試みているときに，自身が~accessした`内方$~serverから妥当でない応答を受信した
］ことを指示する。
◎
The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.
</p>

			</section>
			<section id="section-6.6.4">
<h4>6.6.4. `503^st</h4>

<p>
状態s~code `503^stは、［
~serverは、［
いくばくかの遅延~後に緩和される見込みが高いような，一時的な過負荷 または~scheduleされた保守
］に因り，現在 要請を取扱えない
］ことを指示する。
`~server$は、 `Retry-After$h ~headerを送信して，［
~clientが要請を再試行する前に待機する，~~適量な時間
］を示唆してもヨイ。
◎
The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field (Section 7.1.3) to suggest an appropriate amount of time for the client to wait before retrying the request.
</p>

<p class="note">注記：
状態s~code `503^st0の存在は、［
過負荷~時には，その利用が~serverに要求される
］ことを含意するわけではない。
単純に接続を拒否する~serverもあり得る。
◎
Note: The existence of the 503 status code does not imply that a server has to use it when becoming overloaded. Some servers might simply refuse the connection.
</p>

			</section>
			<section id="section-6.6.5">
<h4>6.6.5. `504^st</h4>

<p>
状態s~code `504^stは、［［
`~gateway$／`~proxy$
］として動作している~serverが，［
要請を完了するために~accessする必要がある，`上流$~server
］から適時に応答を受信できなかった
］ことを指示する。
◎
The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.
</p>

			</section>
			<section id="section-6.6.6">
<h4>6.6.6. `505^st</h4>

<p>
状態s~code `505^stは、［
~serverは、［
要請~message内に利用された~HTTP`~major~version$
］を~supportしない／~supportを拒否した
］ことを指示する。
~serverは、［
~clientと同じ~major~versionを利用するどの要請も，この~error~message以外では 完了できない／するつもりがない
］ことを指示している（ `7230-2.6$rfcを見よ）。
`~server$は、 `505^st0 応答に対しては，［
その~versionが何故~supportされないか, および
自身が~supportする他の~protocol
］について述べる`表現$を`生成する$ベキである。
◎
The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described in Section 2.6 of [RFC7230], other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.
</p>

			</section>
		</section>
	</section>
	<section id="section-7">
<h2 title="Response Header Fields">7. 応答~header</h2>

<p>
`応答~header^dfn
により、~serverは［
`status-line$p 内に置かれたもの以上の，応答についての追加的な情報
］を渡せるようになる。
これらの~headerは、［
~server ／ `~target資源$への更なる~access ／ 関係する資源
］についての情報を与える。
◎
The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the target resource, or about related resources.
</p>

<p>
各種 `応答~header$は，それ自身に定義される意味を持つが、一般に，精確な意味論は［
`要請~method$や`応答~状態s~code$の意味論
］により更に精緻化され得る。
◎
Although each response header field has a defined meaning, in general, the precise semantics might be further refined by the semantics of the request method and/or response status code.
</p>

		<section id="section-7.1">
<h3 title="Control Data">7.1. 制御~data</h3>

<p>
次に挙げる`応答~header$は、［
状態s~codeを補足する ／
~cachingを指令する ／
~clientに次へ行く所を指図する
］ような
`制御~data^dfn
を給せる：
◎
Response header fields can supply control data that supplements the status code, directs caching, or instructs the client where to go next.
</p>

<div>
<ul><li>`Cache-Control$h
</li><li>`Expires$h
</li><li>`Date$h
</li><li>`Location$h
</li><li>`Retry-After$h
</li><li>`Vary$h
</li><li>`Warning$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | Age               | Section 5.1 of [RFC7234] |
   | Cache-Control     | Section 5.2 of [RFC7234] |
   | Expires           | Section 5.3 of [RFC7234] |
   | Date              | Section 7.1.1.2          |
   | Location          | Section 7.1.2            |
   | Retry-After       | Section 7.1.3            |
   | Vary              | Section 7.1.4            |
   | Warning           | Section 5.5 of [RFC7234] |
   +-------------------+--------------------------+
</pre>

</div>

			<section id="section-7.1.1">
<h4 title="Origination Date">7.1.1. 出生日時</h4>

				<section id="section-7.1.1.1">
<h5 title="Date/Time Formats">7.1.1.1. 日付時刻の形式</h5>

<p>
1995 年 より前までは、時刻印を通信するときに， 3 種の形式が~serverで共通的に利用されていた。
古い実装との互換性のため、その 3 種すべては，ここに定義される。
選好される形式は、［
Internet Message Format `5322$Rにて利用されている，日付時刻の仕様
］による，固定長で単-時間帯の~subset（ `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>
Sun, 06 Nov 1994 08:49:37 GMT    ; IMF-fixdate
</pre>

<p>
2 種の廃用~形式の，例：
◎
Examples of the two obsolete formats are
</p>

<pre>
Sunday, 06-Nov-94 08:49:37 GMT   ; obsolete `850$R format
Sun Nov  6 08:49:37 1994         ; ANSI C's asctime() format
</pre>

</div>

<p>
~HTTP~header内の時刻印 値を構文解析する`受信者$は、 3 種の `HTTP-date$p 形式すべてを受容しなければナラナイ。
`送信者$が［
`HTTP-date$p による時刻印を包含する~header
］を`生成する$ときは、
`IMF-fixdate$p 形式による時刻印を`生成し$なければナラナイ。
◎
A recipient that parses a timestamp value in an HTTP header field MUST accept all three HTTP-date formats. When a sender generates a header 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 ）の~instance
］として表現する。
最初の 2 種の形式は、［
~UTC名の前身である， Greenwich Mean Time （グリニッジ平均時）の頭字語 “GMT”
］による~UTCを指示する
— ［
`asctime^p 形式~内の値
］は~UTCであるものと見做される。
局所的な時計から `HTTP-date$p 値を`生成する$`送信者$は、その時計を~UTCと同期させるため，
NTP （`5905$R）または 何らかの類似な~protocolを利用する~OUGHT。
◎
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. A sender that generates HTTP-date values from a local clock ought to use NTP ([RFC5905]) or some similar protocol to synchronize its clock to 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" title="fixed length/zone/capitalization subset of the format">形式のうち，固定的な［ 長さ／時間帯／大文字頭字 ］による~subset</span>
; <span class="comment">`5322-3.3$rfc を見よ</span>

`day-name@p
	= %x4D.6F.6E ; "Mon"`, 文字大小区別, 以下同様^com
	/ %x54.75.65 ; "Tue"
	/ %x57.65.64 ; "Wed"
	/ %x54.68.75 ; "Thu"
	/ %x46.72.69 ; "Fri"
	/ %x53.61.74 ; "Sat"
	/ %x53.75.6E ; "Sun"

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

`day@p
	= 2DIGIT
`month@p
	= %x4A.61.6E ; "Jan"`, 文字大小区別, 以下同様^com
	/ %x46.65.62 ; "Feb"
	/ %x4D.61.72 ; "Mar"
	/ %x41.70.72 ; "Apr"
	/ %x4D.61.79 ; "May"
	/ %x4A.75.6E ; "Jun"
	/ %x4A.75.6C ; "Jul"
	/ %x41.75.67 ; "Aug"
	/ %x53.65.70 ; "Sep"
	/ %x4F.63.74 ; "Oct"
	/ %x4E.6F.76 ; "Nov"
	/ %x44.65.63 ; "Dec"
`year@p
	= 4DIGIT

`GMT@p
	= %x47.4D.54 ; "GMT"`, 文字大小区別^com

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

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

【！Errata 4232 Rejected】

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

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

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

`day-name-l@p

	= %x4D.6F.6E.64.61.79          ; "Monday"`, 文字大小区別, 以下同様^com
	/ %x54.75.65.73.64.61.79       ; "Tuesday"
	/ %x57.65.64.6E.65.73.64.61.79 ; "Wednesday"
	/ %x54.68.75.72.73.64.61.79    ; "Thursday"
	/ %x46.72.69.64.61.79          ; "Friday"
	/ %x53.61.74.75.72.64.61.79    ; "Saturday"
	/ %x53.75.6E.64.61.79          ; "Sunday"

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

<p>
`HTTP-date$p は文字大小区別である。
`送信者$は、 `HTTP-date$p 内に，［
文法~内に `SP$P として特に内包されたもの
］以外の 余計な`空白$を`生成し$てはナラナイ。
［
`day-name$p, `day$p, `month$p, `year$p, `time-of-day$p
］の意味論は、 Internet Message Format 構成子に定義される，対応する名前のものと同じである （`5322-3.3$rfc）。
◎
HTTP-date is case sensitive. 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>
［
2 桁~年を利用する， `rfc850-date$p 形式による時刻印 値
］の`受信者$は、［
50 年より先の未来として出現する時刻印
］を，［
最後の 2 桁が同じ，【！past】最も近過去の年
］を表現しているものと解釈しなければナラナイ。
◎
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>
時刻印 値の`受信者$には、~header定義により制約されない限り，時刻印の構文解析において堅牢であることが奨励される。
例えば，~messageは、ときには［［
Internet Message Format により定義される，いずれかの日付時刻 指定
］を生成し得るような，非~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 the date/time stamp format 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 id="section-7.1.1.2">
<h5>7.1.1.2. `Date^h</h5>

<p>
`Date^h ~headerは、~messageが
<dfn id="origination-date">出生した日付時刻</dfn>
を表現する
— その意味論は、 `5322-3.6.1$rfcにて定義される Origination Date Field（ `orig-date^p ）と同じである。
~header値は、 `HTTP-date$p である。
◎
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 7.1.1.1.
</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を`生成する$ときは，
その~header値として［
~message生成の日付時刻に可用な，最良な近似
］を`生成する$ベキである。
理論~上は、日時は，~payloadが`生成され$る~~直前の瞬間を表現する~OUGHT。
実施~上は、日時は，~message出生時の間の任意の時点に`生成され$得る。
◎
When a Date header field is generated, the sender 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 the payload is generated. In practice, the date can be generated at any time during message origination.
</p>

<p>
`時計@
— ~UTCによる~~現在時の適度な近似を供する時計 —
を備えていない`生成元~server$は、
`Date^h ~headerを送信してはナラナイ。
生成元~serverは、`応答~状態s~code$の`応答class$が［
`1xx$st ／ `5xx$st
］である場合， `Date^h ~headerを送信してもヨイ
— 他のすべての事例では， `Date^h ~headerを送信しなければナラナイ。
◎
An origin server MUST NOT send a Date header field if it does not have a clock capable of providing a reasonable approximation of the current instance in Coordinated Universal Time. An origin server MAY send a Date header field if the response is in the 1xx (Informational) or 5xx (Server Error) class of status codes. An origin server MUST send a Date header field in all other cases.
</p>

<p>
`時計$を備えている`受信者$が，［
`Date^h ~headerを伴わない応答~messageを受信した
］ときは、それを［
~cacheする／下流へ回送する
］ときには，受信した時刻を記録して，~messageの`~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.
</p>

<p>
`~UA$は、要請~内に `Date^h ~headerを送信してもヨイ
— 一般には，~serverにとって有用な情報を伝達するものと予見される場合に限られるが。
例えば，~HTTPの~custom~appは、［
~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>
			<section id="section-7.1.2">
<h4>7.1.2. `Location^h</h4>

<p>
`Location^h ~headerは、［
応答に関係する特定の資源を指す
］ために，一部の応答~内にて利用される。
関係性の型は、［
`要請~method$, `状態s~code$
］の意味論の組合nで定義される。
◎
The "Location" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.
</p>

<pre class="bnf">
`Location@p
	= `URI-reference$p
</pre>

<p>
~header値は、単独の `URI-reference$p からなる。
値が`相対~参照$（`3986-4.2$rfc）の形をとるときの，最終~値は、`実効~要請~URI$ （`3986-5$rfc）に対し解決して，算出される。
◎
The field value consists of a single URI-reference. When it has the form of a relative reference ([RFC3986], Section 4.2), the final value is computed by resolving it against the effective request URI ([RFC3986], Section 5).
</p>

<p>
`Location^h 値は、
`201$st 応答に対しては，［
要請により作成された
`首な資源@
］を指し、
`3xx$st 応答に対しては，［
要請を自動的に~redirectするときに選好される`~target資源$
］を指す。
◎
For 201 (Created) responses, the Location value refers to the primary resource created by the request. For 3xx (Redirection) responses, the Location value refers to the preferred target resource for automatically redirecting the request.
</p>

<p>
`3xx$st 応答~内に供される `Location^h 値に 素片~成分（ `fragment$p ）がない場合、`~UA$は，~redirectionを［
その値が［
`要請~target$を`生成する$際に利用した~URI参照の素片~成分
］を継承している
］かのように処理しなければナラナイ（すなわち，~redirectionは、元の参照の素片があれば，それを継承する）。
◎
If the Location value provided in a 3xx (Redirection) response does not have a fragment component, a user agent MUST process the redirection as if the value inherits the fragment component of the URI reference used to generate the request target (i.e., the redirection inherits the original reference's fragment, if any).
</p>

<div class="example">
<p>
例えば、［
~URI参照 "`http://www.example.org/~tim^c" に対し`生成され$た `GET$m 要請
］の結果が，次の~headerを包含する `303$st 応答になるならば：
◎
For example, a GET request generated for the URI reference "http://www.example.org/~tim" might result in a 303 (See Other） response containing the header field:
</p>

<pre class="lang-http">
Location: /People.html#tim
</pre>

<p>
これは、~UAが
"`http://www.example.org/People.html#tim^c"
へ~redirectすることを示唆する。
◎
which suggests that the user agent redirect to "http://www.example.org/People.html#tim"
</p>

<p>
同様に、［
~URI参照 "`http://www.example.org/index.html#larry^c" に対し`生成され$た `GET$m 要請
］の結果が，次の~headerを包含する `301$st 応答になるならば：
◎
Likewise, a GET request generated for the URI reference "http://www.example.org/index.html#larry" might result in a 301 (Moved Permanently) response containing the header field:
</p>

<pre class="lang-http">
Location: http://www.example.net/index.html
</pre>

<p>
これは、~UAが，元の`素片~識別子$を保全して
"`http://www.example.net/index.html#larry^c"
へ~redirectすることを示唆する。
◎
which suggests that the user agent redirect to "http://www.example.net/index.html#larry", preserving the original fragment identifier.
</p>
</div>

<p>
`Location^h 値~内の素片~識別子が，適切でなくなる状況もある：
例えば，［
`201$st 応答~内の `Location^h ~header
］は、［
作成された資源に特有な~URI
］を供するものと想定されている。
◎
There are circumstances in which a fragment identifier in a Location value would not be appropriate. For example, the Location header field in a 201 (Created) response is supposed to provide a URI that is specific to the created resource.
</p>

<p class="note">注記：
一部の`受信者$は、［
`Location^h ~headerの~URI参照が妥当でない
］ときに，その回復を試みる。
この仕様は，そのような処理を義務化したり定義しないが、堅牢性の~~目的で，それを許容する。
◎
Note: Some recipients attempt to recover from Location fields that are not valid URI references. This specification does not mandate or define such processing, but does allow it for the sake of robustness.
</p>

<p class="note">注記：
`Content-Location$h ~headerは、それが［
同封された`表現$に対応する最も特定な資源
］を指す点で， `Location^h から相違する。
したがって、応答が `Location^h, `Content-Location$h 両~headerを包含することもアリである。
◎
Note: The Content-Location header field (Section 3.1.4.2) differs from Location in that the Content-Location refers to the most specific resource corresponding to the enclosed representation. It is therefore possible for a response to contain both the Location and Content-Location header fields.
</p>

			</section>
			<section id="section-7.1.3">
<h4>7.1.3. `Retry-After^h</h4>

<p>
~serverは、［
~UAが後継の要請を為す前に，どのくらい長く待機する~OUGHT
］かを指示するために， `Retry-After^h ~headerを送信する。
［
`503$st 応答に伴って送信されてきた `Retry-After^h
］は、［
~serviceが~clientに可用でないと予期される~~長さ
］を指示する。
［
`3xx$st 応答に伴って送信されてきた `Retry-After^h
］は、［
~UAが~redirect要請を発行する前に，~UAに待機するよう依頼する最短な時間
］を指示する。
◎
Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request. When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client. When sent with any 3xx (Redirection) response, Retry-After indicates the minimum time that the user agent is asked to wait before issuing the redirected request.
</p>

<p>
この~headerの値は、 `HTTP-date$p, または［
応答を受信した後の遅延~秒数
］のいずれかをとる。
◎
The value of this field can be either an HTTP-date or a number of seconds to delay after the response is received.
</p>

<pre class="bnf">
`Retry-After@p
	= `HTTP-date$p
	/ `delay-seconds$p
</pre>

<p>
`delay-seconds$p 値は、秒数を表現する負でない~decimal整数である。
◎
A delay-seconds value is a non-negative decimal integer, representing time in seconds.
</p>

<pre class="bnf">
`delay-seconds@p
	= 1*`DIGIT$P
</pre>

<div class="example">
<p>
その利用~例：
◎
Two examples of its use are
</p>

<pre class="lang-http">
Retry-After: Fri, 31 Dec 1999 23:59:59 GMT
Retry-After: 120
</pre>

<p>
後者の遅延は 2 分間になる。
◎
In the latter example, the delay is 2 minutes.
</p>
</div>

			</section>
			<section id="section-7.1.4">
<h4>7.1.4. `Vary^h</h4>

<p>
応答~内の `Vary^h ~headerは、［
~method／ `Host$h ~header／`要請~target$
］の他に，要請~messageのどの部分が［
`生成元~server$による，この応答を選定して表現する処理n
］に波及し得た（し得る）かを述べる。
`~header値$は、［
1 個の~asterisk （"`*^c"）
］または［
何個かの`~header名$（文字大小無視）からなる~list
］のいずれかをとる：
◎
The "Vary" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response. The value consists of either a single asterisk ("*") or a list of header field names (case-insensitive).
</p>

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

<p>
`Vary^h ~headerに対する値 "`*^c" は、要請のあらゆる部分
— 場合によっては ~message構文の外側の要素も含む（例：~clientの~network~address） —
が，応答の`表現$を選定する役割を担い得た（担い得る）ことを通達する。
`受信者$は、［
この応答が，今後の【同じ】要請にも適切になるかどうか
］を［
要請を`生成元~server$に回送しない限り決定できない
］ことになる。
【したがって、そのような応答は~cacheしても無意味になる。】
`~proxy$は、値に "`*^c" をとる `Vary^h ~headerを，`生成し$てはナラナイ。
◎
A Vary field value of "*" signals that anything about the request might play a role in selecting the response representation, possibly including elements outside the message syntax (e.g., the client's network address). A recipient will not be able to determine whether this response is appropriate for a later request without forwarding the request to the origin server. A proxy MUST NOT generate a Vary field with a "*" value.
</p>

<p>
`Vary^h ~headerに対する ~commaで分離された名前の~listによる値は、［
~listされた名前の`要請~header$
— これらは
`選定用~header@
と呼ばれる —
が，`表現$を選定する役割を担い得た（担い得る）
］ことを指示する。
選定用~headerになり得る~headerは、この仕様で定義されるものに制限されない。
◎
A Vary field value consisting of a comma-separated list of names indicates that the named request header fields, known as the selecting header fields, might have a role in selecting the representation. The potential selecting header fields are not limited to those defined by this specification.
</p>

<div class="example">
<p>
例えば，次を包含する応答は：
◎
For example, a response that contains
</p>

<pre class="lang-http">
Vary: accept-encoding, accept-language
</pre>

<p>
`生成元~server$が、この応答に対する内容を選択する決定要因として，要請の［
`Accept-Encoding$h, `Accept-Language$h
］~header（または それらの欠如）を利用したかもしれないことを，指示する。
◎
indicates that the origin server might have used the request's Accept-Encoding and Accept-Language fields (or lack thereof) as determining factors while choosing the content for this response.
</p>

</div>

<p>
`生成元~server$が［
~header名の~listを伴う `Vary^h
］を送信する目的には、次の 2 つがあり得る：
◎
An origin server might send Vary with a list of fields for two purposes:
</p>

<ul>
	<li>
<p>
~cache受信者たちに，次のことを伝える
⇒
今後の要請において、その要請が［
~listされた~headerについて，元の要請と同じ値（`7234-4.1$rfc）をとる
］のでない限り，この応答を その要請を充足するために利用してはナラナイ。
</p>
<p>
言い換えれば `Vary^h は、［
新たな要請が，格納-済みな~cache~entryに合致する
］ために要求される~cache~keyを拡げる。
</p>
◎
1. To inform cache recipients that they MUST NOT use this response to satisfy a later request unless the later request has the same values for the listed fields as the original request (Section 4.1 of [RFC7234]). In other words, Vary expands the cache key required to match a new request to the stored cache entry.
</li>
	<li>
~UA受信者に，次のことを伝える
⇒
この応答は`内容~折衝$の~subjectであり、~listされたいずれかの~header内に 追加的な~parameterが供される場合（`~proactive折衝$）には，後続な要請に対し異なる`表現$が送信され得る。
◎
2. To inform user agent recipients that this response is subject to content negotiation (Section 5.3) and that a different representation might be sent in a subsequent request if additional parameters are provided in the listed header fields (proactive negotiation).
</li>
</ul>

<div class="p">

<p>
`生成元~server$は、［
自身による，`表現$を選定する~algo
］が［
要請~messageの，~methodや`要請~target$以外の側面
］に基づいて変動するときには， `Vary^h ~headerを送信するベキである
— ただし，
その変動が cross し得ないとき 【次の最初の例】 , あるいは［
生成元~serverが，~cache透過性を防止するように，故意に環境設定されている
］ときは除く — 例えば：
◎
An origin server SHOULD send a Vary header field when its algorithm for selecting a representation varies based on aspects of the request message other than the method and request target, unless the variance cannot be crossed or the origin server has been deliberately configured to prevent cache transparency. For example,＼
</p>

<ul>
	<li>
`~header名$ `Authorization$h は、［
その定義により，複数~利用者にまたがる再利用が拘束される
］ことから， `Vary^h 内に送信する必要はない。
◎
there is no need to send the Authorization field name in Vary because reuse across users is constrained by the field definition (Section 4.2 of [RFC7235]).＼
</li>
	<li>
同様に，生成元~serverは、［
変動よりも， `Vary^h による~cachingの処理能~costへの影響iの方が，有意である
］と見なす場合は，［
`Vary^h に代えて， `Cache-Control$h 指令を利用する
］かもしれない。
◎
Likewise, an origin server might use Cache-Control directives (Section 5.2 of [RFC7234]) to supplant Vary if it considers the variance less significant than the performance cost of Vary's impact on caching.
</li>
</ul>
</div>

			</section>
		</section>
		<section id="section-7.2">
<h3 title="Validator Header Fields">7.2. 検証子~header</h3>

<p>
下に挙げる
`検証子~header^dfn
は、［
`選定された表現$についての~metadata
］を伝達する。
◎
Validator header fields convey metadata about the selected representation (Section 3).＼
</p>

<p>
［
`安全な$要請に対する応答
］内の検証子~headerは、［
応答の取扱い中に，`生成元~server$により選択され, `選定された表現$
］について述べる。
`状態s~code$の意味論に依存して、必ずしも［
所与の応答において`選定された表現$が，その応答の~payloadに同封されている表現と同じになる
］とは限らないことに注意。
◎
In responses to safe requests, validator fields describe the selected representation chosen by the origin server while handling the response. Note that, depending on the status code semantics, the selected representation for a given response is not necessarily the same as the representation enclosed as response payload.
</p>

<p>
［
状態変更 要請に対する成功裡な応答
］内の`検証子~header$は、［
その要請を処理した結果
］として，［［
それに先立って`選定された表現$
］を置換する，新たな`表現$
］について述べる。
◎
In a successful response to a state-changing request, validator fields describe the new representation that has replaced the prior selected representation as a result of processing the request.
</p>

<p>
例えば，［
`201$st 応答~内の `ETag$h ~header
］は、 “更新喪失” 問題を防止するため，［
新たに作成された資源の表現~用の `entity-tag$p
］を通信して、それを今後の`条件付き要請$内に利用できるようにする。
◎
For example, an ETag header field in a 201 (Created) response communicates the entity-tag of the newly created resource's representation, so that it can be used in later conditional requests to prevent the "lost update" problem [RFC7232].
</p>

<div>
<ul><li>`ETag$h
</li><li>`Last-Modified$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | ETag              | Section 2.3 of [RFC7232] |
   | Last-Modified     | Section 2.2 of [RFC7232] |
   +-------------------+--------------------------+
</pre>

</div>

		</section>
		<section id="section-7.3">
<h3 title="Authentication Challenges">7.3. 認証~challenge</h3>

<p>
認証~challengeは、［［
未来の要請において認証用の`資格証$を供する仕組み
］として，~clientに可用になるもの
］を指示する：
◎
Authentication challenges indicate what mechanisms are available for the client to provide authentication credentials in future requests.
</p>

<div>
<ul><li>`WWW-Authenticate$h
</li><li>`Proxy-Authenticate$h
</li></ul>

<pre lang="en" class="_en">
   +--------------------+--------------------------+
   | Header Field Name  | Defined in...            |
   +--------------------+--------------------------+
   | WWW-Authenticate   | Section 4.1 of [RFC7235] |
   | Proxy-Authenticate | Section 4.3 of [RFC7235] |
   +--------------------+--------------------------+
</pre>

</div>

		</section>
		<section id="section-7.4">
<h3 title="Response Context">7.4. 応答の文脈</h3>

<p>
残りの`応答~header$は、今後の要請にあり得る利用のために，［
`~target資源$についての更なる情報
］を供する：
◎
The remaining response header fields provide more information about the target resource for potential use in later requests.
</p>

<div>
<ul><li>`Accept-Ranges$h
</li><li>`Allow$h
</li><li>`Server$h
</li></ul>

<pre lang="en" class="_en">
   +-------------------+--------------------------+
   | Header Field Name | Defined in...            |
   +-------------------+--------------------------+
   | Accept-Ranges     | Section 2.3 of [RFC7233] |
   | Allow             | Section 7.4.1            |
   | Server            | Section 7.4.2            |
   +-------------------+--------------------------+
</pre>

</div>

			<section id="section-7.4.1">
<h4>7.4.1. `Allow^h</h4>

<p>
`Allow^h ~headerは、［
`~target資源$が~supportするものとして広告される，~methodの集合
］を~listする。
この~headerの目的は、［
資源に結付けられた妥当な`要請~method$
］を`受信者$に厳密に伝えることである。
◎
The "Allow" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.
</p>

<pre class="bnf">
`Allow@p
	= #`method$p
</pre>

<div class="example">
<p>
利用~例：
◎
Example of use:
</p>

<pre class="lang-http">
Allow: GET, HEAD, PUT
</pre>

</div>

<p>
許容される~methodの実際の集合は、各~要請の時点で，`生成元~server$により定義される。
`生成元~server$は、 `405$st 応答~内には， `Allow^h ~headerを`生成し$なければナラナイ。
また、他のどの応答~内にも`生成し$てヨイ。
値が空な `Allow^h ~headerは、［
資源がどの~methodも許容しない
］ことを指示する
— それは、［
資源が環境設定により一時的に不能化されている
］場合に `405$st0 応答~内に生じ得る。
◎
The actual set of allowed methods is defined by the origin server at the time of each request. An origin server MUST generate an Allow field in a 405 (Method Not Allowed) response and MAY do so in any other response. An empty Allow field value indicates that the resource allows no methods, which might occur in a 405 response if the resource has been temporarily disabled by configuration.
</p>

<p>
`~proxy$は、 `Allow^h ~headerを改変してはナラナイ
— 汎用~message取扱い規則に則って取扱うときは、値の中に指示された すべての~methodを解する必要はない。
◎
A proxy MUST NOT modify the Allow header field -- it does not need to understand all of the indicated methods in order to handle them according to the generic message handling rules.
</p>

			</section>
			<section id="section-7.4.2">
<h4>7.4.2. `Server^h</h4>

<div class="p">

<p>
`Server^h ~headerは、［
`生成元~server$が，要請を取扱うために利用している~software
］についての情報を包含する
— それは、次のために，~clientに利用されることが多い：
◎
The "Server" header field contains information about the software used by the origin server to handle the request, which is often used by clients＼
</p>

<ul>
	<li>
報告された相互運用能の問題の対象範囲を絞り込むための補助。
◎
to help identify the scope of reported interoperability problems,＼
</li>
	<li>
特定0の~server制限を避けるために，対処する／要請を誂える
◎
to work around or tailor requests to avoid particular server limitations, and＼
</li>
	<li>
［
~server／ OS
］の利用に関する解析。
◎
for analytics regarding server or operating system use.＼
</li>
</ul>

<p>
`生成元~server$は、自身の応答~内に `Server^h ~headerを`生成し$てヨイ。
◎
An origin server MAY generate a Server field in its responses.
</p>

</div>

<pre class="bnf">
`Server@p
	= `product$p *( `RWS$p ( `product$p / `comment$p ) )
</pre>

<p>
`Server^h `~header値$は、 1 個~以上の［
`製品~識別子$と,
後続する 0 個以上の `comment$p
］からなる。
それらは組で，［
生成元~server~software, および その有意な下位製品
］を識別する。
慣行により，製品~識別子は、生成元~server~softwareを識別するために［
それらの有意度の降順
］で~listされる。
各~製品~識別子は、`5.5.3$secにて定義されるように，名前, および~version（省略可能）からなる。
◎
The Server field-value consists of one or more product identifiers, each followed by zero or more comments (Section 3.2 of [RFC7230]), which together identify the origin server software and its significant subproducts. By convention, the product identifiers are listed in decreasing order of their significance for identifying the origin server software. Each product identifier consists of a name and optional version, as defined in Section 5.5.3.
</p>

<div class="example">
<p>
例：
◎
Example:
</p>

<pre class="lang-http">
Server: CERN/3.0 libwww/2.17
</pre>

</div>

<p>
`生成元~server$は、［
~~不必要に木目細かな詳細を包含する `Server^h ~header
］を`生成する$ベキでない。
また、［
第三者-主体による下位製品の追加
］を制限するベキである。
~~過度に長く詳細な `Server^h `~header値$は、応答の待時間を増大させる。
また，内部~実装の詳細を露呈する~~可能性もあるので、攻撃者にとっては（少しばかり，）既知な~securityの穴を見出して悪用し易くなる。
◎
An origin server SHOULD NOT generate a Server field containing needlessly fine-grained detail and SHOULD limit the addition of subproducts by third parties. Overly long and detailed Server field values increase response latency and potentially reveal internal implementation details that might make it (slightly) easier for attackers to find and exploit known security holes.
</p>

			</section>
		</section>
	</section>
	<section id="section-8">
<h2 title="IANA Considerations">8. IANA 考慮点</h2>

		<section id="section-8.1">
<h3 title="Method Registry">8.1. ~method~registry</h3>

<p>
`要請~method$~token用の名前空間は、新たに作成された
`Hypertext Transfer Protocol (HTTP) Method Registry＠~IANA-a/http-methods$
（ HTTP ~method~registry）
にて保守され，定義される。
◎
The "Hypertext Transfer Protocol (HTTP) Method Registry" defines the namespace for the request method token (Section 4). The method registry has been created and is now maintained at &lt;http://www.iana.org/assignments/http-methods&gt;.
</p>

			<section id="section-8.1.1">
<h4 title="Procedure">8.1.1. 手続-</h4>

<p>
~HTTP~method登録は、次の~fieldを内包しなければナラナイ：
◎
HTTP method registrations MUST include the following fields:
</p>

<ul>
	<li>
~method名（`4$sec）
◎
• Method Name (see Section 4)
</li>
	<li>
`安全$かどうか（ "yes" または "no" ）
◎
• Safe ("yes" or "no", see Section 4.2.1)
</li>
	<li>
`冪等$かどうか（ "yes" または "no" ）
◎
• Idempotent ("yes" or "no", see Section 4.2.2)
</li>
	<li>
仕様~textへの~pointer
◎
• Pointer to specification text
</li>
</ul>

<p class="trans-note">【
`5300$errataに報告あり（ Reported: 2018-03-24 ）：
上の~listには、［
`~cache可能$かどうか（ "yes" または "no" ）
］の~fieldも含めるべき。
それに伴い、 `8.1.3$secの表にも “~cache可能？” の列を追加する（具体的な yes/no は参照先に）。
】</p>

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

			</section>
			<section id="section-8.1.2">
<h4 title="Considerations for New Methods">8.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の構文解析（`7230-3.3$rfc）は，［
（ `HEAD$m に対する応答は別として）~methodの意味論に依存しない必要がある
］ので、新たな~methodの定義は，要請, 応答いずれの~messageにおいても，構文解析~algoを変更したり, ~message本体が在ることを禁制できない。
新たな~methodの定義は、［
`Content-Length$h ~headerの値に "`0^c" を要求する
］ことにより，［
長さ 0 の`~message本体$のみが許容される
］ように指定できる。
◎
Since message parsing (Section 3.3 of [RFC7230]) 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 a message body on either the request or the response message. Definitions of new methods can specify that only a zero-length message body is allowed by requiring a Content-Length header field with a value of "0".
</p>

<div class="p">

<p>
新たな~method定義は、次を指示する必要がある：
◎
A new method definition needs to indicate＼
</p>

<ul>
	<li>
`安全$か？
`冪等$か？
`~cache可能$か？
◎
whether it is safe (Section 4.2.1), idempotent (Section 4.2.2), cacheable (Section 4.2.3),＼
</li>
	<li>
要請~内に在る`~payload本体$に，どのような意味論が結付けられるか？
◎
what semantics are to be associated with the payload body if any is present in the request 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>
`条件付きに$できるか？
— できる場合、条件が偽のときに，~serverは どう応答するか？
◎
The new method ought to describe whether it can be made conditional (Section 5.2) and, if so, how a server responds when the condition is false.＼
</li>
	<li>
`部分的~応答$の意味論のための，何らかの利用はあり得るか？
— その場合、それも文書化する~OUGHT。
◎
Likewise, if the new method might have some use for partial response semantics ([RFC7233]), it ought to document this, too.
</li>
</ul>

</div>

<p class="note">注記：
"`M-^c" から開始する~method名は，定義しないこと
— その接頭辞は、［
`2774$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 id="section-8.1.3">
<h4 title="Registrations">8.1.3. 登録</h4>

<p>
"Hypertext Transfer Protocol (HTTP) Method Registry"
は、次の登録により拡充された：
◎
The "Hypertext Transfer Protocol (HTTP) Method Registry" has been populated with the registrations below:
</p>

<div>
<table><thead>
<tr><td>~method
<td>`安全$？
<td>`冪等$？
<tbody>

<tr><td>`CONNECT$m
<td>no
<td>no

<tr><td>`DELETE$m
<td>no
<td>yes

<tr><td>`GET$m
<td>yes
<td>yes

<tr><td>`HEAD$m
<td>yes
<td>yes

<tr><td>`OPTIONS$m
<td>yes
<td>yes

<tr><td>`POST$m
<td>no
<td>no

<tr><td>`PUT$m
<td>no
<td>yes

<tr><td>`TRACE$m
<td>yes
<td>yes
</table>

<pre lang="en" class="_en">
   +---------+------+------------+---------------+
   | Method  | Safe | Idempotent | Reference     |
   +---------+------+------------+---------------+
   | CONNECT | no   | no         | Section 4.3.6 |
   | DELETE  | no   | yes        | Section 4.3.5 |
   | GET     | yes  | yes        | Section 4.3.1 |
   | HEAD    | yes  | yes        | Section 4.3.2 |
   | OPTIONS | yes  | yes        | Section 4.3.7 |
   | POST    | no   | no         | Section 4.3.3 |
   | PUT     | no   | yes        | Section 4.3.4 |
   | TRACE   | yes  | yes        | Section 4.3.8 |
   +---------+------+------------+---------------+
</pre>
</div>

			</section>
		</section>
		<section id="section-8.2">
<h3 title="Status Code Registry">8.2. 状態s~code~registry</h3>

<p>
`応答~状態s~code$ 
— `status-code$p ~token —
用の名前空間は、
`~HTTP状態s~code~registry＠~IANA-a/http-status-codes$
にて保守され，定義される。
◎
The "Hypertext Transfer Protocol (HTTP) Status Code Registry" defines the namespace for the response status-code token (Section 6). The status code registry is maintained at &lt;http://www.iana.org/assignments/http-status-codes&gt;.
</p>

<p>
この節は、
以前に`2817-7.1$rfcにて定義された HTTP Status Codes 用の登録~手続-を置換する。
◎
This section replaces the registration procedure for HTTP Status Codes previously defined in Section 7.1 of [RFC2817].
</p>

			<section id="section-8.2.1">
<h4 title="Procedure">8.2.1. 手続-</h4>

<p>
登録は、次の~fieldを内包しなければナラナイ：
◎
A registration MUST include the following fields:
</p>

<ul>
	<li>
`状態s~code$（ 3 桁）
◎
• Status Code (3 digits)
</li>
	<li>
短い記述
◎
• Short Description
</li>
	<li>
仕様~textへの~pointer
◎
• Pointer to specification text
</li>
</ul>

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

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

<p>
［
現在の状態s~codeにより定義されない応答~用の意味論
］を表出することが必要yなときは、新たな状態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には、`6$secにて定義される類別のいずれかに入ることが要求される。
既存の構文解析器が，応答~messageを処理できるようにするため、新たな状態s~codeは，~payloadを不許可には できない
— `~payload本体$を長さ 0 に義務化することはできるが。
◎
New status codes are required to fall under one of the categories defined in Section 6. To allow existing parsers to process the response message, new status codes cannot disallow a payload, although they can mandate a zero-length payload body.
</p>

<p>
［
まだ広範に配備されてない，新たな状態s~code
］用の提案は、［
登録されることになる明瞭な総意が得られる
］まで，［
~code用に特定の番号を割振ることを避ける
］~OUGHT
— 早期の草案は、代わりに，［
提案される状態s~codeの`応答class$
］を，尚早に番号を消費することなく指示する［
"`4NN^c" や, "`3N0^c" 〜 "`3N9^c" などの表記法
］を利用できる。
◎
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を応答に利用するときに
⇒＃
要求される~headerは何か？／
どの~headerが意味論を改変し得るか？／
意味論が更に精緻化される~headerは何か？
◎
any dependencies on response header fields (e.g., what fields are required, what fields can modify the semantics, and what header field semantics are further refined when used with the new status code).
</li>
	<li>
<p>
`既定で~cache可能である$かどうか。
◎
The definition of a new status code ought to specify whether or not it is cacheable.＼
</p>

<p>
状態s~codeが何であれ、明示的な`鮮度~情報$を伴う応答は，~cacheできることに注意
— しかしながら，［
~cache可能として定義された状態s~code
］を伴う応答は、［
明示的な`鮮度~情報$がなくても~cacheする
］ことが許容される。
同様に，状態s~codeの定義は、~cacheの挙動に拘束を設置できる。
更なる情報は`7234$Rを見よ。
◎
Note that all status codes can be cached if the response they occur in has explicit freshness information; however, status codes that are defined as being cacheable are allowed to be cached without explicit freshness information. Likewise, the definition of a status code can place constraints upon cache behavior. See [RFC7234] for more information.
</p>
	</li>
	<li>
~payloadに，［
識別される資源（`3.1.4.1$sec）への何らかの結付け
］が含意されるかどうか。
◎
Finally, the definition of a new status code ought to indicate whether the payload has any implied association with an identified resource (Section 3.1.4.1).
	</li>
</ul>

			</section>
			<section id="section-8.2.3">
<h4 title="Registrations">8.2.3. 登録</h4>

<p>
状態s~code~registryは、次の登録により更新された：
◎
The status code registry has been updated with the registrations below:
</p>

<div>
<ul><li>`100$st
</li><li>`101$st
</li><li>`200$st
</li><li>`201$st
</li><li>`202$st
</li><li>`203$st
</li><li>`204$st
</li><li>`205$st
</li><li>`300$st
</li><li>`301$st
</li><li>`302$st
</li><li>`303$st
</li><li>`305$st
</li><li>`306$st
</li><li>`307$st
</li><li>`400$st
</li><li>`402$st
</li><li>`403$st
</li><li>`404$st
</li><li>`405$st
</li><li>`406$st
</li><li>`408$st
</li><li>`409$st
</li><li>`410$st
</li><li>`411$st
</li><li>`413$st
</li><li>`414$st
</li><li>`415$st
</li><li>`417$st
</li><li>`426$st
</li><li>`500$st
</li><li>`501$st
</li><li>`502$st
</li><li>`503$st
</li><li>`504$st
</li><li>`505$st
</li></ul>

<pre lang="en" class="_en">
   +-------+-------------------------------+----------------+
   | Value | Description                   | Reference      |
   +-------+-------------------------------+----------------+
   | 100   | Continue                      | Section 6.2.1  |
   | 101   | Switching Protocols           | Section 6.2.2  |
   | 200   | OK                            | Section 6.3.1  |
   | 201   | Created                       | Section 6.3.2  |
   | 202   | Accepted                      | Section 6.3.3  |
   | 203   | Non-Authoritative Information | Section 6.3.4  |
   | 204   | No Content                    | Section 6.3.5  |
   | 205   | Reset Content                 | Section 6.3.6  |
   | 300   | Multiple Choices              | Section 6.4.1  |
   | 301   | Moved Permanently             | Section 6.4.2  |
   | 302   | Found                         | Section 6.4.3  |
   | 303   | See Other                     | Section 6.4.4  |
   | 305   | Use Proxy                     | Section 6.4.5  |
   | 306   | (Unused)                      | Section 6.4.6  |
   | 307   | Temporary Redirect            | Section 6.4.7  |
   | 400   | Bad Request                   | Section 6.5.1  |
   | 402   | Payment Required              | Section 6.5.2  |
   | 403   | Forbidden                     | Section 6.5.3  |
   | 404   | Not Found                     | Section 6.5.4  |
   | 405   | Method Not Allowed            | Section 6.5.5  |
   | 406   | Not Acceptable                | Section 6.5.6  |
   | 408   | Request Timeout               | Section 6.5.7  |
   | 409   | Conflict                      | Section 6.5.8  |
   | 410   | Gone                          | Section 6.5.9  |
   | 411   | Length Required               | Section 6.5.10 |
   | 413   | Payload Too Large             | Section 6.5.11 |
   | 414   | URI Too Long                  | Section 6.5.12 |
   | 415   | Unsupported Media Type        | Section 6.5.13 |
   | 417   | Expectation Failed            | Section 6.5.14 |
   | 426   | Upgrade Required              | Section 6.5.15 |
   | 500   | Internal Server Error         | Section 6.6.1  |
   | 501   | Not Implemented               | Section 6.6.2  |
   | 502   | Bad Gateway                   | Section 6.6.3  |
   | 503   | Service Unavailable           | Section 6.6.4  |
   | 504   | Gateway Timeout               | Section 6.6.5  |
   | 505   | HTTP Version Not Supported    | Section 6.6.6  |
   +-------+-------------------------------+----------------+
</pre>

</div>

			</section>
		</section>
		<section id="section-8.3">
<h3 title="Header Field Registry">8.3. ~header~registry</h3>

<p>
~HTTP~headerは、`BCP90$rにて定義されるように，
`Message Headers＠~IANA-a/message-headers$
~registryの中に登録される。
◎
HTTP header fields are registered within the "Message Headers" registry located at &lt;http://www.iana.org/assignments/message-headers&gt;, as defined by [BCP90].
</p>

			<section id="section-8.3.1">
<h4 title="Considerations for New Header Fields">8.3.1. 新たな~headerに対する考慮点</h4>

<p>
`~header$は、［
~message／
その~payload／
`~target資源$／
接続（すなわち`制御~data$）
］についての~dataを通信するために利用できる，［
~key:値
］の ~pairである。
~HTTP~messageにおける~header構文の一般的な定義は、`7230-3.2$rfcを見よ。
◎
Header fields are key:value pairs that can be used to communicate data about the message, its payload, the target resource, or the connection (i.e., control data). See Section 3.2 of [RFC7230] for a general definition of header field syntax in HTTP messages.
</p>

<p>
`~header名$に課される要件は、`BCP90$rにて定義される。
◎
The requirements for header field names are defined in [BCP90].
</p>

<p>
新たな~headerを定義する仕様の策定者には、［
名前を実用的な短さに保つ
］こと, および［
その~headerが~Internet上で利用されることは 決してないのでない限り，名前に "`X-^c" 接頭辞を付けない
］ことを勧める：
"`X-^c" 接頭辞~idiomは、実施において，広範囲に誤用されてきた
— それに意図されていた利用は、［
~proprietary~softwareや~intranet処理の内側における，名前~衝突を避ける仕組み
］に限られていた
— その接頭辞により［
私的な名前が，新たに登録される~Internet名と決して衝突しない
］ことが確保されるので。
更なる情報は`BCP178$rを見よ。
◎
Authors of specifications defining new fields are advised to keep the name as short as practical and not to prefix the name with "X-" unless the header field will never be used on the Internet. (The "X-" prefix idiom has been extensively misused in practice; it was intended to only be used as a mechanism for avoiding name collisions inside proprietary software or intranet processing, since the prefix would ensure that private names never collide with a newly registered Internet name; see [BCP178] for further information).
</p>

<p>
新たな`~header値$の構文は、概して ~ABNF （`5234$R）を利用して
— 必要yなら，`7230-7$rfcに定義される拡張も利用して —
定義される。
また、通例的に，US-ASCII 文字の範囲に拘束される。
より広~範囲の文字を必要とする~headerは、`5987$Rにて定義されるものなどの，符号化法を利用できる。
◎
New header field values typically have their syntax defined using ABNF ([RFC5234]), using the extension defined in Section 7 of [RFC7230] as necessary, and are usually constrained to the range of US-ASCII characters. Header fields needing a greater range of characters can use an encoding such as the one defined in [RFC5987].
</p>

<p>
生の~header値における頭部／尾部の`空白$は、`~header$を構文解析する際に除去される（`7230-3.2.4$rfc）。
~header定義において，値において頭部／尾部の`空白$が有意になる所では、
`quoted-string$p などの~container構文を~~要することになる。
◎
Leading and trailing whitespace in raw field values is removed upon field parsing (Section 3.2.4 of [RFC7230]). Field definitions where leading or trailing whitespace in values is significant will have to use a container syntax such as quoted-string (Section 3.2.6 of [RFC7230]).
</p>

<p>
~comma （"`,^c"）は，［
`~header値$の各~entry間の汎用 区切子
］として利用されるので、`~header値$に許容されるときは，~~注意して扱う必要がある。
~commaを包含し得る成分は、概して，［
`quoted-string$p ~ABNF生成規則を利用する`二重引用符$
］で保護される。
◎
Because commas (",") are used as a generic delimiter between field-values, they need to be treated with care if they are allowed in the field-value. Typically, components that might contain a comma are protected with double-quotes using the quoted-string ABNF production.
</p>

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

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

</div>

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

<p>
多くの~headerは、（文字大小無視な）名前が~~付与された~parameterを内包する形式を利用する（例えば `Content-Type$p ）。
~parameter値の構文に［
引用符~無し（ `token$p ）と有り（ `quoted-string$p ）
］の両~形を許容すれば、`受信者$は，既存の構文解析器を利用できるようになる。
【！~componentの利用を可能化し得る＊ 】
その場合、~parameter値の意味は，それに利用される構文
【における引用符の有無】
には依存しない~OUGHT（例えば、`~MIME型$に対する~parameterの取扱いについての注記を見よ）。
◎
Many header fields use a format including (case-insensitively) named parameters (for instance, Content-Type, defined in Section 3.1.1.5). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing parser components. When allowing both forms, the meaning of a parameter value ought to be independent of the syntax used for it (for an example, see the notes on parameter handling for media types in Section 3.1.1.1).
</p>

<p>
新たな~headerを定義する仕様の策定者には、次を文書化することも考慮することを勧める：
◎
Authors of specifications defining new header fields are advised to consider documenting:
</p>

<ul>
	<li>
<p>
~header値は，単独の値をとるか，それとも（~commaで区切られる）~listとり得るか？
— `7230-3.2$rfcを見よ。
◎
• Whether the field is a single value or whether it can be a list (delimited by commas; see Section 3.2 of [RFC7230]).＼
</p>

<p>
~list構文を利用しない場合は、複数~個の~headerが生じたときに，~messageを扱う方法も（その~headerを無視するのが既定としてイミを成し得るかもしれないが、常に~~正しい選択になるとは限らない）。
◎
If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default would be to ignore the field, but this might not always be the right choice).＼
</p>

<p>
~headerの定義が~list構文を許容していなくても、媒介者や~software~libraryは，［
複数の~header~instanceを一つに`結合-$し得る
］ことに注意。
堅牢な形式は、受信者がこれらの状況を発見することを可能化する。
例えば：
◎
Note that intermediaries and software libraries might combine multiple header field instances into a single one, despite the field's definition not allowing the list syntax. A robust format enables recipients to discover these situations＼
</p>
		<ul>
			<li>
良い例： "`Content-Type$p"
— ~commaが出現し得るのは，引用符~付き文字列の内側のみなので
◎
(good example: "Content-Type", as the comma can only appear inside quoted strings;＼
</li>
			<li>
悪い例： "`Location$p"
— ~URIの内側に~commaが生じ得る
◎
bad example: "Location", as a comma can occur inside a URI).
</li>
		</ul>
	</li>
	<li>
~headerは，どの条件の下で利用できるか？
— 例：
応答のみ ／
要請のみ ／
すべての~message ／
特定0の`要請~method$に対する応答のみ,
等々。
◎
• Under what conditions the header 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>
~headerは、 `PUT$m 要請に際して それを解する`生成元~server$により格納されるべきか？
◎
• Whether the field should be stored by origin servers that understand it upon a PUT request.
</li>
	<li>
~headerの意味論は、既存の`要請~method$や状態s~codeなどの文脈の下で，更に精緻化されるか？
◎
• Whether the field semantics are further refined by the context, such as by existing request methods or status codes.
</li>
	<li>
［
`~header名$を，`Connection$h ~header内に~listする
］ことは適切になるか？（すなわち，`隣点間~header$か？）。
◎
• Whether it is appropriate to list the field-name in the Connection header field (i.e., if the header field is to be hop-by-hop; see Section 6.1 of [RFC7230]).
</li>
	<li>
`媒介者$は、どの条件の下で，~headerの値を［
挿入する／削除する／改変する
］ことが許容されるか？
◎
• Under what conditions intermediaries are allowed to insert, delete, or modify the field's value.
</li>
	<li>
［
`Vary$h `応答~header$内に，`~header名$を~listする
］ことは適切になるか？（例： `要請~header$が，`生成元~server$の内容~選定~algoにより利用されるときなど）。
◎
• Whether 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 7.1.4).
</li>
	<li>
~headerは，`~trailer節$内で［
有用になる／許容-可能
］か？
◎
• Whether the header field is useful or allowable in trailers (see Section 4.1 of [RFC7230]).
</li>
	<li>
~headerは，何度かの~redirectにまたがって保全される~OUGHTか？
◎
• Whether the header field ought to be preserved across redirects.
</li>
	<li>
~privacyに関係する~dataの開示など，他の追加的な~securityの考慮点を導入するか？
◎
• Whether it introduces any additional security considerations, such as disclosure of privacy-related data.
</li>
</ul>

			</section>
			<section id="section-8.3.2">
<h4 title="Registrations">8.3.2. 登録</h4>

<p>
"Message Headers" ~registryは、
次の恒久的な登録により更新された：
◎
The "Message Headers" registry has been updated with the following permanent registrations:
</p>

<div>
<table><thead>
<tr><td>~header名
<td>~protocol
<td>位置付け
<tbody>

<tr><td>`Accept$h
<td>http
<td>standard

<tr><td>`Accept-Charset$h
<td>http
<td>standard

<tr><td>`Accept-Encoding$h
<td>http
<td>standard

<tr><td>`Accept-Language$h
<td>http
<td>standard

<tr><td>`Allow$h
<td>http
<td>standard

<tr><td>`Content-Encoding$h
<td>http
<td>standard

<tr><td>`Content-Language$h
<td>http
<td>standard

<tr><td>`Content-Location$h
<td>http
<td>standard

<tr><td>`Content-Type$h
<td>http
<td>standard

<tr><td>`Date$h
<td>http
<td>standard

<tr><td>`Expect$h
<td>http
<td>standard

<tr><td>`From$h
<td>http
<td>standard

<tr><td>`Location$h
<td>http
<td>standard

<tr><td>`Max-Forwards$h
<td>http
<td>standard

<tr><td>`MIME-Version$h
<td>http
<td>standard

<tr><td>`Referer$h
<td>http
<td>standard

<tr><td>`Retry-After$h
<td>http
<td>standard

<tr><td>`Server$h
<td>http
<td>standard

<tr><td>`User-Agent$h
<td>http
<td>standard

<tr><td>`Vary$h
<td>http
<td>standard
</table>

<pre lang="en" class="_en">
   +-------------------+----------+----------+-----------------+
   | Header Field Name | Protocol | Status   | Reference       |
   +-------------------+----------+----------+-----------------+
   | Accept            | http     | standard | Section 5.3.2   |
   | Accept-Charset    | http     | standard | Section 5.3.3   |
   | Accept-Encoding   | http     | standard | Section 5.3.4   |
   | Accept-Language   | http     | standard | Section 5.3.5   |
   | Allow             | http     | standard | Section 7.4.1   |
   | Content-Encoding  | http     | standard | Section 3.1.2.2 |
   | Content-Language  | http     | standard | Section 3.1.3.2 |
   | Content-Location  | http     | standard | Section 3.1.4.2 |
   | Content-Type      | http     | standard | Section 3.1.1.5 |
   | Date              | http     | standard | Section 7.1.1.2 |
   | Expect            | http     | standard | Section 5.1.1   |
   | From              | http     | standard | Section 5.5.1   |
   | Location          | http     | standard | Section 7.1.2   |
   | Max-Forwards      | http     | standard | Section 5.1.2   |
   | MIME-Version      | http     | standard | Appendix A.1    |
   | Referer           | http     | standard | Section 5.5.2   |
   | Retry-After       | http     | standard | Section 7.1.3   |
   | Server            | http     | standard | Section 7.4.2   |
   | User-Agent        | http     | standard | Section 5.5.3   |
   | Vary              | http     | standard | Section 7.1.4   |
   +-------------------+----------+----------+-----------------+
</pre>
</div>

<p>
上の登録の変更~制御者は~IETF-orgである。
◎
The change controller for the above registrations is: "IETF (iesg@ietf.org) - Internet Engineering Task Force".
</p>

			</section>
		</section>
		<section id="section-8.4">
<h3 title="Content Coding Registry">8.4. 内容~符号法~registry</h3>

<p>
`内容~符号法$~名の名前空間は，
【！7230-4.2$rfc？】
`HTTP Content Coding Registry＠~IANA-a/http-parameters$
にて保守される，内容~符号法~registryにて定義される。
◎
The "HTTP Content Coding Registry" defines the namespace for content coding names (Section 4.2 of [RFC7230]). The content coding registry is maintained at &lt;http://www.iana.org/assignments/http-parameters&gt;.
</p>

			<section id="section-8.4.1">
<h4 title="Procedure">8.4.1. 手続-</h4>

<p>
`内容~符号法$の登録にあたっては、次の~fieldを含めなければナラナイ：
◎
Content coding registrations MUST include the following fields:
</p>

<ul>
	<li>
名前
◎
• Name
</li>
	<li>
記述
◎
• Description
</li>
	<li>
仕様~textへの~pointer
◎
• Pointer to specification text
</li>
</ul>

<p>
`内容~符号法~名$は、`転送~符号法~名$と重なってはてはナラナイ
— 符号化法の形式変換が一致していない限り（ `7230$Rに定義される各種 `圧縮~符号法$に該当するものなど）。
◎
Names of content codings MUST NOT overlap with names of transfer codings (Section 4 of [RFC7230]), unless the encoding transformation is identical (as is the case for the compression codings defined in Section 4.2 of [RFC7230]).
</p>

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

			</section>
			<section id="section-8.4.2">
<h4 title="Registrations">8.4.2. 登録</h4>

<p>
"HTTP Content Coding Registry"
は、次の登録により更新された：
◎
The "HTTP Content Coding Registry" has been updated with the registrations below:
</p>

<div>
<table><thead>
<tr><td>名前
<td>記述
<td>参照
<tbody>

<tr><td>`identity^c
<td>予約-済み（ `Accept-Encoding$h における “符号化しない” の同義語）
<td>`5.3.4$sec
</table>

<pre lang="en" class="_en">
   +----------+----------------------------------------+---------------+
   | Name     | Description                            | Reference     |
   +----------+----------------------------------------+---------------+
   | identity | Reserved (synonym for "no encoding" in | Section 5.3.4 |
   |          | Accept-Encoding)                       |               |
   +----------+----------------------------------------+---------------+
</pre>
</div>

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

<p>
この節は、［
開発者／情報~provider／利用者
］向けに，~HTTP意味論, および その［
 ~Internet越しに情報を転送するための利用
］に関連な，既知な~securityの懸念を伝えることを~~意図している。
［
~message構文／構文解析／経路制御
］に関係する考慮点は、 `7230-9$rfcにて論じられる。
◎
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 message syntax, parsing, and routing are discussed in Section 9 of [RFC7230].
</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側~app（
~HTTP~interfaceの背後の~code
）の~secure化。
◎
securing server-side applications (code behind the HTTP interface),＼
</li>
	<li>
~HTTPを介して受信された~payloadの~UAによる処理の~secure化。
◎
securing user agent processing of payloads received via HTTP, or＼
</li>
	<li>
一般における~Internetの~secureな利用。
◎
secure use of the Internet in general,＼
</li>
</ul>

<p>
様々な組織が、~Web~appにおける~securityの［
時事的な情報, および 現在の事実調査への~link
］を保守している。
（例： `OWASP$r）。
◎
rather than security of the protocol. Various organizations maintain topical information and links to current research on Web application security (e.g., [OWASP]).
</p>
</div>

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

<p>
`生成元~server$は、［
`実効~要請~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 effective request 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 request target 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="section-9.2">
<h3 title="Attacks Based on Command, Code, or Query Injection">9.2. ~command／~code／~query の注入に基づく攻撃</h3>

<p>
`生成元~server$は、`~URI$の中の~parameterを，［
~system~serviceを識別する／
~database~entryを選定する／
~data~sourceを選択する
］ための手段として，利用することが多い。
しかしながら、要請~内に受信された~dataは，信用できない。
攻撃者は、［［
~command呼出し／言語~解釈器／~database~interface
］を通して渡されたときに［
~command／~code／~query
］として誤解釈され得る
］ような~dataを包含させるために，どのような要請~data要素（~method, `request-target$p, ~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, request-target, header fields, or body) 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 注入は、［
`request-target$p または~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 request-target 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="section-9.3">
<h3 title="Disclosure of Personal Information">9.3. 個人-情報の開示</h3>

<p>
`~client$は、多量の個人-情報を知る立場にあることが多い
— ［
資源とヤリトリするために，利用者から供される情報（例：
利用者の［
名前, 所在, ~mail~address, ~password, 暗号化~key, 等々
］）
］や, ［
利用者の時間~越しな閲覧~活動についての情報（例： 履歴, ~bookmark, 等々）
］の両者を含めて。
実装は、
意図的でない個人-情報の開示を防止する必要がある。
◎
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.
</p>

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

<p>
`~URI$は、~secureな資源を識別するものであっても，［
共有され, ~secure化されないもの
］になるように意図されている。
~URIは、［
~displayに示される／
~pageの印刷-時に各用紙に刷られる／
様々な未保護な~bookmark~list内に格納される
］ことが多い。
したがって，［
敏感な／個人識別可能な／開示される~riskがある
］情報を~URIに内包することは、賢明でない。
◎
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. It is therefore unwise to include information within a URI that is sensitive, personally identifiable, or a risk to disclose.
</p>

<p>
~serviceの作者は、［
`GET$m ~based~formによる，敏感な~dataの提出
］は避ける~OUGHT
— 何故なら、その~dataは， `request-target$p 内に置かれることになるので。
多くの既存の［
~server／~proxy／~UA
］は、`request-target$p を［
第三者-主体から可視になり得る所
］に，~logしたり, 表示する。
そのような~serviceは、代わりに `POST$m ~based~formによる提出を利用する~OUGHT。
◎
Authors of services ought to avoid GET-based forms for the submission of sensitive data because that data will be placed in the request-target. Many existing servers, proxies, and user agents log or display the request-target in places where it might be visible to third parties. Such services ought to use POST-based form submission instead.
</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 5.5.2 to address some of its security considerations.
</p>

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

<p>
［
`~URI$参照の中で利用される`素片~識別子$
］は，要請~内には送信されないが、実装者は，応答の結果として［
それらが、~UAや，稼働している どの拡張／~scriptからも可視になる
］ことを自覚しておく~OUGHT。
特に，［
~redirectが生じて，元の要請の素片~識別子が `Location$h 内の新たな参照に継承される
］とき、これは，［
ある~siteの素片を別の~siteに開示する
］効果を持ち得る。
最初の~siteが素片~内に個人-情報を利用している場合、［
他の~siteへの~redirectに際し，【元の素片と無関係な】（場合によっては空な） `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 7.1.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="section-9.6">
<h3 title="Disclosure of Product Information">9.6. 製品~情報の開示</h3>

<p>
［
`User-Agent$h ／ `Via$h ／ `Server$h
］~headerは、［
当の`送信者$の~software~systemについての情報
］を，露呈することが多い。
理論~上は、これは，攻撃者が既知な~securityの穴を悪用し易くし得る
— 実施においては、攻撃者は，［
利用されている 見かけの~software~version
］に関わらず，~~可能性のある すべての穴を試行する傾向にあるが。
◎
The User-Agent (Section 5.5.3), Via (Section 5.7.1 of [RFC7230]), and Server (Section 7.4.2) 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="section-9.7">
<h3 title="Browser Fingerprinting">9.7. ~browser指紋収集</h3>

<p>
~browser指紋収集（ fingerprinting ）は、［
一意な［
~UAの各種~特性からなる集合
］を通して，特定の~UAを時間~越しに識別する
］ための様々な技法の~~総称である。
これらの特性には、~UAの［
~TCPの挙動,
備えている特能,
~scripting環境
］に関係する情報も含まれ得る
— 特に関心が持たれるものは、［
~HTTPを介して通信され得る，一意な【個別の~UAを一意に~~特定するような】特性の集合
］である。
指紋収集は，［
~UAの挙動を時間~越しに追跡すること
］を
— 利用者が，他の形の~data~collection（例：~cookie）に対しては持ち得るような、対応ng制御なしに —
可能化するので、~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 its TCP behavior, 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 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 5.3), including the Accept, Accept-Charset, Accept-Encoding, and Accept-Language header fields.
</p>

<p>
指紋収集の懸念に加えて，［
`Accept-Language$h ~headerの詳細な利用
］は、［
利用者が私的な資質と見なし得る情報
］を露呈し得る。
例えば，［
所与の言語~集合を解すること
］は、［
特定0の民族の成員であること
］に強く相関し得る。
~UAがとり得る，そのような~privacyの損失を制限する~approachとしては、~whitelistに入れられた~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 whitelisted, 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>
	<section id="section-10">
<h2 title="Acknowledgments">10. 謝辞</h2>

<p class="trans-note">【
この節の内容は、
`RFC723X 共通~page＠~723X#acknowledgments$
に移譲。
】
◎
See Section 10 of [RFC7230].
</p>

	</section>
	<section id="section-11">
<h2 title="References">11. 参照文献</h2>

<p class="trans-note">【
この節の内容は、
`RFC723X 共通~page＠~723X#references$
に移譲。
】</p>

	</section>
	<section id="appendix-A">
<h2 title="Appendix A. Differences between HTTP and MIME">付録 A. ~HTTPと~MIMEの相違点</h2>

<div class="p">

<p>
`~HTTP11$は、［
Internet Message Format `5322$R
および
MIME（ Multipurpose Internet Mail Extensions ） `2045$R
用に定義された，構成子の多く
］を利用して、`~message本体$を，拡張-可能な~headerと伴に［
~openかつ多種多様な`表現$
］により伝送できるようにする。
しかしながら，`2045$Rは、~emailのみに力点を置いている
— ~HTTPの~appは、~emailから相違する多くの特性を持つので，~MIMEから相違する特能を備える。
これらの相違点は、次のために注意深く選択されている：
</p>

<ul>
	<li>
~binary接続の処理能を最適化する
</li>
	<li>
新たな`~MIME型$の利用における自由度を高める
</li>
	<li>
日時の比較をより容易にする
</li>
	<li>
一部の早期の~HTTP~server／~clientの実施を承認する
</li>
</ul>
◎
HTTP/1.1 uses many of the constructs defined for the Internet Message Format [RFC5322] and the Multipurpose Internet Mail Extensions (MIME) [RFC2045] to allow a message body to be transmitted in an open variety of representations and with extensible header fields. However, RFC 2045 is focused only on email; applications of HTTP have many characteristics that differ from email; hence, HTTP has features that differ from MIME. These differences were carefully chosen to optimize performance over binary connections, to allow greater freedom in the use of new media types, to make date comparisons easier, and to acknowledge the practice of some early HTTP servers and clients.
</div>

<p>
この付録は、~HTTPが~MIMEから相違する，特定の分野について述べる。
厳密的~MIME環境 への／からの `~gateway$や`~proxy$は、これらの相違点を自覚した上で，必要yな所では 適切な変換を供する必要がある。
◎
This appendix describes specific areas where HTTP differs from MIME. Proxies and gateways to and from strict MIME environments need to be aware of these differences and provide the appropriate conversions where necessary.
</p>

		<section id="appendix-A.1">
<h3 title="A.1. MIME-Version">A.1. `MIME-Version^h</h3>

<p>
~HTTPは、~MIME準拠~protocolではない。
しかしながら，~messageを構築するときに［
単独の `MIME-Version^h ~header
］を内包することで、［
~MIME~protocolの どの~versionが利用されたか
］を指示できる。
`MIME-Version^h ~headerの利用は、［
~messageが（`2045$Rにて定義されるように）~MIME~protocolに全部的に適合している
］ことを指示する。
`送信者$は、［
~HTTP~messageを厳密的~MIME環境に~exportする
］ときには（アリな所では）全部的な適合性を確保する責を負う。
◎
HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined in [RFC2045]). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.
</p>

		</section>
		<section id="appendix-A.2">
<h3 title="A.2. Conversion to Canonical Form">A.2. 正準-形への変換</h3>

<p>
~MIMEは、`2049-4$rfcにて述べられるように，転送に先立って，［
~Internet~mail本体 部分
］を正準-形に変換することを要求する。
［
`~MIME型$ "`text^c" の各種 下位型が，~HTTP越しに伝送されるときに許容される形
］については、この文書の`3.1.1.3$secに述べている。
`2046$Rは、その "`text^c" 型の内容が，改行を `CRLF$P として表現することを要求し，改行~並びの外での `CR$P ／ `LF$P の利用を禁止する。
一方で，~HTTPは、~text内容の中の改行を指示する［
`CRLF$P 並びや, ~~単独の `CR$P ／ `LF$P
］を許容する。
◎
MIME requires that an Internet mail body part be converted to canonical form prior to being transferred, as described in Section 4 of [RFC2049]. Section 3.1.1.3 of this document describes the forms allowed for subtypes of the "text" media type when transmitted over HTTP. [RFC2046] requires that content with a type of "text" represent line breaks as CRLF and forbids the use of CR or LF outside of line break sequences. HTTP allows CRLF, bare CR, and bare LF to indicate a line break within text content.
</p>

<p>
~HTTPから厳密的~MIME環境への`~proxy$／`~gateway$は、［
~text `~MIME型$の中のすべての改行
］を，`3.1.1.3$secにて述べたように［
`2049$Rによる 正準-形 `CRLF$P
］に転化する~OUGHT。
しかしながら，これは［
`Content-Encoding$h が在ること
］, および［
~HTTPが［
`CR$P ／ `LF$P を表現する~octet 13 ／ 10 を利用しない，一部の`~charset$
］の利用を許容する事実
］により，複雑化することもあることに注意。
◎
A proxy or gateway from HTTP to a strict MIME environment ought to translate all line breaks within the text media types described in Section 3.1.1.3 of this document to the RFC 2049 canonical form of CRLF. Note, however, this might be complicated by the presence of a Content-Encoding and by the fact that HTTP allows the use of some charsets that do not use octets 13 and 10 to represent CR and LF, respectively.
</p>

<p>
変換は、［
内容が~~元々正準-形である場合
］を除き，［
元の内容に適用された暗号用の~checksumを，それが何であれ非互換化する
］ことになる。
したがって、~HTTPにてそのような~checksumを利用する内容には，正準-形が推奨される。
◎
Conversion will break any cryptographic checksums applied to the original content unless the original content is already in canonical form. Therefore, the canonical form is recommended for any content that uses such checksums in HTTP.
</p>

		</section>
		<section id="appendix-A.3">
<h3 title="A.3. Conversion of Date Formats">A.3. 日時~形式の変換</h3>

<p>
`~HTTP11$は、［
日時の比較~処理nを単純~化する
］ために［
制約された，日時~形式の集合（`7.1.1.1$sec）
］を利用する。
他の~protocolからの`~proxy$／`~gateway$は、［
~message内に在るどの `Date$h ~header
］も，いずれかの~HTTP11形式に適合することを確保し、必要yなら日時を書換える~OUGHT。
◎
HTTP/1.1 uses a restricted set of date formats (Section 7.1.1.1) to simplify the process of date comparison. Proxies and gateways from other protocols ought to ensure that any Date header field present in a message conforms to one of the HTTP/1.1 formats and rewrite the date if necessary.
</p>

		</section>
		<section id="appendix-A.4">
<h3 title="A.4. Conversion of Content-Encoding">A.4. `Content-Encoding^h の変換</h3>

<p>
~MIMEは、`~HTTP11$の `Content-Encoding$h ~headerに等価な概念を含まない。
これは，`~MIME型$の改変子として動作するので、［
~HTTPから~MIME準拠~protocolへの `~proxy$／`~gateway$
］は，~messageを回送する前に［
`Content-Type$h ~headerの値を変更する
］か, または［
`表現$を復号する
］~OUGHT。
（
~Internet~mailに対する `Content-Type$h の一部の試験的~appは、
`Content-Encoding$h と等価な機能を遂行するために，
`media-type$p ~parameterに
"`;conversions=&lt;content-coding&gt;^c"
を利用している。
しかしながら，この~parameterは、~MIME標準の一部でない）。
◎
MIME does not include any concept equivalent to HTTP/1.1's Content-Encoding header field. Since this acts as a modifier on the media type, proxies and gateways from HTTP to MIME-compliant protocols ought to either change the value of the Content-Type header field or decode the representation before forwarding the message. (Some experimental applications of Content-Type for Internet mail have used a media-type parameter of ";conversions=&lt;content-coding&gt;" to perform a function equivalent to Content-Encoding. However, this parameter is not part of the MIME standards).
</p>

		</section>
		<section id="appendix-A.5">
<h3 title="A.5. Conversion of Content-Transfer-Encoding">A.5. `Content-Transfer-Encoding^h の変換</h3>

<p>
~HTTPは、［
~MIMEの `Content-Transfer-Encoding$h ~header
］を利用しない。
~MIME準拠~protocolから~HTTPへの`~proxy$／`~gateway$は、応答~messageを~HTTP~clientへ送達するに先立って，すべての `Content-Transfer-Encoding^h を除去する必要がある。
◎
HTTP does not use the Content-Transfer-Encoding field of MIME. Proxies and gateways from MIME-compliant protocols to HTTP need to remove any Content-Transfer-Encoding prior to delivering the response message to an HTTP client.
</p>

<p>
~HTTPから~MIME準拠~protocolへの `~proxy$／`~gateway$ は、~messageが［
その~protocol上で安全に~transportされるような，正しい［
形式, 符号化法
］である
］ことを確保する責を負う
— ここでの “安全な~transport” は、利用される~protocolによる制限により定義される。
そのような~proxy／~gatewayは、［
適切な `Content-Transfer-Encoding$h を伴う~data
］を形式変換して~labelする~OUGHT
— そうすることで，行先~protocol越しの~transportが安全になる見込みが高まる場合には。
◎
Proxies and gateways from HTTP to MIME-compliant protocols are responsible for ensuring that the message is in the correct format and encoding for safe transport on that protocol, where "safe transport" is defined by the limitations of the protocol being used. Such a proxy or gateway ought to transform and label the data with an appropriate Content-Transfer-Encoding if doing so will improve the likelihood of safe transport over the destination protocol.
</p>

		</section>
		<section id="appendix-A.6">
<h3 title="A.6. MHTML and Line Length Limitations">A.6. MHTML と行l長さ制限</h3>

<p>
~MHTML `2557$R 実装と~codeを共有する~HTTP実装は、
~MIMEにおける行l長さの制限を自覚しておく必要がある。
~HTTPにおいては この制限がないので、長い行lも折返さない。
［
~HTTPにより~transportされている~MHTML~message
］は、行lの［
長さ制限, 折返し, 正準-化, 等々
］を含め，~MHTMLのすべての規約に従う
— ~HTTPは、`~message本体$を~payloadとして転送し，［
"`multipart/byteranges$c" 型
］は別として、そこに包含され得るどの［
内容や~MIME~header行l
］も，解釈しないので。
◎
HTTP implementations that share code with MHTML [RFC2557] implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations and folding, canonicalization, etc., since HTTP transfers message-bodies as payload and, aside from the "multipart/byteranges" type (Appendix A of [RFC7233]), does not interpret the content or any MIME header lines that might be contained therein.
</p>

		</section>
	</section>
	<section id="appendix-B">
<h2 title="Appendix B. Changes from RFC 2616">付録 B. RFC 2616 からの変更点</h2>

<ul>

	<li>
<p>
この改訂における首な変更点は、編集上の性向にある：
◎
The primary changes in this revision have been editorial in nature:＼
</p>

		<ul>
			<li>
~messaging構文を抽出した。
◎
extracting the messaging syntax and＼
</li>
			<li>
［
中核の特能,
`条件付き要請$,
`部分的~要請$,
~caching,
認証
］に対する~HTTP意味論は，別々な文書に区分された。
◎
partitioning HTTP semantics into separate documents for the core features, conditional requests, partial requests, caching, and authentication.＼
</li>
			<li>
適合性についての言い回しは，要件を明瞭に~targetにするように改訂された。
◎
The conformance language has been revised to clearly target requirements and＼
</li>
			<li>
`表現$と~payloadとを, および 表現と資源とを
判別するための，各種用語を改善した。
◎
the terminology has been improved to distinguish payload from representations and representations from resources.
</li>
		</ul>
	</li>
	<li>
`~URI$内に埋込まれる意味論は、`要請~method$と整合でない場合には不能化されるとする，新たな要件が追加された
— これが、相互運用能を失敗させる共通的な~~要因なので。
（`2$sec）
◎
A new requirement has been added that semantics embedded in a URI be disabled when those semantics are inconsistent with the request method, since this is a common cause of interoperability failure. (Section 2)
</li>
	<li>
［
~payloadが，特定の識別子に結付けられたかどうか
］を決定するための~algoが追加された。
（`3.1.4.1$sec）
◎
An algorithm has been added for determining if a payload is associated with a specific identifier. (Section 3.1.4.1)
</li>
	<li>
~text`~MIME型$に対する既定の`~charset$ ISO-8859-1 は、除去された
— 既定は，今や、その~MIME型が定義するものである。
同様に、
`Accept-Charset$h ~headerから，ISO-8859-1 の特別~扱いは除去された。
（`3.1.1.3$sec, `5.3.3$sec）
◎
The default charset of ISO-8859-1 for text media types has been removed; the default is now whatever the media type definition says. Likewise, special treatment of ISO-8859-1 has been removed from the Accept-Charset header field. (Section 3.1.1.3 and Section 5.3.3)
</li>
	<li>
`Content-Location$h の定義は、
もはや，［
相対~URI参照を解決するときの基底~URI
］には影響しないように変更された
— 実装~supportが乏しいことに加えて、［
内容~折衝による資源において相対~linkを非互換化する，望ましくない効果
］も生じるので。
（`3.1.4.2$sec）
◎
The definition of Content-Location has been changed to no longer affect the base URI for resolving relative URI references, due to poor implementation support and the undesirable effect of potentially breaking relative links in content-negotiated resources. (Section 3.1.4.2)
</li>
	<li>
`7230$Rの，~methodに中立的な構文解析~algoと整合させるため、
`GET$m の定義は，［
要請が本体を持ち得る
］ように緩められた
— `GET$m の本体は意味を持たないが
（`4.3.1$sec）
◎
To be consistent with the method-neutral parsing algorithm of [RFC7230], the definition of GET has been relaxed so that requests can have a body, even though a body has no meaning for GET. (Section 4.3.1)
</li>
	<li>
`~server$には、
もはや，すべての `Content-*^h ~headerを取扱うことは要求されない。
また、［
`PUT$m 要請における `Content-Range$h の利用
］は，明示的に禁じられた。
（`4.3.4$sec）
◎
Servers are no longer required to handle all Content-* header fields and use of Content-Range has been explicitly banned in PUT requests. (Section 4.3.4)
</li>
	<li>
`CONNECT$m ~methodの定義は、`2817$Rからこの仕様へ移動された。
（`4.3.6$sec）
◎
Definition of the CONNECT method has been moved from [RFC2817] to this specification. (Section 4.3.6)
</li>
	<li>
`OPTIONS$m および `TRACE$m `要請~method$は、`安全$と定義された。
（`4.3.8$sec）
◎
The OPTIONS and TRACE request methods have been defined as being safe. (Section 4.3.7 and Section 4.3.8)
</li>
	<li>
非互換化した実装が広範に配備されていることから、
`Expect$h ~headerにおける拡張の仕組みは、除去された。
（`5.1.1$sec）
◎
The Expect header field's extension mechanism has been removed due to widely-deployed broken implementations. (Section 5.1.1)
</li>
	<li>
`Max-Forwards$h ~headerは、［
`OPTIONS$m, `TRACE$m
］~methodに制約された。
以前までは、拡張~methodもそれを利用し得ていたが。
（`5.1.2$sec）
◎
The Max-Forwards header field has been restricted to the OPTIONS and TRACE methods; previously, extension methods could have used it as well. (Section 5.1.2)
</li>
	<li>
［
適用-可能な参照元~URIがないときの， `Referer$h ~headerの値
］として、 "`about:blank^c" ~URIが~~提案された
— それは，その事例を，他の［
`Referer$h ~headerが 送信されない／除去される
］事例から区別する。
（`5.5.2$sec）
◎
The "about:blank" URI has been suggested as a value for the Referer header field when no referring URI is applicable, which distinguishes that case from others where the Referer field is not sent or has been removed. (Section 5.5.2)
</li>
	<li>
次の`状態s~code$は、今や`既定で~cache可能である$（明示的な`鮮度~情報$が無くても，~cacheに格納して再利用できる）：
`204$st0, `404$st0, `405$st0, `414$st0, `501$st0
（`6$sec）
◎
The following status codes are now cacheable (that is, they can be stored and reused by a cache without explicit freshness information present): 204, 404, 405, 414, 501. (Section 6)
</li>
	<li>
`201$st 状態sの記述は、［
複数の資源が作成されている可能性
］を許容するように変更された。
（`6.3.2$sec）
◎
The 201 (Created) status description has been changed to allow for the possibility that more than one resource has been created. (Section 6.3.2)
</li>
	<li>
`203$st の定義は、~payload`形式変換$の事例も含むように~~広げられた。
（`6.3.4$sec）
◎
The definition of 203 (Non-Authoritative Information) has been broadened to include cases of payload transformations as well. (Section 6.3.4)
</li>
	<li>
自動的に~redirectしても安全な`要請~method$の集合は、
もはや~~閉じていない
— ~UAは、要請~method意味論に基づいてその決定を下せる。
~redirect［
`301$st0, `302$st0, `307$st0
］には、
もはや［
応答~payload／利用者-ヤリトリ
］に関する規範的な要件は無い。
（`6.4$sec）
◎
The set of request methods that are safe to automatically redirect is no longer closed; user agents are able to make that determination based upon the request method semantics. The redirect status codes 301, 302, and 307 no longer have normative requirements on response payloads and user interaction. (Section 6.4)
</li>
	<li>
［
`301$st0, `302$st0
］は、［
~UAが~methodを `POST$m から `GET$m に書換える
］ことも可能なように変更された。
（`6.4.2$sec, `6.4.3$sec）
◎
The status codes 301 and 302 have been changed to allow user agents to rewrite the method from POST to GET. (Sections 6.4.2 and 6.4.3)
</li>
	<li>
`303$stの記述は、［
明示的な`鮮度~情報$が与えられた場合に~cacheできる
］ようにするため，変更された。
`GET$m に対する `303$st0 応答~用の，特有な定義が追加された。
（`6.4.4$sec）
◎
The description of the 303 (See Other) status code has been changed to allow it to be cached if explicit freshness information is given, and a specific definition has been added for a 303 response to GET. (Section 6.4.4)
</li>
	<li>
`305$stは、［
~proxyの~in-band環境設定に関する~securityの懸念
］に因り，非推奨にされた。
（`6.4.5$sec）
◎
The 305 (Use Proxy) status code has been deprecated due to security concerns regarding in-band configuration of a proxy. (Section 6.4.5)
</li>
	<li>
`400$stは、構文~errorに制限されないよう，緩められた。
（`6.5.1$sec）
◎
The 400 (Bad Request) status code has been relaxed so that it isn't limited to syntax errors. (Section 6.5.1)
</li>
	<li>
`2817$Rから `426$stを組入れた。
（`6.5.15$sec）
◎
The 426 (Upgrade Required) status code has been incorporated from [RFC2817]. (Section 6.5.15)
</li>
	<li>
［
`HTTP-date$p ／ `Date$h
］~headerに対する要件の~targetは、
日時を送信するすべての~systemではなく，
日時を生成する~systemに抑制された。
（`7.1.1$sec）
◎
The target of requirements on HTTP-date and the Date header field have been reduced to those systems generating the date, rather than all systems sending a date. (Section 7.1.1)
</li>
	<li>
`Location$h ~headerの構文は、［
`相対~参照$や`素片$を内包する，すべての~URI参照
］を許容するように変更された。
— 素片の利用が適切にならないときの，いくつかの明確化と伴に。
（`7.1.2$sec）
◎
The syntax of the Location header field has been changed to allow all URI references, including relative references and fragments, along with some clarifications as to when use of fragments would not be appropriate. (Section 7.1.2)
</li>
	<li>
`Allow$h は、
`PUT$m 要請~内にそれを指定する~optionは除去して，
`応答~header$として分類し直された。
`Allow$h の内容に関係する要件は、
緩められた
— それに伴い、
~clientには，その値を常に信用することは要求されなくなった。
（`7.4.1$sec）
◎
Allow has been reclassified as a response header field, removing the option to specify it in a PUT request. Requirements relating to the content of Allow have been relaxed; correspondingly, clients are not required to always trust its value. (Section 7.4.1)
</li>
	<li>
"Method Registry" が定義された。
（`8.1$sec）
◎
A Method Registry has been defined. (Section 8.1)
</li>
	<li>
以前に`2817-7.1$rfcにて定義されていた
"Status Code Registry" は、この仕様にて定義し直された。
（`8.2$sec）
◎
The Status Code Registry has been redefined by this specification; previously, it was defined in Section 7.1 of [RFC2817]. (Section 8.2)
</li>
	<li>
`内容~符号法$の登録は、
`~IETFによる考査$を要するように変更された。
（`8.4$sec）。
◎
Registration of content codings has been changed to require IETF Review. (Section 8.4)
</li>
	<li>
`Content-Disposition^h ~headerは、今や `6266$Rにより定義されているので，除去された。
◎
The Content-Disposition header field has been removed since it is now defined by [RFC6266].
</li>
	<li>
`Content-MD5^h ~headerは、`部分的~応答$に関して，実装が一貫でないので、除去された。
◎
The Content-MD5 header field has been removed because it was inconsistently implemented with respect to partial responses.
</li>
</ul>

	</section>
	<section id="appendix-C">
<h2 title="Appendix C. Imported ABNF">付録 C. 取込まれた~ABNF</h2>

	</section>
	<section id="appendix-D">
<h2 title="Appendix D. Collected ABNF" data-cycling=".bnf">付録 D. 総集的~ABNF</h2>

<p class="trans-note">【
付録 C, D の内容は、
`総集的~ABNF＠~723Xabnf#abnf-7231$
に移譲。
】</p>

	</section>
</main></div>