HTTP 1.1 が改定されました

HTTPが改定されました。

HTTP 1.1 を規定していたRFC2616 Hypertext Transfer Protocol -- HTTP/1.1が廃止され、後継として以下の6つのRFCが公開されました。

変更は、曖昧さの排除や、無駄な空白文字や改行の排除などによりセキュリティを強化する方向の変更です。

革新的な何かが追加されてはおらず、バージョンもHTTP 1.1のままです。

変更点

RFC7230のA.2 に記載されているRFC2616からの変更点は以下のとおりです。

A.2. Changes from RFC 2616(原文)
The "identity" transfer coding token has been removed. (Sections 3.3 and 4) 圧縮方式からidenty 方式がなくなった
サポートされるのは以下の6種
  • chunked
  • compress
  • deflate
  • gzip
  • x-compress
  • x-gzip
Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. (Section 2.7.1) HTTP/HTTPSのURIに、ユーザ名やパスワードなどの情報を付加することが禁止になった
Registration of Transfer Codings now requires IETF Review (Section 8.4) 圧縮形式の定義は、IETFへの登録と認可が必要になった
The expectation to support HTTP/0.9 requests has been removed. (Appendix A) HTTP/0.9のサポートが必要ではなくなった
(必須ではなくなった)
HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is fundamentally a message-oriented protocol. Minimum supported sizes for various protocol elements have been suggested, to improve interoperability. (Section 3) HTTPメッセージのバッファリングを許容
Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. The ABNF productions defining header fields now only list the field value. (Section 3.2) 無効な空白文字が含まれるメッセージをリジェクトすることが求められるようになった
Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed where specifically defined in the ABNF. (Section 3.2.3) 空白文字の使用箇所は明示的に提示された
The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been clarified. The quoted-pair rule no longer allows escaping control characters other than HTAB.
Non-US-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (Section 3.2.6)
NUL文字をコメントなどに含めることは許容されなくなった
エスケープ文字としてのバックスラッシュの使い方を明確にした
ヘッダフィールド内の非US-ASCIIコンテンツは廃止(テキストルールから削除)

Empty list elements in list productions (e.g., a list header field containing ", ,") have been deprecated. (Section 7) 空のリストは禁止された
リストの構文もより厳格になった
Header fields that span multiple lines ("line folding") are deprecated. (Section 3.2.4) ヘッダーに改行を含む記述をすることは排除された
HTTP's approach to error handling has been explained. (Section 2.5) エラー処理の説明を追加
Bogus Content-Length header fields are now required to be handled as errors by recipients. (Section 3.3.2) コンテンツ長ヘッダが偽造されていた場合、エラーとして処理することが求められるようになった
Chunk length does not include the count of the octets in the chunk header and trailer. Line folding in chunk extensions is disallowed. (Section 4.1) チャンクでの転送時のチャンク長はヘッダーとトレーラーを含まないこととした。
チャンクで改行は許容しないこととなった
The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers have been restricted to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (Section 2.6) HTTPのHeaderのVersion フィールドにのせるバージョン名"HTTP/1.1"が大文字限定になり番号の桁数も1桁限定になった
The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven by methods or status codes) that affect it, and that new protocol elements cannot define such special cases.
CONNECT is a new, special case in determining message body length. "multipart/byteranges" is no longer a way of determining message body length detection. (Section 3.3.3)
メッセージ長を決定するアルゴリズムでの例外を排除し、より明確になった
The meaning of the "deflate" content coding has been clarified. (Section 4.2.2) deflateの定義明確になった
The semantics of the Upgrade header field is now defined in responses other than 101 (this was incorporated from [RFC2817]). Furthermore, the ordering in the field value is now significant. (Section 6.7) Upgadeヘッダーの構文が明確になった

The segment + query components of RFC 3986 have been used to define the request-target, instead of abs_path from RFC 1808. The asterisk-form of the request-target is only allowed with the OPTIONS method. (Section 5.3)
The term "Effective Request URI" has been introduced. (Section 5.5) "Effective Request URI"が新たに定義された。
例えば、
  GET /pub/WWW/TheProject.html HTTP/1.1
  Host: www.example.org:8080
から、
  http://www.example.org:8080/pub/WWW/TheProject.html
という"Effective Request URI" を組み立てた上でどう処理するか判断するように求めている。
Gateways do not need to generate Via header fields anymore. (Section 5.7.1) ゲートウェイが、VIA ヘッダを付加する必要がなくなった
Exactly when "close" connection options have to be sent has been clarified.
Also, "hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop in this specification doesn't exempt them. (Section 6.1)
CLOSEを送信すべきタイミングを明確にした。
永続的な接続をサポートしないクライアントはREQを送る毎にCLOSEを送信すること(MUST)
永続的な接続をサポートしないサーバーはは応答を返す毎にCLOSEを送信すること(MUST)
The limit of two connections per server has been removed. An idempotent sequence of requests is no longer required to be retried.
The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. Also, some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (Section 6.3)
サーバーあたり2接続数の制限がなくなりました。
Issues with the Keep-Alive and Proxy-Connection header fields in requests are pointed out, with use of the latter being discouraged altogether. (Appendix A.1.2) KEEP-ALIVE の問題を記述し、クライアントが、REQにProxy-Connectionヘッダーを含めないように推奨している。
The HTTPS URI scheme is now defined by this specification; previously, it was done in Section 2.4 of [RFC2818]. Furthermore, it implies end-to-end security. (Section 2.7.2) RFC2818で定義されていたHTTPSのURIスキームがRFC7230で定義されるようになった
This specification now defines the Upgrade Token Registry, previously defined in Section 7.2 of [RFC2817]. (Section 8.6) RFC2817の7.2に記載されていた "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry"が 8.6に収容された


上記はRFC7230により変更になった分ですが、RFC2616からの変更点は、以下にも記載されています。


歴代HTTP
RFC2616
(失効)
2代目 HTTP1.1 "Hypertext Transfer Protocol -- HTTP/1.1"
1999年に発行
今回7230から7235に置き換えられた
RFC2068
(失効)
初代のHTTP1.1 "Hypertext Transfer Protocol -- HTTP/1.1"
2616に置き換えられている 
RFC1945 HTTP 1.0 "Hypertext Transfer Protocol -- HTTP/1.0"

最近のブログ記事

SORACOM,HLR持ちeSIM対応
SORACOMが自前のHLRを持ち、自…
準天頂衛星4機体制に
h2{ font-size:12…
Windows 10 mobile終了
Windows 10 mobileの新機…
カスタム検索

月別 アーカイブ