Reverse HTTP Transport が描く新しい Web サービスデプロイ構成 | blog.jxck.io
Intro IETF の httpbis で、 Reverse HTTP Transport という仕様が提案されている。 Reverse HTTP Transport https://www.ietf.org/archive/id/draft-bt-httpbis-reverse-http-01.html この仕様は、 Origin サーバの前に何かしら Intermediaries (Loadbalancer, Reverse Proxy, CDN etc)があるのが一般的な現代の Web サービス構成において、非常に革新的なアイデアを取り入れたプロトコルと言える。 まだ v01 という初期段階ではあるが、発想が非常に面白かったので、読書メモを残す。 登場人物 ベースとして HTTP の話にはなるが、登場人物が多いため Client/Server という「相対的な役割」で話をすると、紛
Promise.withResolvers によるイベントの Promise 化 | blog.jxck.io
Intro Promise.withResolvers() は、 Stage 4 であり ES2024 の候補となった。 すでにブラウザでの実装も進んでいるため、その活用方法を解説する。 イベントの Promise 化 JS では、非同期処理 API は長らくイベントリスナベースで定義され、それを組み合わせるフロー制御で処理されてきた。 しかし、 Promise が定義されて以降は、標準 API も Promise を返すようになり、 async/await によって処理されるのが一般的になってきた。 結果、イベントリスナベースの API を Promise 化するような場面も増えた。 例えば以下のようなものだ。 async function request() { return new Promise((resolve, reject) => { document.querySelect
Cookie2 とは何か | blog.jxck.io
Intro タイトルを見て「Cookie の新しい仕様か、キャッチアップしよう」と思って開いたのなら、以降を読む必要はない。 Cookie History 2000 年に発行された Cookie の仕様である RFC 2965 では、仕様中に Set-Cookie2/Cookie2 (以下 Cookie2) という 2 つのヘッダが定義されている。しかし 2011 年に改定された現行の RFC 6265 ではそれらヘッダは deprecate されており、実際の Web でこれらのヘッダが交換される場面を、少なくとも筆者は見たことがない。存在すら知らない開発者も多いだろう。 筆者はずっと、この仕様がどのように出てきて、どうして消えていったのかが気になっていた。 Web 上にも情報が少なく、「歴史上の理由で」とか分かったようなことを言ってる人がたまにいるくらいだ。四半世紀前のことなので経緯を
XMLHttpRequest とはなんだったのか | blog.jxck.io
Intro Fetch API の実装が広まり、 IE もリタイアを迎えたことで、今後忘れ去られていくことになるだろう XMLHttpRequest について。 どのように始まり、どのように広まり、どのように使われなくなっていくのか。その間に残した多大な功績を残す。 XMLHttpRequest の始まり この名前は非常に長いため、通常 XHR と略される。 この API は、現在の Web API のように W3C/WHATWG による標準化を経て策定された API ではない。 Microsoft によるいわゆる独自実装の API として始まり、後追いで標準化される。 したがって、 Web API の中でもかなり異質な命名である XHR が、 XmlHttpRequest でも XMLHTTPRequest でもなく XMLHttpRequest である理由も、 Microsoft の命
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
Navigation API による「JS での画面遷移」と SPA の改善 | blog.jxck.io
Intro 従来の History API を改善する Navigation API の仕様策定と実装が進んでいる。 これは、 History API の使いにくかった部分を補うだけではなく、「JS で画面遷移をする」という現状のミッシングピースに取り組み、 SPA が抱える多くの問題だけでなく MPA すら改善する可能性がある。 この API の目的と仕様を解説しつつ、実装のメモを残す。 画面遷移と SPA の軌跡 Web は HTML の取得と描画を繰り返す、画面遷移(Navigation)を前提としたアーキテクチャ(のちに SPA からの逆算で MPA と呼ばれる)が基本であり、ブラウザなどの実装もそれに最適化されている。 一方「アプリケーション」の設計手法をそのまま Web に持ち込んだ SPA は、この Navigation によってもたらされる UX の低下を防ぐ部分がある一方
Web のセマンティクスにおける Push と Pull | blog.jxck.io
Intro 筆者は、 Web のセマンティクスに対する実装の方針として、大きく Push 型の実装 と Pull 型の実装 があると考えている。 もっと言えば、それは実装方法という具体的な話よりも、開発者のセマンティクスに対する態度を表現することができる。 この話は「Push よりも Pull が良い」などと簡単に切り分けられる話ではない。 「自分は今 Push で実装しているのか、 Pull で実装しているのか」この観点を意識するかしないかによって、セマンティクスに対する視野が広くなり、その応用として、たとえば今自分が行っている実装が、将来の Web においてどのような互換性の問題を生じるかなどを想像できるようになるだろう。最近問題になる Ossification を、こうした視点の欠如の結果とみることもできる。 (本エントリでの Ossification は、一般に言われている Pro
ローカル開発環境の https 化 | blog.jxck.io
Intro Web の https 化が進み、それに伴って https を前提とする API も増えてきた。 そうした API を用いた開発をローカルで行う場合、 localhost という特別なホストを用いることもできるが、それだけでは間に合わないケースも少なからずある。 localhost を https にするという方法もあるが、そのように紹介されている方法には、いくつか注意すべき点もある。 この辺りの話を、直近 1 ヶ月で 3 回くらいしたので、筆者が普段使っている方法や注意点についてまとめる。 特に推奨するつもりはない。 Update chrome の --host-rules について追記 localhost での開発の注意点 例として https://example.com にデプロイする予定の ServiceWorker を用いたアプリがあったとする。 開発をローカルで行う
Service Worker の Background Fetch によるメディアのキャッシュ | blog.jxck.io
Intro Podcast を PWA 対応するために、待望だった機能の 1 つが Background Fetch だ。 これにより、通常 Range Request で取得するような、大きなファイルを事前にダウンロードしておくことができるようになる。 この API と、 Service Worker およびブラウザにおける Range Request/Partial Response の扱いについて記す。 background fetch Podcast は大きな音声ファイルがメインコンテンツとなる。 PWA のキャッシュ戦略典型例としては install 時に全てキャッシュする request 発生時にキャッシュする といった方法がある。 しかし、この方法は一般的な Podcast としては少し使いにくい。 install 時に全てのファイルをキャッシするのは現実的ではない requ
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
Clear-Site-Data Header | blog.jxck.io
Intro Clear-Site-Data Header の実装が進んでいる。 このヘッダについて解説する。 Clear-Site-Data 例えばログアウト処理を実施する場合は、レスポンスヘッダで Cookie を無効にするといった形で実現されるだろう。 しかし、最近では Cookie 以外にも多くのストレージがあり、アカウント特有のデータが保存されていることが多い。 local storage session storage indexed db service worker cache api これらを、ログアウト処理の中で各 API を適切に呼び出し、全て確実に削除するのは簡単ではない。 また、 httponly の Cookie や browser cache などは、 JS からの削除もできない。 SPA のように実装されている場合は、その状態を含めて初期化しないと不整合が発生
Safari による User-Agent 固定化と Web における Feature Detection | blog.jxck.io
Update 2018/3/1 : Safari 11.0.3 の UA を追記 2018/4/16: Safari 11.1 の UA を追記 2018/5/1 : OS のバージョンは固定されなくなった件を追記 2 月に方針が変更され、 OS のバージョンは固定されなくなった。 このため、 iOS のバージョンアップにより発生するバグなどを回避する道は残されたことになる。 一方 Webkit のバージョンは(予定では 605.1.15 に)固定されることになりそうだ。詳細は、以下を参照。 Safari の UA 文字列が固定されて固定されなくなったおはなし - fragmentary Intro 少し前に Safari Technology Preview 46 がリリースされた。 Service Worker のアナウンスに目がそちらに盗まれている一方、しれっと以下の一文がある。 F
Fetch の中断と Promise のキャンセル方法の標準化 | blog.jxck.io
Intro XHR から fetch() に積極的に移行しづらかった最大のミッシングピースとして、中断できないという問題があった。 これは、 fetch() が選んだ Promise ベースのインタフェースにおいて、キャンセルをどうするかという議論と絡み、長く決着が付かずにいた問題である。 最近、やっと話が前進したので、ここまでの経過を解説する。 Fetch のミッシングピース fetch() は、ブラウザが発行するリクエストと、取得するレスポンスを扱う低レベルなインタフェースとして策定が始まった。 DOM の API が Promise ベースに移行しつつある流れを汲み、 fetch() もまた Promise を返す関数一発スタイルになった。 クラスからインスタンスを生成しメソッドを呼ぶ XHR スタイルでは、インスタンスを再利用した場合の挙動などを含め、オブジェクトのライフサイクルを
EventTarget の継承可能化による EventEmitter の代替 | blog.jxck.io
Intro 念願 だった EventTarget の constructible/subclassable が DOM の仕様にマージされた。 これにより、いわゆる EventEmitter のブラウザ移植が不要になることが期待される。 Allow constructing and subclassing EventTarget Update Chrome Canary 64 で実装が確認できたため、 DEMO を追加した。 EventTarget EventTarget には addEventListener, removeEventListener, dispatchEvent が定義されている。 これは、ブラウザが内部で生成する Event や、任意に生成された CustomEvent を発火/補足するために利用される。 callback = console.log.bind(con
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 仕様
Passive Event Listeners によるスクロールの改善 | blog.jxck.io
Intro DOM のイベントリスナの仕様に Passive Event Listeners というオプションが追加された。 このオプションは、主にモバイルなどでのスクロールの詰まり(Scroll Junk) を解決するために導入されたものである。 今回は、この仕様が解決する問題と、本サイトへの適用を解説する。 Passive Event Listeners Spec Scroll Event の PreventDefault() 画面のスクロールに合わせたインタラクションを実装する場合、 Scroll Event にイベントリスナを登録する。 典型的な例では touchstart や touchend をフックし、その中で DOM の操作などを実施するなどがある。 場合によってはイベントリスナ内で preventDefault() を呼ぶことで、スクロールそのものを止めることもできる。
中級者向け Service Worker Tutorial | blog.jxck.io
Intro Service Worker の初心者向けのチュートリアルや、使ってみた系のエントリも増えてきました。 しかし、 Service Worker は通常のブラウザ用 JS の開発と少し経路が違い、慣れるまで開発やデバッグもなかなか難しいと思います。 そこで特に難しい部分、そして分かっていないと実際にデプロイした際に難しいと思う部分について、実際に動きを確認しながら解説したいと思います。 なお、 Service Worker の基本的な概念などについては、他のチュートリアルなどを見て理解している前提で進めます。 思いつきで撮ったので色々ミスも有ります、また Chrome Dev Tools の UI はどうせ変わるのでそのつもりで見てください。 TODO になっている動画は、そのうち撮って追加します。 List claim controllerchange updatefound
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
