With the current state of the CustomRequestHeaders/CustomRequestModifieres we are running into issues with our Web application once it needs to load data from external sources.
The application loads models and textures from an rest api endpoint within the same base url (though it is routed to another container that actually hosts the rest api)
This endpoint requires correct Authorization tokens sent alongside the requests.
So far we achive this by using the WebRequest.CustomRequestHeaders.
This works for models but not for textures, as textures are loaded internally from babylon by creating an image element and setting the url property. We currently work around this by wrapping the Tools.LoadImage method to manually inject the authorization header.
When we started to play around with WebXR which dynamically loads controller definitions and models from github.com/immersive-web and controllers.babylonjs… url’s we got hit by CORS errors.
This was the result of our code leaking the tokens to the “outside world”.
One thought was inejcting the Authorization headers with CustomRequestModifiers. However they are called before the underlying XMLHttpRequest is open which will result in a similar crash back when CustomRequestHeaders were injected to early. (#6055).
As a temporary workaround we removed the Authorization headers from CustomRequestHeaders and inject them inside CustomRequestModifiers by inside an eventlistener to ready state open only if the request goes to our rest endpoint.
The same crash might occur if one constructs a new WebRequest object and calls the recently added setRequestHeader method before the WebRequest is actually open.
I would like to get some feedback on what side effects this might cause moving down the CustomRequestModifiers handling from WebRequest.open to WebRequest.send right after CustomRequestHeaders have been injected.
Or would it even make sense to provide OnBeforeOpen, OnBeforeSend observers as a convenient way to do some work on the underlying XMLHttpRequest ? This might go along with some refacturing i.e. renaming CustomRequestModifiers and/or removing CustomRequestHeaders since the CustomRequestModifiers could be used to achieve the same goal.
While digging deeper into the refacturing hole another option would be to derrive from XMLHttpRequest itself saving quite a few lines of code. Taking it would be usable by all supported browsers.
And even further in… The long run would it make sense to shift towards the fetch API in order to benefit from Promises and flat awaitable async functions? Though this is probably long down the road.