ブラウザから直接TCP・UDPで送受信する「Direct Sockets API」という仕組みが議論されています。 実験段階ですが、Chromeでは起動時にオプションを付けることでこの機能を有効にできます。今回はTCPの方で簡単に動作を見てみます。 Direct Sockets API Direct Sockets APIは、TCP・UDPで直接送受信可能にするAPIです。既存のアプリケーションプロトコル(SSHやIRC)、P2Pのような機能を実現可能になります。 もちろんセキュリティ上の問題もあるので、Chromeでは現状デフォルトでは有効になっていない機能です。 セキュリティ面についてはだいぶGithubリポジトリで議論されておりますので目を通すと良いでしょう。ローカルネットワークへの通信やSame-Origin-Policy(CORS)回避の話が上がっていますが、今回は細かくは紹介し

ChromeでCookieのSameParty属性の開発が進められている (コミット)。 現在のところ「SameParty cookie attribute explainer」に説明が書かれている。 今回は、CookieのSameParty属性について簡単にメモしていく。 背景 トラッキング対策、プライバシーの観点でサードパーティクッキーは制限する方向に進んでいる。その制限をSame Partyの場合に緩和する仕組みを提供するのがSameParty属性の話である。 例えば、同一主体により運営されているドメインの異なるサイト (例えば、google.co.jp, google.co.uk) 間においては、いわゆる(cross-site contextsで送られる)サードパーティクッキーを許可しようという話です。 もともとは、First-Party Setsを活用しSameSite属性にFi

@flano_yukiがHTTP/3について書きました。(無料です。 2020年6月時点の内容となっています。概ねQUICやHTTP/3の大枠は固まっており、2021年の内容と照らし合わせても、大きな変更はありません。PDFを下に貼ってあります。 , (宣伝) また、2021年6月にアップデートも含め、WEB+DB PRESS Vol.123に記事を書かせていただいております（有料） gihyo.jp http3-note https://github.com/flano-yuki/http3-note にPDFを置きました 1. はじめに(HTTP/3と概要) 2. QUICについて 3. HTTP/3について 4. HTTP/3 拡張仕様と応用 5. (執筆予定) 実装、ツール紹介 公開形式は、そのうちなんとかするかも 内容 1. はじめに(HTTP/3と概要) 1.1 はじめのはじめ

なんらかの理由でWebサーバを停止する場合に、処理中のPOSTリクエストをそのまま別のサーバで引き継げるようにする「HTTP Partial POST Replay」という仕様がFacebookのAlan Frindell氏から提出されています (HTTP Workshopの資料はこちら)。 スポットインスタンスを利用していたり、サーバの設定を変えて再起動したい場合、新しいリクエストは受け付けないようにし、すでに来ているリクエストのみ処理をするのは一般的です。それでも大きなファイルをアップロードしているPOSTリクエストは処理が終わるまで時間がかかってしまう場合がありあります。 やむをえずPOSTリクエストの処理を中断してしまうと、ユーザは再度大きなファイルをアップロードしなおす必要があり、とてもストレスがかかります。 「HTTP Partial POST Replay」では、ユーザの接続

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だと推定されるという説明から論文は始まる。

20180824追記 Loading Signed Exchangesについて記事を書きました Loading Signed Exchangesの仕様 (WebPackaging) - ASnoKaze blog 20180208追記 Bundled HTTP Exchangesについて記事を書きました Bundled HTTP Exchanges とは (WebPackagingの議論より) - ASnoKaze blog 20180121追記 署名の仕組みとして Origin-Signed HTTP Exchanges を利用する方向のようです HTTP/2 クロスオリジン サーバプッシュを可能にする提案仕様 - ASnoKaze blog 20171001追記 IETF99にてユースケースについてまずまとめるべき気というフィードバックが有り、それをうけて「Use Cases and

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という仕様が提案されて

「Moving towards a more secure web」でアナウンスされているように、2017年1月にリリースされる予定のChrome 56でHTTPサイトへの警告が表示されるようになる。 日本語のサイトでも取り上げられている Google、2017年からChromeでいくつかのHTTPサイトを「安全ではない」と警告 日本語版表示 Chrome Canaryで、chrome://flagsより 下記設定を有効にすることで、日本語版の警告表示が確認できる。 "保護されていない発行元に「保護されていない発行元」のマークを付ける" http://asnokaze.com https://asnokaze.com 日本語だと、また印象が変わる。HTTPS対応できてないサイトへの影響は結構ありそうである。

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

既に記法が変わっています。サンプルコードはそのままでは使用できません。リポジトリ内のテストコードを参考にしてください (2016/04/04) 20161210 「varnishtestのHTTP/2対応 アップデート」にて、更新項目について書きました Varnish-CacheのvarnishtestがHTTP2に対応した(まだWIP状態であり、正式ではない。) varnishtestと言う名前だが、Varnishのテスト以外にも十分使えると思う。 イメージしやすいように先に簡単なサンプルを載せる。 サンプル テストコードはvtcと呼ばれるコードで記述する。 h2client c1 -connect localhost:8080 { stream 1 { txreq -req GET -url / -hdr :scheme http -hdr :authority localhost r

NginxのTCP Load Balancing(ngx_stream_core_module) もともとNginx+で利用できたTCP Load Balancing機能というものがある http://nginx.com/products/application-load-balancing/ HTTPにかぎらずTCPレイヤでロードバランシグ機能を提供する。つまりMySQLやMemcachedのロードバランサとしても使用することができるようになる。 OSS版でも使用できるようになったらしいhttp://hg.nginx.org/nginx/rev/61d7ae76647d 試しにMemcachedのロードバランサを構築してみた(環境はubuntu14.04) nginxビルド ざっと適当にインストール sudo apt-get install libpcre3 libpcre3-dev b

20190417追記 HTTP/3はこちら「WiresharkでのQUICの復号(decrypt) - ASnoKaze blog」 20151030追記 TLSを利用するHTTP/2では、秘密鍵を設定しても通信を復号することは出来ません。 HTTP/2の鍵交換はPFSなので、下記も参考にして下さい 「Wireshark で HTTP/2 over TLS の通信をダンプする方法」 https://gist.github.com/summerwind/a482dd1f8e9887d26199 この記事は HTTP2 Advent Calendar の 9 日目の投稿です。 初めましてゆきと申します。HTTP/2アドベントカレンダーにはガチ勢しかおらず戦々恐々としております。 アドベントカレンダーネタとしては、Push周りを書こうとしてたのですが先日Push周りの素晴らしい記事が投稿されてし