request (URL) -> Response { status, headers, body }
a. If Response contains Content-Type, then done.
b. Otherwise, fall into Content-Type identifier, which for most cases, is auto-generated from supplied file extension to mime-type mapping
c. However, if you supply a custom identify function or whatever, then you are given (URL, bytes) and can return mime-type or false.identify returns a Content-Type given (URL, bytes). By default this function is automatically generated from the file extension to mime-type mapping. But something like Dockerfiles need custom logic (and only needs to URLs), but imagine a shell script, which would determine the Content-Type based on the first line of the file.
a. Or should it be headers, where it is { Content-Type: }, but could include additional headers, such as x-ecma-goal-symbol: "module" or "script".load(Response: { headers: { Content-Type } }, body) -> { source, type, exports? }
Nice to be able to access load from outside import.
request (URL) -> Response { status, headers, body }a. If Response contains Content-Type, then done.
b. Otherwise, fall into Content-Type identifier, which for most cases, is auto-generated from supplied file extension to mime-type mapping
c. However, if you supply a custom identify function or whatever, then you are given (URL, bytes) and can return mime-type or false.
identifyreturns a Content-Type given (URL, bytes). By default this function is automatically generated from the file extension to mime-type mapping. But something like Dockerfiles need custom logic (and only needs to URLs), but imagine a shell script, which would determine the Content-Type based on the first line of the file.a. Or should it be
headers, where it is { Content-Type: }, but could include additional headers, such asx-ecma-goal-symbol: "module" or "script".load(Response: { headers: { Content-Type } }, body) -> { source, type, exports? }Nice to be able to access load from outside import.