[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICのAckとロスリカバリについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze

12月8日に現在標準化が進められているQUICの仕様のdraft-17が出ました。 以下の記事で書いたように、"HTTP over QUIC" のHTTP/3への名称が含まれています。 asnokaze.hatenablog.com その他にも幾つかの変更が含まれているのでざっと目を通す。 「Hypertext Transfer Protocol Version 3 (HTTP/3)」 「Using Transport Layer Security (TLS) to Secure QUIC」 「QUIC Loss Detection and Congestion Control」 「QUIC: A UDP-Based Multiplexed and Secure Transport」 この draft-17 は「9th Implementation Draft」であり、2019年1月に東京

[追記] QUIC, HTTP/3 関連記事 まるっと解説記事を書き直しました asnokaze.hatenablog.com その他もどうぞ QUIC, HTTP/3の標準化状況を確認したい (2019年11月版) - ASnoKaze blog HTTP/3と新しいプライオリティ制御方式について - ASnoKaze blog QUICのコネクションマイグレーションについて - ASnoKaze blog QUICの暗号化と鍵の導出について - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP

20190821 追記 この提案は廃案されました https://mailarchive.ietf.org/arch/msg/doh/qkmhh93Id6XIngH3LJwp-HokH_Y DNS over HTTPS(DoH)の標準化が進められており、引き続き注目を集めている。 asnokaze.hatenablog.com 一方で、DoHサーバをどのように見つけるか、見に行かせるかの議論が始まっています。 JPNIC Blog :: DNS over HTTPSとDHCP －IETF102における議論－ で紹介されている通り、先月行われたIETF102でもDNSリゾルバの識別子と利用についてのBoFがありました。 例えば、設定ファイルだったり、DHCPでDNSサーバを設定する際にDoHサーバを設定する際にどうすればいいか、どのようディスカバリさせるかといった議論です。 その流れで、Do

2017/09/13 更新 Googleのブログで公式アナウンスが出ました。 一部対応者の表記がDigiCertになりましたが、大きなスケジュール変更はありません security.googleblog.com 今年の上旬より、Chromeが古いシマンテックの証明書を失効扱いするニュースが世間を賑わせたのは記憶にあたらしいかと思います。 internet.watch.impress.co.jp 議論は続いており、Blinkの開発者メーリングリストの「Intent to Deprecate and Remove: Trust in existing Symantec-issued Certificates」にてシマンテックとGoogle(+ Mozilla)が協議を重ねていることがわかります。 本日、「Google ChromeとChromiumプロジェクトを代表して」という形で最終になるで

2018/2 asnokaze.hatenablog.com Googleの考案したQUICは現在IETFで標準化が進められており、多くの人々によって議論されております。QUICの中身よりも現在の状況について、自分用に整理する。 Issueが追えてないので残念感ある。 概要 UDP上で信頼性のある暗号化されたHTTP/2通信を行うQUICは、もともとはGoogleが考案・実装・実証をすすめられていた。 IETFの会合で数度のBoF(WG設立前の議論)の開催へて、2016年にQUIC WGが出来QUICの標準化を進めることが決定した。 QUIC WGのゴールはCharterにかかれている通り、大まかに以下のとおりである アプリケーションのために、コネクション及びトランスポートの遅延を最小化すること head-of-lineブロッキングの無い多重化を提供すること エンドポイントの変更のみでデプ

追記 10190510 関連して、このような動きもあります。 Cookie の SameSite=Lax をデフォルトにする提案仕様 - ASnoKaze blog Cookieの仕様と拡張仕様 HTTPのCookieの仕様は RFC 6265 - HTTP State Management Mechanism で定義されております。 2015年頃より、IETFのHTTPbisワーキンググループではCookieのセキュリティを向上させる目的で拡張仕様が3つほど議論されていました。 Cookie Prefixes 付与する属性をCookie名に含めることで、変更できなくする(Chrome51, Firefox50) Same-Site Cookies SameSite属性の追加。クロスサイトへのリクエスト時にはCookieヘッダを付けなくなる(Chrome 51) Deprecate mod

20190408追記 最新版について記事を書きました asnokaze.hatenablog.com QUICのヘッダ圧縮であるQPACKについて 現在のQUICの策定中仕様の一つである「Hypertext Transfer Protocol (HTTP) over QUIC」では、QUICでもHTTPヘッダの圧縮にHPACKを使用することになっていますが、新しくQUIC用のヘッダ圧縮方式として「HTTP over QUIC - Mapping and Header Compression」という仕様でQPACKなるものが提案されています。 背景 QUICとHPACK HTTP/2ではヘッダ圧縮方式としてHPACKと呼ばれる方式を利用します。HPACKはRFC 7541「HPACK: Header Compression for HTTP/2」で標準化されています。 HPACKはヘッダ名と

W3CでFeature Policyという仕様が議論されています。仕様は著者であるGoogleのIlya Grigorik氏のリポジトリ(URL)より確認できます。 このドキュメントはまだW3C公式のドキュメントとはなってはいませんが、先月行われたFace-to-Faceのミーティングでも議論がされています(議事録) Feature Policy セキュリティやパフォーマンスの観点で、Webデベロッパーがブラウザの特定のAPI（機能）を無効にしたい場合もあります。 そこで、 Feature-Policyヘッダを用いて以下のようにブラウザの機能を制限できるようにするのがこの仕様です。 また、このFeature-Policyヘッダは現在IETFで議論が行われている"A JSON Encoding for HTTP Header Field Values"(URL)というHTTPヘッダ値にjso

Credential Management クレデンシャル管理機能と連携するためのAPI仕様「Credential Management」がW3Cで議論されています。 https://www.w3.org/TR/credential-management/ ブラウザは、Webサイトにログインするためのユーザ名・パスワードといった資格情報(クレデンシャル)を独自に管理しています。そしてログインフォームなどを検出すると自動入力等も行います。 Credential Managementでは、このブラウザが持つクレデンシャル管理機能とWebサイト側が連携する仕組みを提供し、ユーザがスムーズにログイン処理を行えるようになります。 JavaScriptからクレデンシャルをストアさせたり、とりだしてログイン処理を行ったりできるようになります。 例えば、まずはストアされているクレデンシャルを用いてログイン

新しい仕様の翻訳を公開しました(2018/10/31) QUICの仕様を翻訳していく http://d.hatena.ne.jp/ASnoKaze/20160725/1469374715 2018年追記 最新の状況、概要についてはこちら asnokaze.hatenablog.com QUICの仕様(ドラフト) 5月頃に、Googleのブログでも「Google の試験的トランスポート、QUIC のアップデート」という記事で紹介されたように、QUICというUDPを用いたプロトコルが注目を集めています。 幾つかのドキュメントは存在していたものの、仕様としては未公開でした。 しかし、6/17に2つのInternet-Draftが公開されました 「QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2」 「QUIC Loss Recov

HTTP2 draft11 4/3にHTTP2のdraft11が公開された。 ALTSVCフレームの追加や、"connection header"から"connection preface"への名称変更などが含まれている。 なかでもストリームのpriorityについて大きな変更が入った。 HTTP/2のpriority HTTP2ではクライアントからサーバにリソースを要求する際priority(優先度)を伝えることが出来る。 これは、一般的にWebサイトを表示する際、早くレスポンスが欲しいものとそうでないものがあるためである。 例えば、レンダリングを開始するのにCSSファイルは必要だが、画像ファイルは遅くてもかまわない。もしくは、アクティブでないタブの場合は優先度を下げるといった事も出来るかもしれない。 （もちろんサーバ側はクライアントからの優先度に従うことが必須ではない。） depend

宣伝 2015/11 追記 ソフトウェアデザイン 11月号に HTTP/2の特集記事を書かせていただきました。より詳しく書きましたので、本記事より参考になるかと思います。 http://www.amazon.co.jp/dp/B01494YKUI HTTP2は2014年4月のWG Last Callに向けて、仕様策定が進められている。 現在も、ロンドンで行われているIETFのミーティングでは熱い議論が行われているところであろう。 (local activityとして日本での活動なども紹介されているようです) HTTP2の仕様を決めているHTTPbisワーキンググループのchairであるMark Nottingham氏が、自身のブログにて「Nine Things to Expect from HTTP/2」という記事が投稿されている。 ここでは、HTTP2が何をもたらすか以下の観点で説明して

7月8日に5つめとなるHTTP2.0 draft 04が公開されました。 http://tools.ietf.org/html/draft-ietf-httpbis-http2-04 今までの非常にざっくりした流れはこのようになっています。 仕様の中でも触れられている通り、出すとしていたimplementation draftと呼ばれていてものになります。 この仕様に則って、8月5日に相互運用性テスト(Interoperability testing)が行われる予定です。また、合わせて8月の5〜7日にドイツのハンブルクでinterim meetingが行われ、HTTP2.0について議論される予定です。 draft 04における変更点ですが 6月13,14日に行われたinterim meetingの議論の結果が多く反映されているようです。 正直、全然追えてないのでメモ書き程度になります HT