https://lepidum.co.jp/ Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.
h2-14はどう変わる
IETF90レポート
株式会社レピダム
前田 薫 (@mad_p)
http2 勉強会 #5 2014/07/30
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
目次
 draft-14, HPACK-09の変更点(予想)
 前回の報告からの差分
 前回: http2 hackathon #2 2014/5
 draft-12, HPACK-07
 IETF90報告
 proxy
 その他
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
h2-14 はどう変わる
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HTTP/2基本仕様ドラフト
 IETFドラフトの最近の歴史
 draft-ietf-httpbis-http2 (h2)
 日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-13/
 draft-ietf-httpbis-header-compression (HPACK)
http2study #5 2014/07/29
Date h2 HPACK http2studyでの解説 備考
2014/02/13 10 06 #4 (2014/3)
2014/04/03 11 07
2014/04/23 12 hackerthon #2 (2014/5) HPACK更新なし
2014/06/17 13 08
近日中?? 14 09 #5 (2014/07) 現時点での予測
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
h2-13, HPACK-08までの変更点
 全体
 拡張性が復活(-09でなくなったもの)
 フレームタイプ、SETTINGに拡張を許す
 既存部分の意味を変える拡張は事前にSETTINGSによ
るネゴシエーションをしてから使う
 例: per-frame gzip, big frame
 ストリーム優先度: dependency-based priority
 参考: https://nghttp2.org/blog/2014/04/27/how-
dependency-based-prioritization-works
 close後のストリームにもPRIORITY適用可能に
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
接続確立まで
 バージョン識別子「h2c」(c = cleartext)
 暗号化されていないTCP接続上のHTTP/2
 TLS暗号スイートを限定
 AEADモードの強制
 Connection Preface
 Connection Headerから名前変更
 AltSvcは拡張仕様に
 ALTSVCフレームも拡張に
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Frame全般
 Frame Types
 ALTSVC 削除 (拡張仕様に)
 BLOCKED 削除 (元々-12だけの予定だった)
 パディング
 256オクテットまで
 PAD_LOW, PAD_HIGH → PADDING
 PUSH_PROMISEに追加、CONTINUATIONから削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
DATA Frame
 per-frame GZip圧縮
 拡張に追い出して削除
 content-encodingヘッダの要件も合わせて削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HPACK
 リテラル文字列に「ヘッダテーブルに追加
しない」オプション
 圧縮率観測攻撃の対象になるヘッダで使用
 例: Authorization Basic
 主にプロキシに対する指示
 ハフマンテーブルの更新
 static headerテーブルの更新
 SETTINGS_HEADER_TABLE_SIZE 変更後に最大
テーブルサイズをHPACK層でも送る
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
draft-14, HPACK-09の変更点(予想)
 Editor's copy
 http://http2.github.io/http2-spec/index.html
 http://http2.github.io/http2-spec/compression.html
 6月のInterimその前後のMLでの議論を反映
 IETF90では議論がなかった
 h2-14がWorking Group Last Call (WGLC)になる
気配
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
変更点予想一覧
 h2-14
 HTTPレスポンスコード 1xx が復活
 フレームサイズ上限→16M octets (Large Frames)
 SETTINGS_MAX_HEADER_LIST_SIZE
 pseudo headers(「:」で始まるもの)は最初に
 segment削除
 HPACK-09
 reference set削除
 同一ヘッダ名の値結合ルールも合わせて削除
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
reference set削除(YATTA!)
 reference setとは
 前回のHEADERSの中身を覚えておき、差分だけ送信
 同一のヘッダフィールドは送らない
 まったく同一の場合は空のHEADERSフレームを送る
 reference setの問題点
 最後まで読まないと中身がわからない
 接続先(:authority, :scheme)が不明
 ヘッダの順番が保たれない
 圧縮率に貢献するというデータがない
 実装がややこしくなりバグの元
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Large Frames (1/2)
 フレームの最大長を 2^24 - 1 (16M octets)に
 Frame HeaderのLengthフィールドは24bitに
 理由: でかいデータを速い回線で送りたい
http2study #5 2014/07/29
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length (24) |
+---------------+---------------+---------------+
| Type (8) | Flags (8) |
+-+-+-----------+---------------+-------------------------------+
|R| Stream Identifier (31) |
+=+=============================================================+
| Frame Payload (0...) ...
+---------------------------------------------------------------+
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Large Frames (2/2)
 受信可能なフレーム最大長のSETTINGS項目
 SETTINGS_MAX_FRAME_SIZE
 受信側が「自分は受け取れるよ」と宣言
 デフォルトは 2^14 (16384=16K octets)
 相手がこれを送ってくるまでは 16384 を超える大き
さのフレームを送ってはいけない
 処理系は16384 octetを処理できなければならない
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
pseudo headers (:headers)
 :authority, :pathなどはサーバー動作を決め
るために早めにほしい
 reference setがあるとどっちにしろヘッダブ
ロックを全部読まないとわからなかった
 :authorityはほぼ変わらない
 reference setがなくなったので、ヘッダはス
トリーミング処理したい
 → 先頭にまとめて送る
 オレオレ:headerを作るのも禁止。拡張でやれ
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
SETTINGS_MAX_HEADERS_LIST_SIZE
 HPACK後、1フレームにおさまらないヘッダ
は分割
 HEADERS, CONTINUATION, ...
 PUSH_PROMISE, CONTINUATION, ...
 これらのフレームの間に他のstreamを送っては
いけない → head-of-line blockingが発生し得る
 受信できる最大ブロック長を相手に知らせ
る(advisory)
 受信できないサーバーは431を返す
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF90レポート
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
IETF90概要
 Toronto
 2014/07/20-25
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
httpbis WG
 Monday
 proxyに関する議論
 Tuesday
 その他の議論
 議事録
 https://github.com/httpwg/wg-materials/blob/gh-
pages/ietf90/minutes.md
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシの現状について
 HTTP/2におけるプロキシについて(Adam)
 SPDYではプロキシがあって通過できない人がい
る
 コンテンツfilteringはクライアントでやるべき
 Trusted Proxyとコスト(Peter)
 ネットが遅い地域ではOpera Miniが普及
 サーバー側でTLSをほどき、高圧縮で送信
 CDNではラストマイルはサポートできない
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
Explicitly Authenticated Proxy(Salvatore)
 userのexplicit consent下で動くプロキシ
 これまでとは別のカテゴリのプロキシ
 reduce data usage
 content filtering
 accessには干渉しないが、optional servicesを提
供するもの
 Proxy Certificate
 opt outの必要性
 per requestではなくブラウザ設定で
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
そもそもProxyって何だ(mnot)
 HTTP/1.1ではどう定義されているか
 explicitly allows transformation and cache
 explicitly configured by clients
 HTTPS request is end-to-end
 これらのプロキシの定義を変えるのは大変
 機能追加ではなく現在のコンセンサスの変更である
 IETFは政治的にはサイドを取らないが、↑を選ぶとサイドを
取ることになる
 What can we do?
 publish "proxy problem" draft
 standardize proxy.pac
 find other ways to address underlying use cases
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシのディスカッション
 MITMプロキシの問題
 オリジンサーバーの証明書を渡せない
 end-2-endセキュリティーではない
 「HTTPがMITMを許容」なんて見出し見たいか?
 保護の必要なコンテンツの分離
 サーバーが秘匿性を表明したい
 ムービーだから内容は秘密じゃない
 フレームごと暗号化は考えたけど複雑すぎ
 トレードオフと選択は選択者によって違う
 検閲は分けて考えないといけない
 アフォーダンスが必要だ。選択肢だけではダメ
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
プロキシディスカッションまとめ
 Mark
 HTTPS is inviolate
 Maybe some interest in opt in to soften that
 Some interest in adorning TLS
 Interest in normalizing what an intercepting proxy is
 Interest in encrypted caching.
 Open issue on how opportunistic security interacts
with a proxy
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
HTTP/2以外の仕様
 HTTP/1.1 → RFC7230-5
 RFC2616を分割、6つのRFCになった。http/2ではそのうちの1
つだけを置きかえる(wire format)
 goals: wire formatとそれ以外を分離
 他の仕様にあったものでbase RFCにあるべきだったものを
cherry-pickingした
 RFC7238: 308 permanent redirect
 expirimental → proposed standard
 RFC5987: character set
 UTF-8だけを要求すればよく、ISO-8859-1 必須はドロップしてよい
 RFC6266: Use of the Content-Disposition Header Field
 Proposed Standard → Internet Standard.
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
その他の文書の検討
 draft-nakajima-httpbis-http2-interop-survey
 draft-ietf-httpbis-alt-svc
 拡張になったAltSvcのissuesについて
 draft-ietf-http2-encryption
 日和見暗号とHTTP/2の関係
 draft-hutton-httpbis-connect-protocol
 WebRTCがHTTP/2トンネルを使って送信されて
いることがわかるようにしてほしい → 炎上
http2study #5 2014/07/29
Copyright © 2004-2014 Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/
今後の予定
 8月 WG Last Call
 次のinterimはあるのか?

HTTP/2 draft 14 preview and IETF90 httpbis WG Report

  • 1.
    https://lepidum.co.jp/ Copyright ©2004-2014 Lepidum Co. Ltd. All rights reserved. h2-14はどう変わる IETF90レポート 株式会社レピダム 前田 薫 (@mad_p) http2 勉強会 #5 2014/07/30 http2study #5 2014/07/29
  • 2.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 目次  draft-14, HPACK-09の変更点(予想)  前回の報告からの差分  前回: http2 hackathon #2 2014/5  draft-12, HPACK-07  IETF90報告  proxy  その他 http2study #5 2014/07/29
  • 3.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ h2-14 はどう変わる http2study #5 2014/07/29
  • 4.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HTTP/2基本仕様ドラフト  IETFドラフトの最近の歴史  draft-ietf-httpbis-http2 (h2)  日本語訳 http://summerwind.jp/docs/draft-ietf-httpbis-http2-13/  draft-ietf-httpbis-header-compression (HPACK) http2study #5 2014/07/29 Date h2 HPACK http2studyでの解説 備考 2014/02/13 10 06 #4 (2014/3) 2014/04/03 11 07 2014/04/23 12 hackerthon #2 (2014/5) HPACK更新なし 2014/06/17 13 08 近日中?? 14 09 #5 (2014/07) 現時点での予測
  • 5.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ h2-13, HPACK-08までの変更点  全体  拡張性が復活(-09でなくなったもの)  フレームタイプ、SETTINGに拡張を許す  既存部分の意味を変える拡張は事前にSETTINGSによ るネゴシエーションをしてから使う  例: per-frame gzip, big frame  ストリーム優先度: dependency-based priority  参考: https://nghttp2.org/blog/2014/04/27/how- dependency-based-prioritization-works  close後のストリームにもPRIORITY適用可能に http2study #5 2014/07/29
  • 6.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 接続確立まで  バージョン識別子「h2c」(c = cleartext)  暗号化されていないTCP接続上のHTTP/2  TLS暗号スイートを限定  AEADモードの強制  Connection Preface  Connection Headerから名前変更  AltSvcは拡張仕様に  ALTSVCフレームも拡張に http2study #5 2014/07/29
  • 7.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Frame全般  Frame Types  ALTSVC 削除 (拡張仕様に)  BLOCKED 削除 (元々-12だけの予定だった)  パディング  256オクテットまで  PAD_LOW, PAD_HIGH → PADDING  PUSH_PROMISEに追加、CONTINUATIONから削除 http2study #5 2014/07/29
  • 8.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ DATA Frame  per-frame GZip圧縮  拡張に追い出して削除  content-encodingヘッダの要件も合わせて削除 http2study #5 2014/07/29
  • 9.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HPACK  リテラル文字列に「ヘッダテーブルに追加 しない」オプション  圧縮率観測攻撃の対象になるヘッダで使用  例: Authorization Basic  主にプロキシに対する指示  ハフマンテーブルの更新  static headerテーブルの更新  SETTINGS_HEADER_TABLE_SIZE 変更後に最大 テーブルサイズをHPACK層でも送る http2study #5 2014/07/29
  • 10.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ draft-14, HPACK-09の変更点(予想)  Editor's copy  http://http2.github.io/http2-spec/index.html  http://http2.github.io/http2-spec/compression.html  6月のInterimその前後のMLでの議論を反映  IETF90では議論がなかった  h2-14がWorking Group Last Call (WGLC)になる 気配 http2study #5 2014/07/29
  • 11.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 変更点予想一覧  h2-14  HTTPレスポンスコード 1xx が復活  フレームサイズ上限→16M octets (Large Frames)  SETTINGS_MAX_HEADER_LIST_SIZE  pseudo headers(「:」で始まるもの)は最初に  segment削除  HPACK-09  reference set削除  同一ヘッダ名の値結合ルールも合わせて削除 http2study #5 2014/07/29
  • 12.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ reference set削除(YATTA!)  reference setとは  前回のHEADERSの中身を覚えておき、差分だけ送信  同一のヘッダフィールドは送らない  まったく同一の場合は空のHEADERSフレームを送る  reference setの問題点  最後まで読まないと中身がわからない  接続先(:authority, :scheme)が不明  ヘッダの順番が保たれない  圧縮率に貢献するというデータがない  実装がややこしくなりバグの元 http2study #5 2014/07/29
  • 13.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Large Frames (1/2)  フレームの最大長を 2^24 - 1 (16M octets)に  Frame HeaderのLengthフィールドは24bitに  理由: でかいデータを速い回線で送りたい http2study #5 2014/07/29 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length (24) | +---------------+---------------+---------------+ | Type (8) | Flags (8) | +-+-+-----------+---------------+-------------------------------+ |R| Stream Identifier (31) | +=+=============================================================+ | Frame Payload (0...) ... +---------------------------------------------------------------+
  • 14.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Large Frames (2/2)  受信可能なフレーム最大長のSETTINGS項目  SETTINGS_MAX_FRAME_SIZE  受信側が「自分は受け取れるよ」と宣言  デフォルトは 2^14 (16384=16K octets)  相手がこれを送ってくるまでは 16384 を超える大き さのフレームを送ってはいけない  処理系は16384 octetを処理できなければならない http2study #5 2014/07/29
  • 15.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ pseudo headers (:headers)  :authority, :pathなどはサーバー動作を決め るために早めにほしい  reference setがあるとどっちにしろヘッダブ ロックを全部読まないとわからなかった  :authorityはほぼ変わらない  reference setがなくなったので、ヘッダはス トリーミング処理したい  → 先頭にまとめて送る  オレオレ:headerを作るのも禁止。拡張でやれ http2study #5 2014/07/29
  • 16.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ SETTINGS_MAX_HEADERS_LIST_SIZE  HPACK後、1フレームにおさまらないヘッダ は分割  HEADERS, CONTINUATION, ...  PUSH_PROMISE, CONTINUATION, ...  これらのフレームの間に他のstreamを送っては いけない → head-of-line blockingが発生し得る  受信できる最大ブロック長を相手に知らせ る(advisory)  受信できないサーバーは431を返す http2study #5 2014/07/29
  • 17.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ IETF90レポート http2study #5 2014/07/29
  • 18.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ IETF90概要  Toronto  2014/07/20-25 http2study #5 2014/07/29
  • 19.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ httpbis WG  Monday  proxyに関する議論  Tuesday  その他の議論  議事録  https://github.com/httpwg/wg-materials/blob/gh- pages/ietf90/minutes.md http2study #5 2014/07/29
  • 20.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシの現状について  HTTP/2におけるプロキシについて(Adam)  SPDYではプロキシがあって通過できない人がい る  コンテンツfilteringはクライアントでやるべき  Trusted Proxyとコスト(Peter)  ネットが遅い地域ではOpera Miniが普及  サーバー側でTLSをほどき、高圧縮で送信  CDNではラストマイルはサポートできない http2study #5 2014/07/29
  • 21.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ Explicitly Authenticated Proxy(Salvatore)  userのexplicit consent下で動くプロキシ  これまでとは別のカテゴリのプロキシ  reduce data usage  content filtering  accessには干渉しないが、optional servicesを提 供するもの  Proxy Certificate  opt outの必要性  per requestではなくブラウザ設定で http2study #5 2014/07/29
  • 22.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ そもそもProxyって何だ(mnot)  HTTP/1.1ではどう定義されているか  explicitly allows transformation and cache  explicitly configured by clients  HTTPS request is end-to-end  これらのプロキシの定義を変えるのは大変  機能追加ではなく現在のコンセンサスの変更である  IETFは政治的にはサイドを取らないが、↑を選ぶとサイドを 取ることになる  What can we do?  publish "proxy problem" draft  standardize proxy.pac  find other ways to address underlying use cases http2study #5 2014/07/29
  • 23.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシのディスカッション  MITMプロキシの問題  オリジンサーバーの証明書を渡せない  end-2-endセキュリティーではない  「HTTPがMITMを許容」なんて見出し見たいか?  保護の必要なコンテンツの分離  サーバーが秘匿性を表明したい  ムービーだから内容は秘密じゃない  フレームごと暗号化は考えたけど複雑すぎ  トレードオフと選択は選択者によって違う  検閲は分けて考えないといけない  アフォーダンスが必要だ。選択肢だけではダメ http2study #5 2014/07/29
  • 24.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ プロキシディスカッションまとめ  Mark  HTTPS is inviolate  Maybe some interest in opt in to soften that  Some interest in adorning TLS  Interest in normalizing what an intercepting proxy is  Interest in encrypted caching.  Open issue on how opportunistic security interacts with a proxy http2study #5 2014/07/29
  • 25.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ HTTP/2以外の仕様  HTTP/1.1 → RFC7230-5  RFC2616を分割、6つのRFCになった。http/2ではそのうちの1 つだけを置きかえる(wire format)  goals: wire formatとそれ以外を分離  他の仕様にあったものでbase RFCにあるべきだったものを cherry-pickingした  RFC7238: 308 permanent redirect  expirimental → proposed standard  RFC5987: character set  UTF-8だけを要求すればよく、ISO-8859-1 必須はドロップしてよい  RFC6266: Use of the Content-Disposition Header Field  Proposed Standard → Internet Standard. http2study #5 2014/07/29
  • 26.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ その他の文書の検討  draft-nakajima-httpbis-http2-interop-survey  draft-ietf-httpbis-alt-svc  拡張になったAltSvcのissuesについて  draft-ietf-http2-encryption  日和見暗号とHTTP/2の関係  draft-hutton-httpbis-connect-protocol  WebRTCがHTTP/2トンネルを使って送信されて いることがわかるようにしてほしい → 炎上 http2study #5 2014/07/29
  • 27.
    Copyright © 2004-2014Lepidum Co. Ltd. All rights reserved.https://lepidum.co.jp/ 今後の予定  8月 WG Last Call  次のinterimはあるのか?