http-accept-encoding-response-header-ja.html

<!DOCTYPE html><html lang="ja"><head><meta charset="utf-8">
<title>Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding</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 7694 — Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding
trans_update:2018-05-20
page_state_key:HTTP
original_url:https://httpwg.org/specs/rfc7694.html
abbr_url:7694
spec_status:IETFPR
no_original_dfn:true
ref_rfc:true
trans_1st_pub:2018-05-20

●●original_id_map
references:rfc.references
normative:rfc.references.1
informative:rfc.references.2

●●link_map

r.BCP90:#BCP90
r.BREACH:#BREACH
r.RFC7540:#RFC7540

●●section_map

1:introduction
2:notational.conventions
3:accept-encoding
4:example
5:deployment.considerations
6:security.considerations
7:iana.considerations
7.1:n-header-field-registry
7.2:n-status-code-registry


●●words_table1

●●words_table

発見性:discoverability:発見し易さ
HTTP2:HTTP/2
side-channel::::サイドチャネル
正当化-:justify:~
楽観的:optimistic:~
自明:trivial:~
拡げる:expandする:~
診断法:diagnostics:~

●●
	●他の語（言い換え
明瞭でない:unclear
できるようにする:allow
まだ:already

	●他の語
~~要点:point
-:located
-:namely
でも:as well
程ではない:is not on par with
加えて、:furthermore
用意があった:willing to
ためには:In order to
この時点で:At this point
の時点では:At the time of
何らかの:some
~supportされない:unsupported
-:alternatively
上げる:better
大きいもの:big
-:as follows
の様な:-like
必要がある:have to
少数:small
	別として:over
準拠する:compliant#1
~~促すことになる:lead to increased

●●
ref_normative→723X
[RFC2119]
    Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, ~RFC2119,
[RFC7230]
    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", ~RFC7230, June 2014
[RFC7231]
    Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", ~RFC7231, June 2014

●●ref_informative
[BCP90]
    Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, ~RFC3864, September 2004
[BREACH]
    Gluck, Y., Harris, N., and A. Prado, "BREACH: Reviving the CRIME Attack", July 2013,
    URL: http://breachattack.com/resources/BREACH%20-%20SSL,%20gone%20in%2030%20seconds.pdf
[RFC7540]
    Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext Transfer Protocol Version 2 (HTTP/2)", ~RFC7540, May 2015,


●●
Author's Address
Julian F. Reschke
greenbytes GmbH
Hafenweg 16
Muenster, NW 48155
Germany
Email: julian.reschke@greenbytes.de
URI: http://greenbytes.de/tech/webdav/

●●trans_metadata
<p>
~THIS_PAGEは、
~IETF により PROPOSED STANDARD として公表された，
RFC 7694
<a href="~SPEC_URL">An HTTP Status Code to Report Legal Obstacles</a>
を日本語に翻訳したものです。
~PUB
</p>


●●spec_metadata

公表者
	Internet Engineering Task Force (IETF)
RFC
	7694
分類
	Standards Track
ISSN
	2070-1721
編集
	J. Reschke, greenbytes
日付
	2015 年 11 月
現在の位置付け, 正誤表, フィードバックの方法
	https://www.rfc-editor.org/info/rfc7694

</script>

</head>
<body>

<header>
	<hgroup>
<h1>クライアントから起動される HTTP 内容符号法</h1>
<p>RFC 7694 — HTTP Client-Initiated Content-Encoding</p>
	</hgroup>
</header>

<div id="MAIN" hidden>

<p class="trans-note">【
この~RFCは、
~RFC 9110 により廃用にされた。
その~RFCの
<a href="~HTTPsem#_response.accept-encoding">§ 応答~内の `Accept-Encoding^h</a>
を見よ。
】</p>

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

<p>
~HTTPにおける`内容~符号法$は、
圧縮や完全性~検査-用などに，`~payload$の符号化法を許容する
特に， "`gzip$c" 内容~符号法は、
応答~message内に送信される~payload~data用に広範に利用されている。
◎
In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages.
</p>

<p>
内容~符号法は、
要請~message内でも利用できる。
しかしながら，その発見性は応答~message程ではない。
この文書は、
要請~内で~supportされる内容~符号法を指示するために，~HTTP `Accept-Encoding$h ~headerを応答~内での利用~用に拡張する。
◎
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate the content codings that are supported in requests. 
</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 © 2015 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>

<p>
~HTTPにおける`内容~符号法$は、
圧縮や完全性~検査~用などに，`~payload$の符号化法を許容する（ `7231-3.1.2$rfc ）。
特に， "`gzip$c" 内容~符号法は、
応答~message内に送信される~payload~data用に広範に利用されている。
◎
In HTTP, content codings allow for payload encodings such as for compression or integrity checks ([RFC7231], Section 3.1.2). In particular, the "gzip" content coding ([RFC7230], Section 4.2) is widely used for payload data sent in response messages.
</p>

<p>
`内容~符号法$は、
要請~message内でも利用できる。
しかしながら，その発見性は応答~message程ではない。
この文書は、
要請~内で~supportされる内容~符号法を指示するために，~HTTP `Accept-Encoding$h ~headerを応答~内での利用~用に拡張する。
加えて、
状態s~code `415$st の定義を［
適切なときには `Accept-Encoding$h ~headerを内包することを推奨する
］ように更新する。
◎
Content codings can be used in request messages as well; however, discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field ([RFC7231], Section 5.3.4) for use in responses, to indicate the content codings that are supported in requests. It furthermore updates the definition of status code 415 (Unsupported Media Type) ([RFC7231], Section 6.5.13), recommending that the "Accept-Encoding" header field be included when appropriate.
</p>

	</section>
	<section id="section-2">
<h2 title="Notational Conventions">2. 表記規約</h2>

<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>
この文書は、
基底~HTTP仕様
— `7230-2$rfc, `7231-3.1.2$rfc —
に定義される各種用語を再利用する
◎
This document reuses terminology defined in the base HTTP specifications, namely Section 2 of [RFC7230] and Section 3.1.2 of [RFC7231].
</p>

	</section>
	<section id="section-3">
<h2 title="Using the 'Accept-Encoding' Header Field in Responses">3. 応答~内での `Accept-Encoding^h ~headerの利用-法</h2>

<p>
`Accept-Encoding$h は、
`RFC7231$r にて要請~headerのみとして定義されている。
◎
Section 5.3.4 of [RFC7231] defines "Accept-Encoding" as a request header field only.
</p>

<p>
この仕様は、
応答~headerにも `Accept-Encoding^h を許容するよう，その定義を拡げる。
応答~内に在るときは、［
資源は，当の応答が応対した要請にて受容する用意があった`内容~符号法$たち
］を指示する。
その `field-value$p が "`identity^c" のみを包含する場合、
~supportされる内容~符号法は無かったことを含意する。
◎
This specification expands that definition to allow "Accept-Encoding" as a response header field as well. When present in a response, it indicates what content codings the resource was willing to accept in the associated request. A field value that only contains "identity" implies that no content codings were supported.
</p>

<p>
この情報は、
当の応答が応対した要請に特有であることに注意。
~supportされる符号化法の集合は、
同じ~server上の他の資源~用のそれとは異なるかもしれない。
また、
時間~越しに変化したり，
要請の他の側面（`要請~method$など）に依存することもある。
◎
Note that this information is specific to the associated request; the set of supported encodings might be different for other resources on the same server and could change over time or depend on other aspects of the request (such as the request method).
</p>

<p>
状態s~code `415$st は、［
~MIME型, `内容~符号法$
］のどちらに関係する問題にも適用するものと定義されている。
`RFC7231$r
◎
Section 6.5.13 of [RFC7231] defines status code 415 (Unsupported Media Type) to apply to problems related to both media types and content codings.
</p>

<p>
~supportしない内容~符号法に因り要請に対し失敗した~serverは、
`415$st0 で応答する~OUGHT。
加えて、
その応答~内に `Accept-Encoding$h ~headerを内包して，~clientが［
当の課題は［
内容~符号法, ~MIME型
］のどちらに関係するか
］を判別できるようにする~OUGHT。
~MIME型に関係する課題との混同を避けるため、
`415^st0 を伴う要請に対し内容~符号法に無関係な事由で失敗した~serverは，
`Accept-Encoding$h ~headerを内包してはナラナイ。
◎
Servers that fail a request due to an unsupported content coding ought to respond with a 415 status and ought to include an "Accept-Encoding" header field in that response, allowing clients to distinguish between issues related to content codings and media types. In order to avoid confusion with issues related to media types, servers that fail a request with a 415 status for reasons unrelated to content codings MUST NOT include the "Accept-Encoding" header field.
</p>

<p>
応答における `Accept-Encoding$h の最も共通的な利用では、
~clientによる`内容~符号法$の楽観的な利用に対する応答~内に，状態s~code `415$st を伴うことになると予期されている。
しかしながら，この~headerは、［
未来のヤリトリを最適化するために内容~符号法が~supportされる
］ことを~clientに指示するためにも利用できる。
例えば，［
要請~payloadは`圧縮~符号法$の利用を正当化するほど十分~大きいものだったが，~clientがそうするのに失敗した
］とき、
`資源$は `2xx$st0 応答~内に この~headerを内包するかもしれない。
◎
It is expected that the most common use of "Accept-Encoding" in responses will have the 415 (Unsupported Media Type) status code, in response to optimistic use of a content coding by clients. However, the header field can also be used to indicate to clients that content codings are supported, to optimize future interactions. For example, a resource might include it in a 2xx response when the request payload was big enough to justify use of a compression coding but the client failed do so.
</p>

	</section>
	<section id="section-4">
<h2 title="Example">4. 例</h2>

<p>
~clientは、
"`compress$c" 内容~符号法（ `7231-3.1.2.1$rfc ）を利用して `POST^m 要請を提出したとする：
◎
A client submits a POST request using the "compress" content coding ([RFC7231], Section 3.1.2.1):
</p>

<pre class="lang-http">
POST /edit/ HTTP/1.1
Host: example.org
Content-Type: application/atom+xml;type=entry
Content-Encoding: compress

...圧縮された~payload...
</pre>
<!-- 
...compressed payload...
 -->

<p>
"`gzip$c" 内容~符号法しか許容しない~serverは、
この要請を却下する：
◎
The server rejects the request because it only allows the "gzip" content coding:
</p>

<pre class="lang-http">
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: gzip
Content-Length: 68
Content-Type: text/plain
</pre>

<p>
— この資源が要請~内で~supportする内容~符号法は "`gzip^c" のみである。
◎
This resource only supports the "gzip" content coding in requests.
</p>

<p>
この時点で，~clientは、
要請を~supportされる "`gzip^c" 内容~符号法で再試行できる。
◎
At this point, the client can retry the request with the supported "gzip" content coding.
</p>

<p>
要請~内ではどの内容~符号法も~supportしない~serverは、
次のように回答できる：
◎
Alternatively, a server that does not support any content codings in requests could answer with:
</p>

<pre class="lang-http">
HTTP/1.1 415 Unsupported Media Type
Date: Fri, 09 May 2014 11:43:53 GMT
Accept-Encoding: identity
Content-Length: 61
Content-Type: text/plain
</pre>

<p>
— この資源が要請~内で~supportする内容~符号法は無い。
◎
This resource does not support content codings in requests.
</p>

	</section>
	<section id="section-5">
<h2 title="Deployment Considerations">5. 配備~上の考慮点</h2>

<p>
要請における`内容~符号法$をまだ~supportしない~serverには、
`内容~符号法$を利用する要請に対し失敗することが要求される。
`RFC7231$r は、
この目的に状態s~code `415$st を定義する。
なので、
必要な唯一の変更は，その応答~内に［
値 "`identity^c" を伴う `Accept-Encoding$h ~header
］を内包することである。
◎
Servers that do not support content codings in requests already are required to fail a request that uses a content coding. Section 6.5.13 of [RFC7231] defines the status code 415 (Unsupported Media Type) for this purpose, so the only change needed is to include the "Accept-Encoding" header field with the value "identity" in that response.
</p>

<p>
何らかの`内容~符号法$を~supportする~serverであっても、
自身が~supportしない内容~符号法を伴う要請に対しては失敗することが要求される。
この仕様に準拠するためには、
~serverは，問題を通達するために状態s~code `415^st を利用した上で，
`Accept-Encoding$h ~headerを内包して 自身が~supportする内容~符号法を列挙する必要がある。
通例的に，~supportする内容~符号法の集合は 静的かつ少数なので、
この~headerを追加することは自明になる~OUGHT。
◎
Servers that do support some content codings are required to fail requests with unsupported content codings as well. To be compliant with this specification, servers will need to use the status code 415 (Unsupported Media Type) to signal the problem and will have to include an "Accept-Encoding" header field that enumerates the content codings that are supported. As the set of supported content codings is usually static and small, adding the header field ought to be trivial.
</p>

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

<p>
この仕様が追加するのは、
~supportされる`内容~符号法$の発見, および［
内容~符号法を~supportしないことに因る要請の失敗
］に対する診断法に限られる。
そのようなわけで、
新たな~securityの考慮点は導入されない
— ~HTTP11／~HTTP2
にて すでに在るもの（
`7231-9$rfc ／ `7540-10$rfc
）は別として。
◎
This specification only adds discovery of supported content codings and diagnostics for requests failing due to unsupported content codings. As such, it doesn't introduce any new security considerations over those already present in HTTP/1.1 (Section 9 of [RFC7231]) and HTTP/2 (Section 10 of [RFC7540]).
</p>

<p>
しかしながら，［
発見性を上げることと診断法
］の~~要点は、
要請~内で`内容~符号法$をより容易に利用-可能することである。
これは、
`gzip$c などの`圧縮~符号法$の利用eを~~促すことになるかもしれない
— それは、
~secure~channel越しに利用されるとき，
`BREACH$r などの~side-channel攻撃を可能化し得る（ `7540-10.6$rfc ）。
この文書の公表~時点では、
~HTTP要請における圧縮に BREACH の様な攻撃を適用し得る方法は，明瞭でない。
◎
However, the point of better discoverability and diagnostics is to make it easier to use content codings in requests. This might lead to increased usage of compression codings such as gzip (Section 4.2 of [RFC7230]), which, when used over a secure channel, can enable side-channel attacks such as BREACH (see Section 10.6 of [RFC7540] and [BREACH]). At the time of publication, it was unclear how BREACH-like attacks can be applied to compression in HTTP requests.
</p>

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

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

<p>
~HTTP~headerは、
`BCP90$r にて定義されるとおり，
`~message~header~registry＠~IANA-a/message-headers$
の中に登録される。
◎
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>

<p>
この文書は、
`Accept-Encoding$h ~headerの定義を更新する。
それに伴い，その~registryの恒久的~message~header名の `Accept-Encoding^h 項には、
この文書の `3$sec への参照が追加された。
◎
This document updates the definition of the "Accept-Encoding" header field. The "Permanent Message Header Field Names" registry has been updated as follows:
• Header Field Name ｜ Protocol ｜ Status ｜ Reference
• Accept-Encoding ｜ http ｜ standard ｜ Section 5.3.4 of [RFC7231] and Section 3 of this document
</p>

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

<p>
~HTTP`状態s~code$は、
`~HTTP状態s~code~registry＠~IANA-a/http-status-codes$
の中に登録される。
◎
HTTP status codes are registered within the "HTTP Status Codes" registry located at &lt;http://www.iana.org/assignments/http-status-codes&gt;.
</p>

<p>
この文書は、
状態s~code `415^st0 の定義を更新する。
それに伴い，その~registryにおける
`415^st の項には、
この文書の `3$sec への参照が追加された。
◎
This document updates the definition of the status code 415 (Unsupported Media Type). The "HTTP Status Codes" registry has been updated as follows: 
• Value Description Reference
• 415 Unsupported Media Type
• Section 6.5.13 of [RFC7231] and Section 3 of this document
</p>

	</section>
	<section id="n-acknowledgements">
<h2 title="Acknowledgements">謝辞</h2>

<p>
~HTTP~WGの参加者である次の方々に：
</p>

<p lang="en">
Thanks go to the Hypertext Transfer Protocol Working Group participants, namely Amos Jeffries, Ben Campbell, Mark Nottingham, Pete Resnick, Stephen Farrell, and Ted Hardie.
</p>

	</section>
</main></div>