新しいHTTPメソッド、QUERYメソッドの仕様 - ASnoKaze blog
新しいHTTPメソッドを定義する「The HTTP QUERY Method」という提案仕様が議論されています。 もともとは、SEARCHメソッドという呼び名が候補としてあげられていましたが、長い議論ののち、一旦QUERYと呼ぶ方向となっております。最終的なFixについては、この draft 02の公開とともに改めてコンセンサスを求めた後に行われます。 QUERYメソッド 「GETリクエストにボディを付けたいという」という質問は長らく有りました。しかし、GETやHEADリクエストでボディをつけることは非推奨となっています (参考URL)。 そのような要望のなかで、リクエストでボディを含められる冪等性の保証された新しいHTTPメソッドが検討されました。それがQUERYメソッドです。冪等性があるため、ブラウザやProxyは自動でリトライすることができます。(なお、POSTはセマンティクス上冪等
一般ユーザに払い出すと危険なサブドメインやメールアドレス - ASnoKaze blog
ユーザに対して、そのユーザ名のサブドメインやメールアドレスを払い出すWebサービスがあります。 しかし、特定のサブドメインやメールアドレスは特別な用途で使われているものもあります。そのようなサブドメインやメールアドレスを一般ユーザに払い出してしまうと危険です。 現在、IETFでは仕様上利用用途が決められている、それらのラベルをとりまとめる「Dangerous Labels in DNS and E-mail」というdraftが提出されています。 今回はそれを眺めていきます。 （あくまでIETFの取り組みであり、仕様上定義されているものをとりまとめています。クラウドサービスや特定ベンダーで特別利用しているものは現在含まれていません。） サブドメイン ここでとりあげるサブドメインは、利用用途が決まってるため一般ユーザに払い出すべきではありません。(例: mta-sts.example.com)
Webサイトのバグの報告先を示す contributing.txt - ASnoKaze blog
Webサイトのバグを見つけたとしても、その報告先を知る統一的な方法は現状ありません。 たとえば、脆弱性についてはsecurity.txt があります。https://www.facebook.com/security.txt などで使われています。 asnokaze.hatenablog.com 同様の仕組みで、contributing.txt という形式でバグの報告先を示せるようにする仕組みが提案されています。提案仕様は「a simple way to provide informations for contributors」としてIETFに提出されています。 例 contributing.txtをWebページの最上位階層に配置します (例: https://example.com/contributing.txt ) そのファイルは次の情報を含めることが出来ます。 Admin: Va
新しい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上で多重化されたストリームを利用し、ヘッドオブラインブロックのない通信を行えるようにするというのがモチベーションのようです。（実際に使用する"トランスポート"はプラガブルな設計にな
W3CにおけるWeb Lifecycleの議論 (Page Lifecycle API) - ASnoKaze blog
20180523 追記 Page Lifecycle API等とも呼ばれているようです。 github.com 下記内容は古く一部ことなっています W3CでWebPerf Web Performanceで、「Web Lifecycle」というトピックが議論に上っていた。(Agenda URL) これは、iOSアプリやAndroidアプリのActivityのようなライフサイクルを、Webアプリケーションでも定義しようというものらしい。 まだ具体的な仕様は無いものの面白そうなので簡単に見てみる。ちょうざっくり 背景 30%以上のユーザがタブを10以上開いており、現在表示しているタブのユーザ体験に影響を与えている バックグラウンド(非表示のタブなど)の扱いについて明確なライフサイクルは存在しない(デスクトップとモバイルで扱いが異なる) ライフサイクルやAPIがなく、アプリケーションが自身がどうい
GoogleのQUICの論文が知見の塊だった - ASnoKaze blog
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だと推定されるという説明から論文は始まる。
Webページを丸ごとパッケージングする Web Packagingとは - ASnoKaze blog
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
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
