It's unclear how multipart/x-mixed-replace should be handled

[farre]

I've mostly seen multipart/x-mixed-replace used as a pre-video element solution for "streaming" jpeg to <img> element, a la mjpeg but the sub-resource of a multipart/x-mixed-replace can be of any type, and even switch between resoureces as far as I can tell.

This makes it impossible to sniff, which leads me to believe that we need to block multipart/x-mixed-replace entirely but I'm not at all sure of how web compatible this is.

[annevk]

Does such a response always use Content-Type: multipart/x-mixed-replace? Would the first couple of bytes not identify whether it's an image or not? Either we can use that combination or we can safelist multipart/x-mixed-replace in its entirety and strongly recommend against using it.

[farre]

Maybe there's a compromise here, if we say that we sniff the first part and block based on that and if the subresource changes type, then we just allow it.

That might be better than just allowing it in its entirety. I'm not sure how hard this is to spec or implement though, just immediate thoughts.

[annevk]

Yeah, I was thinking that too. If it looks like it's going to be a stream of images based on the initial response, sure, go ahead. And then the server is on the hook for sending things later it didn't want to go across origins. But if it immediately sends something else, we block.