Blocking JSON breaks web compat

[farre]

We've had this happen in the wild:

function loadScript(e,t,o){
    var n=document.getElementsByTagName("script")[0],
        a=document.createElement("script");
    a.type="text/javascript",a.src=e,o&&(a.onerror=o),n.parentNode.insertBefore(a,n.nextSibling),t&&t()
    }

loadScript(
  _data.source.base+_data.source.groups,
  null,
  function(){
    initErrors("Error."),
    _data.source.error=!0
  }
)

where the script to be loaded is proper JSON.

This means that we would block with ORB, and expose this through onerror. This has the unfortunate effect to break the site if the onerror handler actually sees this as a terminal error (which is what we've seen).

We're aiming to handle this the way we're currently handling Window.fetch, namely that we're going to clear the body of the internal response, but allow the load. This is a work-around, but I wonder if this is how we should spec this?

[annevk]

Would we also clear the headers? (Although, what if they used Cross-Origin-Resource-Policy: cross-origin? Should that be forwarded?)

This sounds like Chromium's initial take which had a synthetic "empty" response with some complexity. That seems rather unfortunate as it gives attackers additional details about the response as well.

If this is also done for fetch() that is indeed something that would need to be specified as it would be quite different from what is currently required.

[farre]

To some extent we'd need to clear headers. And it is unfortunate, I'd much rather block. But we keep running into these cases of scripts breaking due to ORB blocks where we're changing behavior, rather than being indistinguishable from network error.

[farre]

@otherdaniel, just a heads up to issues you might run into.