あまり知られていないがCookieにはPriority属性がある。 Chromeでは2013年に実装が入っている(該当コミット)、また提案仕様「A Retention Priority Attribute for HTTP Cookies」も2016年に提出されているが標準化には至ってない。 ここらへんの議論は当時の"メーリングリスト"を参照してください。 そんなPriority属性は、長年動きが無かったが、最近ChromeがデベロッパーツールでPriority属性を表示するようになった( Chrome Canary 81)。 (JavaScriptからPriority属性を指定して、Cookieを設定した例) 超簡単にだが仕様を紹介する。 Priority Attribute CookieのPriorityは保持優先度です。ブラウザが保存容量(ドメイン毎)の都合でCookieを消す場合は

20190905 追記 Draft版の仕様が出てきたので「Mixed Content Level 2の仕様について - ASnoKaze blog」を書きました。 20181010 追記 Chromeが行っている取り組みについて、「Auto Upgrade Mixed Contentとは - ASnoKaze blog」を書きました。 W3CのWeb Application Security WGのco-chairとなった GoogleのMike West氏から、11月に実施されるTPAC 2017に先立って「Mixed Content Level 2」という提案が出されている。 Mixed Content https://のURLで、http://のリソースを読み込むと警告・もしくはブロックを行うMixed Contentという仕様がある。そのMixed Contentの問題とそれを改善

20180523 追記 Page Lifecycle API等とも呼ばれているようです。 github.com 下記内容は古く一部ことなっています W3CでWebPerf Web Performanceで、「Web Lifecycle」というトピックが議論に上っていた。(Agenda URL) これは、iOSアプリやAndroidアプリのActivityのようなライフサイクルを、Webアプリケーションでも定義しようというものらしい。 まだ具体的な仕様は無いものの面白そうなので簡単に見てみる。ちょうざっくり 背景 30%以上のユーザがタブを10以上開いており、現在表示しているタブのユーザ体験に影響を与えている バックグラウンド(非表示のタブなど)の扱いについて明確なライフサイクルは存在しない(デスクトップとモバイルで扱いが異なる) ライフサイクルやAPIがなく、アプリケーションが自身がどうい

RFCやInternet-Draftを読んだことある人であれば、文中にMUSTやSHOULDといった大文字のキーワードが用いられてるのを見たことあるかと思います。 たとえば、このように An endpoint MUST treat this as a stream error (Section 5.4.2) of type PROTOCOL_ERROR. これらのキーワードはプロトコルの仕様の曖昧性を無くすために 「RFC 2119 Key words for use in RFCs to Indicate Requirement Levels」で定義されています。 しかし、微妙な曖昧性があるためRFC 8174で更新されました。 RFC8174 Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words 「MUST」「SHOULD」