リクエストに対してx-cacheレスポンスヘッダでキャッシュにhitしたか示すCDNベンダーもあります。 しかし、このx-cacheヘッダは各ベンダー独自のもので標準化されていませんでした。 そこでCache-Statusというヘッダをちゃんと定義する「The Cache-Status HTTP Response Header」という仕様がFastlyのMark Nottingham氏から出ています。 以前まではcacheヘッダという名前でしたが、draft 01ではCache-Statusヘッダと改称されました。それにあわせてヘッダ値もリファクタされています。 前の仕様は以前書いた通りです。 asnokaze.hatenablog.com Cache-Statusヘッダ Cache-Statusは以下のようになります。「Structured Headers for HTTP」の定義に従っ

Fastlyの「Binary Structured HTTP Headers」という提案仕様がでています。 目次 概要 BINHEADERSフレーム Binary Literal Representation Lists Dictionaries Items String Literals Item Payload Types Aliased Fields 概要 HTTPヘッダはテキストで表現されます。特に値に関して数値、日付やブーリアン値もテキストで表現されます。また、Accept-Encodingのようにリスト構造を持つヘッダ値もあります。 本来バイナリで表現できるデータ形式や構造をテキストで表現するのは、データ量が増えるほかパースコストがかかります。 そこで、Structured Headersの定義に基づいて、HTTPヘッダ値を直接バイナリで表現できるようにするのが「Binary

2020/060/01 追記 nginx公式版が提供されました。こちらを御覧ください asnokaze.hatenablog.com NginxをHTTP/3対応させるパッチがCloudflareから提供されました (CloudflareのHTTP/3ライブラリ Quicheを利用しています。現状ではHTTP/3ドラフト23版の対応になります) github.com 基本的に、書いてるとおりにやればビルドできるのですが、無事HTTP/3しゃべるところまで確認できました ビルド rustインストールしておく $ curl https://sh.rustup.rs -sSf | sh $ source $HOME/.cargo/env書いてあるとおり $ curl -O https://nginx.org/download/nginx-1.16.1.tar.gz $ tar xzvf ngin

2020/07/19 追記 仕様に幾つかの変更があったため、新しく記事を書き直しました asnokaze.hatenablog.com HTTPSで接続する際に以下の情報を持っていると都合がよいです SNIを暗号化するESNIの鍵情報など情報、(通常ESNI DNSレコードに記述される) HTTP/2やHTTP/3で通信可能な事を示すAlt-Svc (通常、HTTPレスポンスヘッダやAlt-Svcフレーム、Alt-Svcレコードで提供される) それらの情報を通知するのに、DNSに新しくHTTPSSVCレコードを追加する「HTTPSSVC service location and parameter specification via the DNS」という提案仕様がGoogleとAkamaiの方の共著で提出されています。 また、このHTTPSSVCレコードではドメインのApexでも使用でき

関連記事 WebTransport over QUICのサンプルサーバを試してみる - ASnoKaze blog WebTransport over HTTP/2 の仕様について - ASnoKaze blog WebTransport over QUIC について - ASnoKaze blog WebTransportという新しい双方向通信フレームワークの議論が始まっている。 GoogleのPeter Thatcher氏らによって、W3C WICGにプロポーザルが投げられています。 discourse.wicg.io WebTransportは、WebSocketのようなAPIをもち、QUICやHTTP/3上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな

QUIC, HTTP/3 関連記事 QUICのAckとロスリカバリについて - ASnoKaze blog HTTP/3のヘッダ圧縮仕様QPACKについて - ASnoKaze blog WiresharkでのQUICの復号(decrypt) - ASnoKaze blog QUIC,HTTP/3 の draft-17に関するメモ - ASnoKaze blog HTTP over QUICと、その名称について (HTTP3について) *2019年9月更新 - ASnoKaze blog QUICの話 (QUICプロトコルの簡単なまとめ) - ASnoKaze blog HTTP/3というかQUICの通信がどのように暗号化されているのか勉強がてら軽くまとめる。(執筆時点でQUIC-TLS Draft 19) QUICでは、通信の多くが暗号化されています。アプリケーションデータはもちろんのこ

この記事では、HTTP/3で導入されるHTTPヘッダ圧縮の仕組みである「QPACK 」について説明します。（執筆時 draft 07） 2020/06/01追記 まるっと解説記事を書き直しました asnokaze.hatenablog.com HTTP/2の場合 ハフマン符号 静的テーブル、動的テーブル HTTP/3とQPACKの導入背景 QPACKの概要 Encoder Instructions Decoder Instructions Header Block Instructions 相対インデックス Compressed Headers エラーハンドリング その他 QPACKという名称について HTTP/2の場合 簡単に、HTTP/2で導入されたヘッダ圧縮の仕組みである「RFC7541 HPACK」について補足します。飛ばしていただいても大丈夫です。 HTTP/2の元となったSPD

QUICを使用している際に、その通信がNATによってアドレス変換を行われているかを検出する「QUIC Address Extension」という提案仕様がAppleの人らによって出されています。 具体的には、送信元IPアドレスがなんであるかを通信相手に確認します。そうすることで、途中でIPアドレスが変換されているかを確認することが出来ます。 NATがいなければ、NATリバインディングを避けるためにPINGフレームを送る必要もありません。一方で、NATを検出した場合はコネクションIDとポートを定期的に変えることがよりプライバシーを高めることになります。 概要 自身のIPでアドレスが相手にどのように見えているか確認する、「PUBLIC_ADDRESS_REQUESTフレーム」と「PUBLIC_ADDRESS_RESPONSE フレーム」を定義します。 PUBLIC_ADDRESS_REQUES

HTTP/2コネクション上で任意のバイトストリームをやりとりできるようにする「Using HTTP/2 as a Transport for Arbitrary Bytestreams」という仕様がAppleの人らによって提案されている。 IETF103でも議論(資料)になったが、その後 draft-01 が出ているのが現状である。 ユースケースとしては任意のバイトストリームをトンネリングしたり、一つのコネクション上で複数のバイトストリームをやり取りするのにストリームを利用するといった背景があるようだ。 通信の流れ 以前解説したWebsocket over HTTP/2と同じように、HTTP/2コネクションを確立したあとにストリーム上でConnectメソッドを用いる。 asnokaze.hatenablog.com 大まかな流れは以下の通り SETTINGSフレームでお互いにこの仕様に対応

目次 Secondary Certificate Authentication in HTTP/2 用途 サーバ側から証明書を要求するパターン クライアント側から証明書を要求するパターン 通信フロー サーバ側から証明書を要求する場合 クライアント側から証明書を要求する場合 Secondary Certificate Authentication in HTTP/2 HTTP/2コネクションを確立したあとに、サーバまたはクライアントから追加の証明書を要求・提供できるようにする「Secondary Certificate Authentication in HTTP/2」という仕様が議論されています。(secondary-certsとも呼ばれています) 仕様自体はすでにwg draftとなっています。 数年前にこのブログでも紹介しましたが、デザイン変更もあるため再度簡単に読み直します。 用途