webRequest API：新しいリクエストのrequestIdを取得するにはどうすればよいですか？

Question

chrome.webRequestのAPIは、リクエストID（：Chrome webRequest documentionソース）の概念が

リクエストIDを

は、各要求は、要求IDによって識別されます。このIDは、ブラウザセッションおよび内線番号のコンテキスト内で一意です。要求のライフサイクル中は一定のままであり、同じ要求に対するイベントの照合に使用できます。 HTTPリダイレクトまたはHTTP認証の場合、複数のHTTP要求が1つのWeb要求にマップされることに注意してください。

リダイレクト間でも要求を相関させるために使用できます。しかし、最初にfetchまたはXMLHttpRequestで新しいリクエストを開始するときに、IDを最初から保持していますか？

これまでのところ、新しいリクエストとrequestIdの間の初期リンクを確立する方法として、リクエストのURLを使用するよりも優れた方法はありませんでした。ただし、同じリソースへの重複要求がある場合、これは信頼できません。

質問：

• あなたが（どちらかfetchまたはXMLHttpRequest付き）新しい要求を行った場合、どのように確実にrequestIdへのアクセスを得るのですか？
• fetch APIまたはXMLHttpRequest APIはrequestIdへのアクセスを許可していますか？

私がしたいことは、webRequest APIで提供される機能を使用して1つのリクエストを変更することですが、他の保留中のリクエストを誤って変更しないようにしたいと考えています。

Answer 1

私の知っている限り、fetchまたはXHMLHttpRequest APIに直接サポートはありません。また、私は完全に信頼できる方法でrequestIdを取得する方法を知らない。

最後に、onBeforeRequestリスナーをインストールし、requestIdを保存してからすぐにリスナーをもう一度削除しました。たとえば、次のようになります。

function makeSomeRequest(url) { 

    let listener; 
    const removeListener =() => { 
    if (listener) { 
     chrome.webRequest.onBeforeRequest.removeListener(listener); 
     listener = null; 
    } 
    }; 

    let requestId; 
    listener = (details) => { 
    if (!requestId && urlMatches(details.url, url)) { 
     requestId = details.requestId; 
     removeListener(); 
    } 
    }; 
    chrome.webRequest.onBeforeRequest.addListener(listener, { urls: ['<all_urls>'] }); 

    // install other listeners, which can then use the stored "requestId" 
    // ... 

    // finally, start the actual request, for instance 
    const promise = fetch(url).then(doSomething); 

    // and make sure to always clean up the listener 
    promise.then(removeListener, removeLister); 
} 

これは完璧ではなく、私が残した詳細です。あなたは、単にdetails.urlがurlと同一であるかどうかを比較することができます：

function urlMatches(url1, url2) { 
    return url1 === url2; 
} 

http://some.domain.testに対する要求を行う場合には、例えば、あなたが同じURLを参照することを保証するものではありません、あなたはリスナーでhttp://some.domain.test/を参照することに注意してください（詳細については私のother questionを参照してください）。またはhttp://はhttps://で置き換えられました（ここではわかりませんが、HTTPS Everywhereなどの他の拡張機能が原因である可能性があります）。

これは、上記のコードがアイデアのスケッチとしか見なされていない理由です。同じURLへの複数のリクエストを開始しない限り、実際には十分に機能するようです。それでも、私は問題にアプローチするより良い方法について学ぶことに興味があります。