Deferred Layer#2329
Conversation
|
I think there's a serious UAF here. The transfer of an deferred request will be deinit'd while the request still lives in the deferred list. I tested this out by writing a log when transfer.deinit is called, and that always happens before the request is "fired". Another issue is that this defers the done/error/shutdown but the header/data are just as important to block from firing. |
|
A while ago, I looked at something that did something similar - delaying new requests until blocking requests were complete. I don't remember exactly what I measured, but it was that it would introduce significant latency. You can imagine: const xhr = new XMLHttpRequest();
...
xhr.send();
// do something that take 500msIf the DeferredLayer defers this request, then it adds 500ms before the request starts. You want to start the HTTP request ASAP, just not process the callbacks. I also think the code current leaks requests, e.g. what happens if |
0e473d5 to
4f79529
Compare
|
Reworked it a bit around your new changes with Transfer and all. |
| .{ .value = blocking_request_id }, | ||
| ); | ||
| } | ||
| self.client.deferring_layer.flushFrame(frame_id); |
There was a problem hiding this comment.
So every callsite that wants to make a blocking request (and there are more), needs to do this?
This solves the issue of scripts running while blocking scripts are running by introducing a
DeferringLayer. This layer defers the completion of requests while a blocking request is running, clearing them later onstaticScriptsDone.This tracks the currently active request by its ID ensuring that each frame can only have one blocking request at a time and deferring the scripts.