紹介！HTTP関連最新仕様！

2015/12/19

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

このエントリは 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ヘッダを送信する手順が仕様化されました。

The ALPN HTTP Header Field (RFC 7639)

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

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

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

HTTP Alternative Services (WG Draft)

サーバの提供しているリソースを、別のホスト、別のポート、別のプロトコルでも提供できることをクライアントに通知可能にする仕様。
HTTPレスポンスヘッダもしくは、HTTP/2のALTSVCフレームで通知可能です。
(プロトコル，ホスト，ポート)と言う形で情報を通知する。
例えば運用上の理由で接続するサーバを切り替えたり、使用するプロトコルを切り替えることができる。
HTTPレスポンスで以下の様にalt-svcヘッダを付加します。
例えばgoogle.comではQUICのために以下の様なレスポンスヘッダをつけてきます

Opportunistic Security for HTTP (WG Draft)

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

サーバから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ヘッダ で望むサーバプッシュの動作を通知します。
 

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

 

Cookie Prefixes (Individual Draft)

Cookieの名前のプレフィックスを用いてCookieの属性を固定化する。Cookieを共有するサイト間で、意図せぬ形で属性を変更されないようにする。
$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を確認できます)

 

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