RFC の URL はどのドメインで貼るのが良いか | blog.jxck.io
Intro IETF の RFC は、いくつかの場所で同じものが公開されている。 どの URL が最適なのか、という話。 結論は www.rfc-editor.org だ。 RFC Hosting Site 例えば RFC 9110 - HTTP Semantics で言うと、以下の 4 つがある。 https://tools.ietf.org/html/rfc9110 https://datatracker.ietf.org/doc/html/rfc9110 https://www.rfc-editor.org/rfc/rfc9110.html https://httpwg.org/specs/rfc9110.html まずは、これらの違いを簡単に解説する。 tools.ietf.org IETF がホストする RFC は、 tools.ietf.org だった。 RFC 2616: H
ブラウザでリロードしながらキャッシュの挙動を確認してる全ての開発者へ | blog.jxck.io
Intro こういうタイトルを付けるのはあまり好きではないが、あえてこのようにした。 「ブラウザでキャッシュがヒットしない」 以下は、 Web における Caching の FAQ だ。 サーバで Cache-Control を付与したのにキャッシュがヒットしない サーバで ETag を付与したのに If-None-Match が送られない サーバで Last-Modified-Since を付与したのに If-Modified-Since が送られない 先日も、筆者が書いた MDN の Cache セクションで「記述が間違っているのでは?」と同様の質問を受けた。 Issue about the Age response header and the term "Reload" · Issue #29294 · mdn/content https://github.com/mdn/cont
HTTP 関連 RFC が大量に出た話と 3 行まとめ | blog.jxck.io
Intro 2022/06/06 ~ 9 あたりに、長きに渡って策定作業が行われていた HTTP 関連の RFC が大量に公開された。 RFC 9110: HTTP Semantics RFC 9111: HTTP Caching RFC 9112: HTTP/1.1 RFC 9113: HTTP/2 RFC 9114: HTTP/3 RFC 9163: Expect-CT Extension for HTTP RFC 9204: QPACK: Field Compression for HTTP/3 RFC 9205: Building Protocols with HTTP RFC 9209: The Proxy-Status HTTP Response Header Field RFC 9211: The Cache-Status HTTP Response Header Field
mouseover 中に表示される DOM のデバッグ | blog.jxck.io
Update 2024-03-30: Chrome 123 から "Emulate a focused page" が追加された。 これを用いれば良いため、以降の全ての方式は古くなった。 Apply other effects: enable automatic dark theme, emulate focus, and more https://developer.chrome.com/docs/devtools/rendering/apply-effects#emulate_a_focused_page マウスが乗ってないと出ない UI も、そこに Tab などでフォーカスを移し、その状態で Dev Tools の "Emulate a focused page" を有効にすれば良い。 Intro 先日、後輩が「mouseover 中にしか表示されない DOM のデバッグ」に手こずっ
本サイトの AMP 提供の停止とここまでの振り返り | blog.jxck.io
Intro 前回の記事で、奇遇にも本サイトの AMP 対応を落とすことになった。しかし、そうでなくても AMP をどこかでやめることは考えていたため、きっかけの一つが SXG 対応になったのは、順当な流れだと筆者は感じている。 これは AMP がなぜ始まり、なぜトーンダウンしつつあるのか、そしてこれからどうなっていくのか、という流れをまとめるいい機会でもある。 その過程で生み出され、本サイトでも検証を続けてきた Performance Timing API, Core Web Vitals, Signed HTTP Exchange 、そして今構想されている Bento AMP などを踏まえ、一連の流れを覚えている範囲で記録としてまとめておく。 ソースは筆者の主観であり、眺めてきた体感を mozaic.fm の Monthly Web などで話してきたものがベースなので、信頼性や正確性は期
Non AMP SXG による Prefetch 対応と AMP 提供の停止 | blog.jxck.io
Intro 本サイトを (Non AMP) SXG に対応した。 これにより、 Google のモバイル検索では、結果を表示した時点でこのサイトの SXG が Prefetch され、結果を選択したら Cache から素早く表示されつつ、 アドレスバーにも本サイトのものとして表示される。 この、 Non AMP SXG 対応にあたって、本サイトの AMP の提供も停止することになった。 移行の作業ログと、関連する流れについて記す。 (Non AMP) SXG SXG については過去に解説した。 WebPackaging の Signed HTTP Exchanges 本サイトでは AMP SXG に対応しており、 Google Search からの AMP ページへの遷移には SXG が取得され、本サイトのドメインが表示される。 AMP SXG 対応 今年の 4 月に、 AMP だけでなく
Public Suffix List の用途と今起こっている問題について | blog.jxck.io
Intro Public Suffix List (PSL) は、現在の Web プラットフォームの一端を支えている非常に重要な要素だ。 実はこれが、少数のボランティアにより GitHub でメンテナンスされた、単なるテキストリストであることは、あまり知られていないかもしれない。 最近、このリストへの追加リクエストがあとを絶たず、問題になっている。 そもそも PSL とは何であり、今どのような問題が起こっているのかについて解説する。 Public Suffix List とは何か PSL を解説するには、まず関連する用語について整理する。 Top Level Domain (TLD) 例えば、このブログのドメインは blog.jxck.io であり、これは筆者が取得したドメイン jxck.io のサブドメインだ。 jxck.io は、 .io という TLD のサブドメインを販売しているレ
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Scroll to Text Fragment を用いたサイト内検索の実装 | blog.jxck.io
Intro Scroll to Text Fragment のユースケースとして、本サイトにサイト内検索を実装した。 Scroll to Text Fragment Scroll to Text Fragment(以下 S2TF) は Chrome 80 で Ship され、 Finch で展開されている。 まだ降りてきてない場合は、 Flag による有効化が必要だ。 詳細は以前このブログでも書いている。 Scroll To Text Fragment と :~:text | blog.jxck.io この機能の使い道の一つとして、検索結果の Deep Link への適用があると考え、 PoC として実装した。 検索結果への適用 このサイトを CSP というキーワードで検索した場合を考える。 検索対象は、記事の本文とすると、例えば以下の一文がヒットする。 Feature Policy のモ
牧歌的 Cookie の終焉 | blog.jxck.io
Intro Cookie は、ブラウザに一度保存すれば、次からその値を自動的に送ってくるという、非常に都合の良い仕様から始まった。 State Less が基本だった Web にセッションの概念をもたらし、今ではこれが無ければ実現できないユースケースの方が多い。 冷静に考えればふざけてるとして思えないヘッダ名からもわかるように、当初はこのヘッダがこんなに重宝され、 Web のあり方を変えるかもしれないくらい重要な議論を巻き起こすことになるとは、最初の実装者も思ってなかっただろう。 そんな Cookie が今どう使われ、 3rd Party Cookie (3rdPC) の何が問題になっているのかを踏まえ、これからどうなっていくのかについて考える。 Cookie のユースケース Web にある API の中でも Cookie はいくつかの点で特異な挙動をする 一度保存すれば、次から自動で送る
Promise.allSettled と Promise.any | blog.jxck.io
Intro Promise.allSettled() と Promise.any() の仕様策定が進んでいる。 両者は近いレイヤの仕様では有るが、作業の進捗には差がある。 Promise.allSettled は Stage 4 であり、 Chrome や Safari TP には実装もされている Promise.any は Stage 2 であり、実装はまだない ここでは、これらがあると何が嬉しいのかを Promise.all(), Promise.race() の特徴を踏まえて解説する。 Promise.all()/race() Promise.all(), Promise.race() は、いずれも複数の Promise をまとめて処理する Utility Method のようなものである。 all は全ての Promise が Resolve したら Resolve し、 race
Private Class Field の導入に伴う JS の構文拡張 | blog.jxck.io
Intro ECMAScript の Private Class Field の仕様策定と各ブラウザの実装が進んでいる。 これにより、従来の JS にはなかった Class の Private フィールドが使えるようになる。 提案されている構文や、挙動について解説する。 Class Field Declaration まず前提として、現状の Class の フィールドはコンストラクタで定義する必要がある。 例えば count フィールドを持つ Counter クラスを定義した場合、以下のようになる。 class Counter { constructor() { this.count = 0 } increment() { this.count ++ } display() { console.log(this.count) } } const c = new Counter() c.in
安全な文字列であると型で検証する Trusted Types について | blog.jxck.io
Intro 脆弱性の原因となる DOM 操作の代表例として elem.innerHTML や location.href などが既に知られている。 こうした操作対象(sink) に対して、文字列ベースの代入処理を行う際に、一律して検証をかけることができれば、脆弱性の発見や防止に役立つだろう。 そこで処理前の文字列に対し、処理後の文字列を安全であるとして明示的に型付ける TrustedTypes という提案がされている。 まだ未解決の部分が多い提案だが、現時点での仕様と実装を元に、このアイデアについて解説する。 WICG/trusted-types Intent to Experiment: Trusted Types Sink XSS などの原因となる DOM 操作として、 DOM に直接文字列を展開する処理がある。 element.innerHTML location.href scri
HTTP の新しいステータスコード 103 Early Hints | blog.jxck.io
Intro これは、 http2 Advent Calendar 2016 の 16 日目の記事である。 HTTP に新しいステータスコード 103 Early Hints が追加されようとしている。 HTTP/1.1 および HTTP2 双方と関わり、リソース配信の最適化に利用することができる。 いったい何のために必要なのか、どういうメリットが考えられるかを解説する。 HTTP2 Push の復習 まず HTTP2 の Push について復習する。 H2 Push は、簡単に言えば PUSH_PROMISE フレームを用いて、レスポンスよりも先に依存するリソースを返すための仕様である。 例えば /users のレスポンスは script.js と style.css をサブリソースとして含んでいるとする。 HTTP2 では SQL を発行して Users の一覧を取得している間に、先行し
Node v7 で入った WHATWG URL 実装について | blog.jxck.io
Intro Node v7.0.0 が公開され、今回のリリースで WHATWG URL の実装が Experimental として入った。 既に標準で含まれていた url module との違いや、 URL API などについて解説する。 WHATWG URL URL は非常によく使われる、 Web において重要なフォーマットの一つだ。 ものによっては一見シンプルに見えるかもしれないが、その仕様はそれなりに大きい。 しかし、これまで DOM/JS はこれをパースする専用の API を持っていなかったため、例えば <input type=text> に入力された URL 文字列のパースは、片手間な正規表現で行われることも少なくなかった。 同様に、動的生成されるクエリやハッシュなどを URL に含める場面でも、やはり文字列操作による構築が行われてきた。 片手間な正規表現や文字列処理が、 URL
「Socket.IO は必要か?」または「WebSocket は通るのか?」問題について 2016 年版 | blog.jxck.io
Intro 「Socket.IO 使ったほうがいいですか?」 という主旨の質問をもらった。 これは、 WebSocket が繋がらない環境に向けて、フォールバック機能を有する Socket.IO にしておいた方が良いのかという意味である。 WebSocket が出てきた当初と比べて、 Web を取り巻く状況は変わったが、変わってないところもある。 念のためと Socket.IO を使うのもよいが、「本当に必要なのか」を問うのは重要である。 Rails も ActionCable で WebSocket に対応し、ユーザも増えるかもしれないことも踏まえ、 ここで、もう一度現状について、把握している範囲で解説しておく。 "繋がらない" とは 最初に、なぜ 繋がらない ことがあるのかを、きちんと把握したい。 まず WebSocket の有史全体をみれば、繋がらないとして語られていた現象は、大きく
Fetch での Stream を用いたプログレス取得とキャンセル | blog.jxck.io
Intro WHATWG が定義する Fetch API は、出たばかりの仕様では、途中でのキャンセルや、プログレスイベントの取得が含まれていなかった。 しかし、後の更新で fetch 結果の Response Body が WHATWG Stream API を実装することになったため、現在の仕様ではプログレスを取ることもキャンセルをすることも可能となっている。 今回は、こうした API のアップデートについて記す。 Update 最初の公開時には、以下のように書いていた。 「XHR ではできるが Fetch ではできない」ことが、仕様上は無くなったことを意味する。 しかし、現時点で仕様としてまだ出来ないことがあることが判明した。 Upload の Progress これに伴い、記事の一部を修正した。 Fetch 最新の Fetch の仕様は以下で確認できる。 Fetch Spec 仕様
Resource Hints API でリソースの投機的取得 | blog.jxck.io
Intro Resource Hints とは現在提案されている以下のドラフトであり、ブラウザに「次に必要となるリソースを教える」ことで、投機的な取得を行う API 群である。 https://w3c.github.io/resource-hints/ 主に以下がある。 dns-prefetch preconnect prefetch prerender 今回は本サイトでこれを適用した話。 投機的なリソース取得 例えば、ログインページの次には、そのサービスのメインページに遷移する頻度が高い。 そして、メインページでは、以下のような追加のリソースが必要になるだろう。 追加の JS 追加の CSS 追加の Image 追加の API アクセス それぞれを DNS 解決 -> TCP 接続 -> リソースのフェッチ、と繰り返していくと、イニシャル表示は必然的に時間がかかる。 ところが、この遷移に
HTTP2 を前提とした HTML+CSS コンポーネントのレンダリングパス最適化について | blog.jxck.io
Intro Chrome が予定している <link rel=stylesheet> の挙動の変更について、 Google Chrome チームの Jake が、興味深いブログを上げている。 The future of loading CSS この内容は、単に Chrome に対する変更だけではなく、 HTTP2 によって変化する最適化手法と、それを最も活かすための HTML, CSS の構成についてのヒントがある。 今回は、この内容を意訳+補足解説し、本サイトに適用していく。 HTTP/1.1 時代の CSS HTML 自体がコンポーネントを意識した作りになっている場合は、自然と CSS も class などを使いコンポーネント単位に作ることができるだろう。 しかし、 HTTP/1.1 では、リクエストの数を減らすために全ての CSS を 1 つ(もしくは少数個)に結合する最適化が主流だ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
