キャッシュのキーとしてURLが使われます。このときURLのクエリパラメータも含めて考慮されます。 特定のクエリパラメータは、分析や別様とでアクセスログに残すために使われたりしますが、提供するリソースが変わらない場合があります。そのケースであれば、クエリパラメータが付いてたとしても、キャッシュがあればキャッシュを使ってもらいたいものです (ここでキャッシュは、HTTPキャッシュ及び、prefetchやprerenderを指します)。 そのため、クエリパラメータが付いている場合の扱いを改善する No-Vary-Search レスポンスヘッダ が、Chromeの方中心に議論されています。 github.com 例 No-Vary-Search レスポンスヘッダの例として次のものが上げられている クエリパラメータのキーの順序を考慮しない No-Vary-Search: key-order特定のクエ

(追記: 2023/06/01 RFC 9369になりました) 「QUIC Version 2」という仕様が提案されています。これは、「RFC 9000」で標準化されたQUIC v1と機能上はまったく同じものです。 この提案仕様の目的は、主にふたつあります。 硬直化(ossification)の問題を緩和し将来のQUICバージョンをインターネットでデプロイしやすくする バージョンネゴシエーションを実行できるようにする 11月に実施されたIETF 112の後に、QUIC WGのメーリングリストで、この仕様にWGとして取り組んでいくコンセンサスが得られました。現在はWG Draftとなっています。 なお、Version 2はまだ2番目のバージョンということで便宜上そう呼んでいるようです。バージョン番号の正式なアサインは後に行われます。 硬直化(ossification)の問題の緩和 硬直化とは

IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利

TCP/QUICのポートフォワードツールを書いた。 概要 IETFで標準化が進められているトランスポートプロトコルQUIC。 UDPを利用しており、エンドポイントのIPアドレスが変わってもコネクションが切れなかったり、より良い再送制御が行えたりと長所は多くある。しかし、QUICをサポートしているアプリケーションプロトコル、実装が現状多くはない。 QUICの恩恵に預かるために、TCPとQUICを相互変換するポートフォワードツール 「t2q2t」 を書いた。(実態としてはただのProxy) github.com ただし、ハンドシェイク回数が増えるのでコネクション確立時のオーバーヘッドは高い 利用例 ユースケースとしては例えば: クライアントとサーバそれぞれでt2q2tを実行する。 クライアント: TCPで0.0.0.0:2022でリッスンし、QUICで192.168.0.1:22に転送する サ

[追記] 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

[追記] 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

20181107追記 QUICプロトコルについての概要は別途記事を書きました asnokaze.hatenablog.com 概要 ACM SIGCOMM 2017という通信系の学会に、Googleの人 総勢21人によって書かれた「The QUIC Transport Protocol: Design and Internet-Scale Deployment」という論文が提出され、学会ホームページより閲覧出来る。 この論文は、QUICの設計仕様と実際にGoogleのサービスにデプロイした結果について書かれている。 すでにGoogler SearchやYoutubeでQUICは有効になっており、一日あたり数十億の接続を処理し、Googleのegress trafficのうち30%がQUICになっており、インターネットのトラフィックの内7%がQUICだと推定されるという説明から論文は始まる。

[20170809追記] nginx-1.13.4に ngx_http_mirror_module は含まれました Nginxで、リクエストを複製するmirrorモジュールがコミットされ、何もせずとも使用できるようになりそうです(現状最新コミットをビルドする必要あり)。 例えば本番環境のproxyからリクエストを複製して開発環境に流すような事も出来ます。もちろん複製処理は本来のリクエスト処理をブロックしません。 例えば以下のように、mirrorに来たリクエストを複製してバックエンドサーバに投げるようにしてみます conf server { listen 80 ; server_name localhost; mirror_request_body on; log_subrequest on; location /mirror { mirror /proxy; #/proxy宛にリクエストを

2020/04/28 追記 仕様の名前が少々変わりましたが、WG Draftとなり作業は引き続き続けられています。 「Specification of DNS over Dedicated QUIC Connections」 QUICの標準化とアプリケーションレイヤ IETFでQUICの標準化が活発に行われており、トランスポート・TLS・HTTP各レイヤのドラフト仕様の改定が進められております。 標準化を行うにあたって当初より、DNSのトランスポートとしてQUICを使用したいという話題は出ていましたが、QUICワーキンググループのチャーターでは、まずはQUICのアプリケーションレイヤとしてHTTPの標準化を行ってから他のアプリケーションプロトコルについて進める旨書かれている。 とはいえDNS over QUICをやりたい人はいるようで、4/11にインターネットドラフトが出されている。共著者

evalとreportOnlyについて追記しました (2016/10/10) 2016/10/20 仕様名は以下の通りになりました。Anti-XSS Response-Time Uniqueness Requirement また、ヘッダ名は、XSS-Protectionヘッダではなく、ARTURヘッダとなっておりますが、また変更される可能性があります。 Googleの調査によると、CSPによるXSSの防止は現実的にデプロイの欠陥によりXSSの防止効果がないことを示しています。調査は「CSP Is Dead, Long Live CSP!」としてACMのカンファレンスで発表され、ペーパーも閲覧することができます。 9月に行われたW3C TPAC 2016のWebAppSecのミーティングで議論され、GoogleのMike West氏より新しくXSS Protectionという仕様が提案されて

Webセキュリティを考える上で大事な仕組みの一つに、Same-Origin Policyという仕組みがあります。 Originは「スキーム・ホスト・ポート」の組み合わせです。これらが一緒であれば、同一Originでありリソースへアクセスすることができます。 歴史的経緯や様々な理由により複数のアプリケーションが同一Originで提供されている場合があります。 たとえば、"チャット"や"ショッピング"の機能が以下の様なURLで提供されているような場合です。 https://example.com/chat/ https://example.com/shopping/ 実際、Googleの検索サービスと地図サービスは同一Originで提供されています。昔からあるリンクや、パフォーマンス、ブランディングのためのようです。 https://www.google.com https://www.goo

準備 virtualboxとvagrantがインストールされてない場合は、公式サイトからダウンロードします。 https://www.virtualbox.org/wiki/Downloads http://www.vagrantup.com/downloads.html VMの起動 GitHubから落としてきます $ git clone https://github.com/flano-yuki/nghttp2-vagrantfile $ cd ./nghttp2-vagrantfile プラグインをインストールして、vmを起動します $ vagrant plugin install vagrant-omnibus $ vagrant upboxのダウンロードに数分、Chefのダウンロードに数分、各種インストールとビルドに20分程度かかります... nghttp2 vagrant ssh