逆向きに接続する Reverse HTTP Transport の仕様 - ASnoKaze blog
『Reverse HTTP Transport』という提案仕様がIETFに提出されています。著者はMetaとNokiaの方々らです。また、HAProxyの方も同様の機能を検討しているそうです(参考URL)。 普通のProxyサーバでは、Proxyサーバからオリジンサーバにコネクション確立するのが一般的です。そのためにオリジンサーバが外部から接続を受けられるようにする必要があります。 Reverse HTTP Transportでは、逆にオリジンサーバからProxyサーバにコネクションを確立し、HTTPリクエストを受け付けるという構成になります。コネクションの確立/TLSハンドシェイクだけが逆向きで、コネクション確立された接続上で、ProxyからHTTPリクエストが送られます。 これによりオリジンサーバをインターネットに公開する必要がなくなります。 プロトコルについて この Reverse
ブラウザからPCの負荷状況を取得する Compute Pressure API - ASnoKaze blog
PCの負荷状況に合わせて、Webサイトでの処理を軽量なものに切り替えたい場合があります。 それを可能にする仕組みである「Compute Pressure API 」がChromeで実装が進められています。なお、仕様の方もW3Cで「Compute Pressure Level 1」が公開されています 例 Compute Pressure APIを使うと、PCのCPU負荷が4段階で確認できます。 Nominal: 負荷が低い状態 Fair: システムは正常に動作しており、追加のワークロードを実行できる Serious: 負荷が高い状態。追加のワークロードを実行するとCriticalになりうる Critical: 負荷が限界に近い状態 詳しいCPU情報はプライバシーの観点から公開しない設計になっています。 実行例 Compute Pressure API は現在Chromeの開発版で動作確認でき
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
40年越しにTCPの仕様(RFC793)が改訂される RFC9293 - ASnoKaze blog
2022/08/09 追記 「RFC 9293 Transmission Control Protocol (TCP)」として正式なRFCが出ました TCPのコア部分の仕様は1981年に発行された「RFC793 TRANSMISSION CONTROL PROTOCOL」で標準化されています。 この、RFC793の改訂版となる「Transmission Control Protocol (TCP) Specification」は、2013年からIETFのTCPM WGで議論されてきましたが、4月4日にIESGによって承認されました(参考URL)。現在はRFC出版の準備に入っています(新しいRFC番号はこの後正式に決まります) www.ietf.org 改めてTCPの仕様を読みたい場合はこのドキュメントを読むのが良さそう。 概要 この改訂版の仕様(通称 rfc793bis)は、RFC793が
0.0.0.0/8のIPアドレスなどを利用可能にする提案仕様 - ASnoKaze blog
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のものを利
新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
時間順にソート可能なUUIDv6, UUIDv7, UUIDv8の提案仕様 - ASnoKaze blog
IETFに「New UUID Formats」という提案仕様が提出されています。 これは、時系列順にソート可能なUUID version 6, UUID version 7, UUID version 8を新しく定義するものです。 詳しい背景は提案仕様にゆずりますが、ULIDを始めとして、時系列順にソート可能な一意な識別子を利用したいというユースケースがあります。例えば、データベースのキーとして使えば、ソートせずとも順番に並びますし、書き込む際も順々に書き込めるのでデータアクセスが局所的になります。 今回は簡単に、それぞれのUUIDのフォーマットを眺めていきます。なお、フォーマットは異なりますが、バージョンを示す値は同じ位置にあります。 UUIDv6 UUIDv6は128bit長で、UUIDv1と似てるフォーマットを取ります。 1582年10月15日(グレゴリオ暦)からの100ナノ秒単位で
ZeroSSL ならIPアドレスのサーバ証明書が取得できる - ASnoKaze blog
IPアドレスのサーバ証明書が欲しい場合があります。そうすれば、ドメインを取得せずともサーバとHTTPS通信ができるようになります。 その他にも例えばDNS over HTTPSではIPアドレスでアクセス出来るように、有効な証明書がセットされていたりします。 https://1.1.1.1 https://8.8.8.8 しかし、Let's Encryptでは、IPアドレスのサーバ証明書は取得できません ~$ sudo certbot certonly --nginx -d 160.16.124.39 Requested name 160.16.124.39 is an IP address. The Let's Encrypt certificateauthority will not issue certificates for a bare IP address.ZeroSSLでは出来
Cookieの新しい属性、SameParty属性について - ASnoKaze blog
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
POSTリクエストを冪等処理可能にするIdempotency-Keyヘッダの提案仕様 - ASnoKaze blog
はじめに HTTPリクエストには冪等なものと非冪等なものがあります。 仕様上、GETやOPTIONSは冪等であり、同じリクエストであれば何度行っても問題ありません。そのため通信上エラーが起こっても自動的にリトライすることが出来ます。 一方で、POSTリクエストは冪等ではありません。同じリクエストでも複数回行うと、結果が変わってしまいます。投稿や課金APIであれば2重に処理されてしまいます。 POSTリクエスト中にタイムアウトが発生した時に、サーバに処理される前にタイムアウトしたのか、サーバが処理したあとにレスポンスを返そうとしたところでタイムアウトしたのかクライアントは区別できません。そのため、POSTリクエストを一概にリトライすることは出来ません。 そこで、リトライにより複数回同じPOSTリクエストを受け取っても、同じものと識別できるように識別子をHTTPリクエストに付加できるようにする
ブラウザからTCP, UDPソケットを操作するDirect Sockets API - ASnoKaze blog
2020/01/14: 実際に動くのを確認しました asnokaze.hatenablog.com (2020/09/17 注釈: Raw SocketsからDirect Socketsに名称が変更されました) ブラウザでTCP, DUPソケットを操作可能にする「Direct Sockets API」という仕様がW3CのWICGで議論されている。 また、blink-devでも「Intent to Prototype: Raw Sockets API」とプロトタイプの議論が行われている。 多くの方がセキュリティ上の懸念を抱くと思うが、ドキュメントでも慎重に検討すると書かれている。GithubでIssueを立てることも可能なので、思うことがある方は、まだまだ議論は始まったばかりでもあるので是非フィードバックされると良いと思う。(割と普通に聞いてもらえます) なお、Raw Socketsという名
新しいWebの双方向通信 "WebTransport" について - ASnoKaze blog
関連記事 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上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな
XSSを防ぐ新しいXSS-Protectionヘッダ - ASnoKaze blog
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という仕様が提案されて
WiresharkでHTTP/2をパケットキャプチャする - ASnoKaze blog
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周りの素晴らしい記事が投稿されてし
HTTP2でWebがどうなるか9つのこと(自分用ﾒﾓ - ASnoKaze blog
宣伝 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が何をもたらすか以下の観点で説明して
Webを支えるプロトコル - ASnoKaze blog
若者のプロトコル離れが叫ばれて久しいが、最近プロトコルは非常にホットな分野である。 目まぐるしく進化するWebに合わせ、プロトコルの世界も着実に進化している。 今までブラウザでは出来なかった事が出来るようになり、Webサービスをより安全に使えるようになった。 そしてWebのパフォーマンスを大きく改善するためにHTTP2.0も議論されている。 Webを支えるプロトコルとして、大きく分けて３つに分けられるかと思う（私の勝手なイメージ、正確な図ではありません） Webアプリケーション ブラウザが今まで出来なかったことを出来るようにしたり、Webアプリケーションの認証・認可などの機能を提供するプロトコルなど。JSやサーバサイドプログラミングで利用したりする。 WebSocket (http://tools.ietf.org/html/rfc6455) ブラウザとWebサーバの間でソケット通信を行う
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
