問題タブ [service-worker]

Service Worker でイメージのエラー 404 を検出しようとしています。画像取得のステータス コードを取得する方法はありますか?

このコードは html ファイルでうまく機能しますが、画像をフェッチするときのステータス コードは常に 0 です。画像のステータス コードを取得する方法はありますか? 例を簡単にするために、キャッシュとその他すべてを削除しました。

これは私が読み込もうとしたサンプルページです:

したがって、html ページ自体のステータスは 200 ですが、両方の画像はステータス 0 を返します。

Service Worker から一連の PUT & POST リクエストを送信する必要があります。それらが送信される順序が重要です。

要件：

• リクエスト メソッド、URL、および JSON 本文を指定して、リクエストを送信します
• 成功した場合 ( response.status < 300):
  • body を success 関数に渡す
  • キュー内の次のリクエストを呼び出す
• 失敗した場合:
  • responseText または err をエラー関数に渡す
  • 実行を停止

単純にキューを繰り返し処理し、fetchリクエストごとに呼び出すと、ネットワークの差異によって (多くの場合) リクエストがサーバーに順不同で到着する可能性があります。

fetch各結果が前の結果に依存する一連の要求を作成するにはどうすればよいですか?

私が試したこと：

• 代わりに XHR を使用します (「async: false」を使用できると仮定しますが、これは Service Worker では許可されていません)。
• setTimeout(sendRequest, i*200). ハック、信頼できません。
• Promise loopsこれらの例ES6 Promise Patternsに基づいています。これは最も有望に思えましたが、例は成功を想定した単純なケースです。フェッチで動作させることはできません。

コンテキスト: API リクエストの「アウトボックス」を使用して、オフラインでのデータの読み取り、作成、および更新をサポートしています。この順序の問題を除いて、うまく機能します。

URL パスの一部を無視する式 ( pathではなくignoreSearch )を使用して、要求 URL を照合するユース ケースを発見しました。

このユース ケースは、画像のサイズが URL パスでエンコードされるレスポンシブ デザインで使用される画像処理サービス用です。これは、これらの種類のサービス (Cloudinary、Firesize、さらには Lorempixel) に共通するものです。

ときどき、ディメンション コンポーネントの 1 つが 1 ピクセルずれていることに気付きました。必要なディメンションはクライアントから計算されます - エラーの原因はここで丸められます- しかし、Service Worker キャッシュは、このバリエーションの洗練されたソリューションになる可能性があります。ただし、URL パスの一部を無視できるように指定できないため、この丸めの問題によりキャッシュ ミスが発生します。

URL 式のマッチングは仕様の一部になる予定はありますか? 一般的に、「URL A でフェッチ、URL B でキャッシュを配置/一致」のパターンが大きくなっても問題ありませんか?

これに対する回避策は、ignoreSearch の現在の回避策 (実装まで) と同じであることがわかりました。つまり、ある URL でフェッチし、別の URL でキャッシュします。URL パス式の一致が仕様の一部になるかどうか、または URL 式一致の使用例が検討されているかどうかは疑問です。信頼できる仕様には、これに関する証拠はありません。

洞察力のある言葉を前もって感謝します。

CSRF で保護された (クエリ文字列 + Cookie) API POST リクエストを保存して、後で webapp がオンラインに戻ったときに再生しようとしています。

これを行うには、Request オブジェクト (Fetch API) を IndexedDB に保存したいのですが、IDBObjectStore.put が DataCloneError "An object could not be cloned" で失敗します。

Request オブジェクトには単純な JSON 本体があり、バイナリ データはなく、すべて文字列だけです。
これは Service Worker (Web Worker) 環境で実行されています。

構造化された複製アルゴリズムが要求オブジェクトを複製しない理由はありますか? [回答: はい] もしそうなら、構造化されたクローニングの代わりに、このオブジェクトを脱水/再水和するための最良のオプションは何ですか?

Request オブジェクトの個々のプロパティを知る/アクセスする必要はありません。必要な Request の部分は、URL、ヘッダー、本文、および Cookie です (ただし、コードにそれを認識させたくありません)。

アドバイスをよろしくお願いします。