haxe.Http.requestUrl() throws InvalidAccessError on haxe-js

1

Just tried haxe.Http.requestUrl() on haxe-js target and it throws InvalidAccessError in browser. Digged around a bit and found that this may happen if XMLHttpRequest is synchronous, which it is for requestUrl, and some conditions are met, for example responseType attribute is non-empty (XMLHttpRequest Standard) or timeout attribute is not zero (XMLHttpRequest Standard).

I’m on Haxe 4.3.3 and in std/haxe.http.HttpJs.hx source file at line 138 the responseType is indeed set. If I comment out this line, the InvalidAccessError is not thrown, the XMLHttpRequest request returns content from the url, but requestUrl still fails for other reasons (namely, the implementation expects the response to be array buffer, and now it’s not).

So, off the bat, it looks like the InvalidAccessError is triggered by setting responseType and doing synchronous XMLHttpRequest request.

My code (that throws the error) is just this:

function fetch_from_url( url : String ) : String {
  return Http.requestUrl( url );
}

where Http resolves to haxe.http.HttpJs for haxe-js target.

Is this a bug or am I doing something wrong?

2

Apparently, requestUrl() is only intended to be used on sys target: haxe.http.HttpBase - Haxe 4.3.4 API
RTFM I guess? :man_facepalming:
To my defence, that is mentioned in documentation for HttpBase, and not HttpJs.
On the other hand, maybe the doc for HttpJs requestUrl() should mention that it’s only intended for sys target?

3

For anyone interested, quick’n’dirty, happy-path-only sync GET request in browser:

function fetch_from_url( url : String ) : String {
    var req = js.Browser.createXMLHttpRequest();
    // https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/open
    req.open("GET", url, false);
    // https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/send
    req.send();
    return req.responseText;
}

Keep in mind that this may not work except in a Worker, as noted here: XMLHttpRequest: open() method - Web APIs | MDN

Also, obviously, don’t do this in production :smile_cat: