紹介！HTTP関連最新仕様！

2015/12/19

goto

こんにちは、インフラストラクチャ部の後藤です。

このエントリは GREE Advent Calendar 2015の20日目の記事です。

GREE Engineers' Blogでは毎回HTTP/2関連の記事を書かせていただいております。

HTTP/2の仕様自体は RFC7540 として標準化されました。ですが、HTTPに関する周辺仕様の話はまだまだ続いています(細かい議論が多いですが....)。

そこで今回は、IETFの(主にHTTPbis WG)HTTPに関連する仕様事情について説明していきたいと思います。

HTTPbis WG

HTTP/1.1の改訂版、HTTP/2やその関連仕様に関して議論していたWGです。

現在もHTTPに関する仕様について議論されています。今回はココで扱われているドラフトについて紹介します。

カッコでその仕様のステータスを書いてあります。DraftはRFCとなる前の段階で、Individual DraftからWG Draftとなり、RFCとなります。

HTTP Client-Initiated Content-Encoding(RFC 7694)

クライアントからContent-Encodingを使って、リクエストボディのエンコーディングを示せるようにする仕様。

今まで添付ファイルなどをクライアント側から圧縮して送信する仕組みはありませんでした。クライアント側からContent-Encodingヘッダを送信する手順及び、サーバ側からAccept-Encodingヘッダを送信する手順が仕様化されました。

     POST /edit/ HTTP/1.1
     Host: example.org
     Content-Type: application/atom+xml;type=entry
     Content-Encoding: gzip

     ...compressed payload...

POST /edit/ HTTP/1.1

Host: example.org

Content-Type: application/atom+xml;type=entry

Content-Encoding: gzip

...compressed payload...

The ALPN HTTP Header Field (RFC 7639)

クライアントがCONNECTメソッドで接続する際に、トンネルさせるプロトコル明示できるようにする仕様。CONNECTメッソドで接続し、TLSで保護されたプロトコルがトンネルされる場合は、TLS ClientHelloのALPN拡張にはALPNヘッダで指定された識別子リストが入ります。

     CONNECT www.example.com HTTP/1.1
     Host: www.example.com
     ALPN: h2, http%2F1.1

CONNECT www.example.com HTTP/1.1

Host: www.example.com

ALPN: h2, http%2F1.1

An HTTP Status Code to Report Legal Obstacles (WG Draft)

法的な理由によりページを表示できないことを示すレスポンスステータスコード 451 の追加。

   HTTP/1.1 451 Unavailable For Legal Reasons
   Content-Type: text/html

   <html>
    <head><title>Unavailable For Legal Reasons
    <body>
     <h1>Unavailable For Legal Reasons>/h1>
     <p>This request may not be serviced in the Roman Province
     of Judea due to the Lex Julia Majestatis, which disallows
     access to resources hosted on servers deemed to be
     operated by the People's Front of Judea.>/p>
    </body>
   </html>

HTTP/1.1 451 Unavailable For Legal Reasons

Content-Type: text/html

<html>

<head><title>Unavailable For Legal Reasons

<body>

<h1>Unavailable For Legal Reasons>/h1>

<p>This request may not be serviced in the Roman Province

of Judea due to the Lex Julia Majestatis, which disallows

access to resources hosted on servers deemed to be

operated by the People's Front of Judea.>/p>

</body>

</html>

HTTP Alternative Services (WG Draft)

サーバの提供しているリソースを、別のホスト、別のポート、別のプロトコルでも提供できることをクライアントに通知可能にする仕様。

HTTPレスポンスヘッダもしくは、HTTP/2のALTSVCフレームで通知可能です。

(プロトコル，ホスト，ポート)と言う形で情報を通知する。

例えば運用上の理由で接続するサーバを切り替えたり、使用するプロトコルを切り替えることができる。

HTTPレスポンスで以下の様にalt-svcヘッダを付加します。

Alt-Svc: h2="new.example.org:80"

1	Alt-Svc: h2="new.example.org:80"

例えばgoogle.comではQUICのために以下の様なレスポンスヘッダをつけてきます

alt-svc:quic="www.google.com:443"; ma=600; v="30,29,28,27,26,25"

1	alt-svc:quic="www.google.com:443"; ma=600; v="30,29,28,27,26,25"

Opportunistic Security for HTTP (WG Draft)

通信相手を認証しない暗号通信(日和見暗号)を可能にする仕様です。広域盗聴攻撃からの保護として日和見暗号は非常に重要です。

http://から始まるURLでもHTTP over TLSで通信を行います。

   GET /index.html HTTP/1.1
   Host: example.com

1 2	GET /index.html HTTP/1.1 Host: example.com

    HTTP/1.1 200 OK
    Content-Type: text/html
    Cache-Control: max-age=600
    Age: 30
    Date: Thu, 1 May 2014 16:20:09 GMT
    HTTP-TLS: ma=3600

HTTP/1.1 200 OK

Content-Type: text/html

Cache-Control: max-age=600

Age: 30

Date: Thu, 1 May 2014 16:20:09 GMT

HTTP-TLS: ma=3600

サーバからHTTP-TLSヘッダを送信することで、クライアントは:443のAlternate-Serviceとして解釈し、日和見暗号通信が可能になります。

Reactive Certificate-Based Client Authentication in HTTP/2 (Indevisual Draft)

TLSネゴシエーションをした後に、クライアントが特定のリソースを要求した際に、サーバが追加で証明書を用いたクライアント認証を行いたい場合があります。

HTTP/1.1 + TLS/1.2ではTLS Renegotiationの手順でクライアント証明書を用いた認証を行っていました。HTTP/2ではTLS Renegotiationが禁止されているためこの手順が出来ません。

HTTP/2 + TLS1.2 やHTTP/2 + TLS1.3で、TLSネゴシエーション終了後に改めて証明書を用いたクライアント認証を可能にする仕様。

HTTP/2にWAITING_FOR_AUTHフレームを、TLS Extentionにapplication_context_idを追加し、クライアント認証を行う理由となったリクエストを紐付ける事ができるようになっています。リクエストが多重化されているHTTP/2でも、どのリクエストに対してクライアント認証を行っているのかが識別できます。

Accept-Push-Policy Header Field (Individual Draft)

クライアントがHTTP/2のサーバプッシュを、リクエスト毎に制御できるようにする仕様。

HTTPリクエストのaccept-push-policyヘッダで望むサーバプッシュの動作を通知します。

   :method = GET
   :scheme = https
   :path = /index.html
   host = example.org
   accept = text/html
   accept-push-policy = none

:method = GET

:scheme = https

:path = /index.html

host = example.org

accept = text/html

accept-push-policy = none

none = サーバプッシュを行わない
default = サーバのデフォルトの挙動
head = HEADメソッドのレスポンス
fast-load = first renderingに必要なリソースをプッシュする

Cookie Prefixes (Individual Draft)

Cookieの名前のプレフィックスを用いてCookieの属性を固定化する。Cookieを共有するサイト間で、意図せぬ形で属性を変更されないようにする。

Set-Cookie: $Secure-SID=12345; Secure; Domain=example.com

1	Set-Cookie: $Secure-SID=12345; Secure; Domain=example.com

$Sercureプレフィックスを付けることで、Secure属性が付いたSet-Cookieのみ受け付けるようになります。

その他にもDomain属性がなく、PATH属性に/が指定されている事を示す$Host-プレフィックスもあります。

Deprecate modification of 'secure' cookies from non-secure origins (Individual Draft)

CookieのSecure属性を、非セキュアオリジンからSecure属性を付与したり、既に保存されているSecure属性がついてるCookieを上書きできないようにする仕様。

Chromeでは実装の検討が始まっています。

First-Party-Only Cookies (Individual Draft)

Cookieに新しい属性としてFirst-Party-Only属性を追加する。

この属性が付与されたCookieは、First-Partyのサイトへのリクエストのみにしか送信されない。

The ORIGIN HTTP/2 Frame (Individual Draft)

HTTP/2では一つのコネクション上で複数オリジンのリクエスト・レスポンスが行われます。ただし、リクエストを送信したもののサーバ側がレスポンスを出来無いオリジンの場合もあります。

サーバ側から提供可能なオリジンを通知するために、HTTP/2の拡張フレームとしてORIGINフレームを追加する仕様

TCP Tuning for HTTP (Individual Draft)

プロトコルの仕様に関するDraftではなく、ベストプラクティスについて言及したDraft。

HTTPを使う際にTCPチューニングに付いて、Linuxの設定例など具体的な説明も含めて記述されている。

以下の5つの章に分かられてプラティクスが紹介されている。

Socket planning
TCP handshake
TCP transfers
Re-using connections
Closing connections

その他

大分長くなってしまいましたが、その他にもHTTPを用いたプッシュ通知を出す仕様がWebPush WGで議論されています。こちらは、まだまだコアスペックの議論が中心ですので今からおってみるのも面白いと思います。

また、今話題のQUICもIndividual Draftとなっております（Google社による実装はさらに進んでいますが）。

さらに、具体的な仕様はまだですが、6月に行われたHTTP Workshopでは暗号化したままリソースをキャッシュさせるBlind CacheやHTTP/3と言ったキーワードも出てきておりまだまだHTTPから目は離せません。

最後に

今回は、現在アクティブな仕様について幾つか紹介しました。

自分でも追いきれてない部分はあり、全ては紹介しきれておりません(HTTP Client Hints とか、The Key HTTP Response Header Fieldとか)

是非興味がある方は関連WGのメーリングリストを読むことをオススメします。誰でも無料で読むことができるので、最新仕様についてどのような議論がされているか追うのもまた一つの楽しみかと思います。(下記URLの List Archive よりMLを確認できます)

HTTPbis WG https://datatracker.ietf.org/wg/httpbis/
WebPush WG https://datatracker.ietf.org/wg/webpush/
HTTPAuth WG https://datatracker.ietf.org/wg/httpauth/
RTCWeb WG https://datatracker.ietf.org/wg/rtcweb/

明日は、社内Ubuntuマスター松澤さんによる「Ubuntu 15.10リリース記念オフラインミーティング」の記事です。