従来から個人的なJavaScriptコードを多数書いていたは、ScrapboxでUserScriptを書き始め、すぐにどハマりする

じきに、どうにかCross Origin Resource Sharingが実現できないかと探究を始め、プロキシサーバーに注目

connect-srcが制約されていたため、Cross Origin Resource Sharingはほとんど不可能と考えられていた

cors-anywhereを常用していたことで、プロキシサーバー自体には親しんでいた

は、Scrapboxの画像のContent Security Policyが寛容なことに気づき、レスポンスを画像に埋め込めば通信が実現できるのでは、というアイデアを思いつく

概要

Google Apps Scriptを採用

2021年5月はじめごろ

ググってみたところ、ビットマップ画像ならヘッダー情報は54バイトで済み、簡単に実装できそうだという結論に至ったは、Proof of Conceptを開始する

画像エンコーダを実装

多分この時だったはず

しかし、Google Apps Scriptでは、どうしてもバイナリデータを提供することができず、挫折

特に常用していた経験があったため選んだ

このプロジェクトの最初の動機は、「本来画像を提供できないGoogle Apps Scriptでも、無理矢理バイナリをテキストにして、 Content-Type: text/html のまま画像として読み込ませることで画像送受信を実現してやろう」という悪戯心で始まっていた

そのため、主なモチベーションを失ったは、しばらくこの話題から離れることになる

失敗の原因はCross Origin Read Blocking

画像をテキストだと言い張って画像要素に読み込ませようとしたため、当然ながらブロックされる

テキストのデータを画像にエンコードし、それを Content-Type: text/html のまま画像として読み込ませるという荒技を試みていた

この頃の名称はまだbitmap-proxyとして考えていた

2021年8月末〜

は、失敗した後もたびたび気にかかっていた「ScrapboxでのCross Origin Resource Sharingの実現」をもう一度試みるようになる

今回選択された実行環境はglitch

開発名がnode-bitmap-proxyとなる

画像エンコーダがGoogle Apps Script（≒JavaScript）で書かれていたため、Node.jsが動く必要があった

サーバーサイドにcors-anywhereを導入し、本格的なウェブサーバーの構成をとる

画像エンコーダとサーバーを一週間ほどかけて調整し、正常な読み込みを苦しみながら実装

Proof of Concept達成

苦労の原因はcors-anywhereの構成を詳しく理解する必要があったため

しかし、ソースコードのリファクタが必要だと感じたは、再びこのプロジェクトを保留

達成したのは実は ブラウザからのリクエスト内容を、指定URLにバイパスする というだけで、元来の URLからのリクエスト情報のデコード は実装していなかった、というのもあった

実生活もめっちゃ忙しかった

2021年10月はじめ〜2021/10/06

サーバーサイドのリファクタリングに一定の目処が立つ

しかし、ブラウザ側のfetch関数の実装に難航

Server-side HTTP Requestを許容するか？それともWHATWGのWeb Fetch APIに基づく挙動にするか？を決めかねていた

Web Fetch APIはServer-side HTTP Requestに比べ、かなり制約が多い

そこでコンセプトが抽象化される

before

after

違い

リクエスト元に応じて、可能な手段を適宜実行する

Scrapboxなら画像

より自由な通信を可能にして、ユースケースを拡大する

js-fetch-proxyの誕生