Closed chrisfarms closed 2 months ago
@chrisfarms
Why is there a silent catch around the URL parsing? Because we were silly and didn't use
URL.canParse()
- what is theurl
you are providing where this fails? @ZaymonFC recently encountered an issue here
An example of the failing parse is a URL like:
ipc://platform.event?value=load&location.href=blob%3Asocket%3A%2F%2Fcom.substream%2Fc90afb20-2069-453e-b0ca-1982fa0c9019&index=0&seq=R7&nonce=1720163215341&runtime-worker-id=2636370820803840258&runtime-worker-location=blob%3Asocket%3A%2F%2Fcom.substream%2F74775b96-14c9-45d0-a6f4-e65fb67c87cd&runtime-frame-type=worker&runtime-worker-type=worker&__sync__=true
but critically ... the "location.origin" passed as the base
is: "null"
(not null
the string "null"
?!)
so the URL is valid, the base is not
maybe the parse should not be setting base if origin is null (which is the case in worker land I guess)?
url = new URL(url, location.origin && location.origin !== 'null' ? location.origin : undefined)
but that null feels like a symptom of something else.
what
Buffer.concat
expects either a Uint8Array or Buffer ... but the fetch ReadableStream passes in a plain ArrayBuffer ... this makes it unhappy ... so this wraps in the TypedArray before giving to concatwhy
I am attempting to get three.js GLTFLoaders working, and running into the above issues.
note
I am NOT confident that either of these are the right thing to do.
Should Buffer.concat actually be fixed to support plain ArrayBuffers instead?
Why is there a silent catch around the URL parsing?