ERのフェッチ操作に関するよくある質問 - - Alibaba Cloud ドキュメントセンター

EdgeRoutine (ER) のフェッチ API に関するよくある質問です。展開、サブリクエストの制限、URL 検証、コネクションプールについて説明します。

フェッチは展開をサポートしていますか。

フェッチは、デフォルトでレスポンスを展開します。次の展開メソッドを使用できます：

decompress：デフォルトのメソッドです。レスポンスの content-encoding ヘッダーを読み取り、最も右にある identity 以外の値で指定された展開アルゴリズムを使用します。たとえば、content-encoding: gzip, identity の場合、 gzip が展開アルゴリズムです。この値がレスポンスヘッダーから削除されると、次のようになります：
- content-encoding: identity, gzip が元のレスポンスヘッダーの場合、gzip が削除された後、ヘッダーは content-encoding: identity になります。
- content-encoding: gzip が元のレスポンスヘッダーの場合、gzip が削除された後、content-encoding のみが残ります。
説明
アルゴリズムがレスポンスヘッダーから削除されると、オリジンサーバーが非圧縮データを返した場合と同様に、データは読み取り可能になります。ER は Gzip のみをサポートしており、認識できないアルゴリズムに対しては例外をスローします。Brotli は、将来のバージョンでサポートされる可能性があります。
fallbackIdentity： decompress と同様ですが、展開に失敗しても例外をスローしません。代わりに、ER は認識できないアルゴリズムの値を Identity として扱い、展開せずにデータをパススルーします。この場合、データがまだ圧縮されていれば、読み取り不可能なままであることがあります。
manual：データを展開しません。

展開ポリシーを手動で設定するには、次のいずれかのメソッドを使用します：

fetch(url, {decompress: "manual"})
fetch(url, {decompress: "fallbackIdentity"})

フェッチでサポートされているサブリクエストの最大数はいくつですか。

フェッチは最大 32 個のサブリクエストをサポートします。この制限は、ポイントオブプレゼンス (POP) でキャプチャされたリクエスト、3xx リダイレクト、キャッシュ API コールなど、すべてのコンテキストに適用されます。クォータの引き上げを申請するには、チケットを送信してください。

ER は無効な URL を認識できますか。

ER は URL を検証しません。URL に無効な文字が含まれている場合、ER はエンコーディングエラーを返します。URL が適切にフォーマットされていることを確認してください。

コネクションプールでサポートされる最大接続数はいくつですか。

ER は、TCP または SSL ハンドシェイクによってすべての接続が消費されるのを避けるために、フェッチ用のコネクションプールを提供します。デフォルトでは、プールは最大 128 の接続をサポートします。この制限に達すると、プールは新しい接続のキャッシュを停止します。このクォータを増やすには、クォータの引き上げを申請できます。

コネクションプールはリクエストごとではなく、ユーザーごとです。利用可能な既存の接続がない場合、ER は新しい接続の作成を試みます。ER は、レスポンスボディ全体が取得された後にのみ接続をキャッシュします。

次のコードは、レスポンスボディ全体が確実に消費されるようにする方法を示しています：

async function fetchAndIgnore(url, options) {
  let response = await fetch(url, options);
  // このメソッドは、ER にレスポンスボディを無視させ、レスポンスボディ全体が取得されるようにします。
  await response.ignore();
}