You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We noticed that the current spec draft whatwg/fetch#1540 indicates that request interception should work even if the request is handled from cache.
In Chromium, this will be difficult to support since a lot of cache handling is happening synchronously and current implementations only covers actual requests that go out to the network.
We also currently do not have a use case for intercepting already cached requests so we would like to update the draft to support interception (but not logging) only for non-cached requests that will be actually sent to the network.
Alternatively, if we allow intercepting requests that have cached responses and the user changes headers, those would not reach the server since the response has already been cached leading to confusing results.
We noticed that the current spec draft whatwg/fetch#1540 indicates that request interception should work even if the request is handled from cache.
In Chromium, this will be difficult to support since a lot of cache handling is happening synchronously and current implementations only covers actual requests that go out to the network.
We also currently do not have a use case for intercepting already cached requests so we would like to update the draft to support interception (but not logging) only for non-cached requests that will be actually sent to the network.
Alternatively, if we allow intercepting requests that have cached responses and the user changes headers, those would not reach the server since the response has already been cached leading to confusing results.
WDYT?
@sadym-chromium @alexnj @jgraham @whimboo
The text was updated successfully, but these errors were encountered: