Impact on streaming responses
anforowicz opened this issue · 2 comments
@MattMenke2 points out that when/if ORB postpones passing the response body to the renderer process (e.g. when ORB needs to first check that the whole response parses as valid Javascript), then ORB can potentially negatively affect streaming responses.
One example given was chat channels without MIME types. It is possible that maybe Jabber structures the entire chat a single JSON entity, which ends only on disconnect. OTOH, it seems that JSON is unlikely to be affected because no-cors JSON responses are already blocked by CORB: 1) when labeled as JSON Content-Type with XCTO:nosniff, 2) when labeled as JSON Content-Type and the first 1024 bytes sniff as JSON, 3) when the first few bytes sniff as a JSON/Javascript parser breaker.
Another example I can think of would be multimedia, but ORB should already handle multimedia robustly by sniffing (and possibly by allowing anything labeled as audio/*, image/*, or video/* as suggested inhttps://github.com//issues/3#issuecomment-648698098).
Still, maybe there are other cases where streaming is needed in a no-cors response that ORB would like to sniff/parse as Javascript? Let's discuss? :-)
Actual JSON cannot be impacted as that requires CORS. The only types that are relevant here are media and JavaScript. And for media it's only the start of the response that is blocking. Not being able to incrementally do things with JavaScript is the most problematic. There are optimizations possible there as well, though I think the focus should be on getting websites to set their JavaScript MIME type correctly as that would eventually allow for a much greater simplification.
I think this can be closed as this problem is limited to JavaScript, which isn't really a streaming format to begin with.