Deno: Handling of urls which don't have file extension

[kt3k]

Currently deno doesn't seem handling a url which doesn't have a file extension. However browsers seem working with such urls.

<script type="module">
  import React from 'https://dev.jspm.io/react';
</script>

I think deno should handle those urls as JavaScript because that's more browser compatible and because it allows deno to work with https://dev.jspm.io. If deno works with jspm.io, I think it enables a lot of more meaningful experiments which depends on npm modules.

[ry]

I agree

[kitsonk]

I assume we will want the privileged to resolve the extension? If it does, and the file_name and module_name get changed to the fully qualified name including the extension, I believe there would be little to nothing to do in the compiler. It would be great to not have the compiler "guessing" at file extensions if at all avoidable.

[MarkTiedemann]

Related question.

Unlike scripts, modules must be served with a valid JavaScript MIME type in the browser, otherwise they won't be executed (jspm.io sets Content-Type: application/javascript, for example).

Should deno replicate this behavior in some way? For example, if https://dev.jspm.io/react would have a content type of text/html, should deno log an error and exit with a non-zero exit code?

[guybedford]

It definitely makes sense to me to have the Content-Type as the content type preference, followed by the file extension. And to throw when neither provides a strong indicator.

[ry]

@MarkTiedemann Yes I think so. Currently we don't look at content-type.

[qti3e]

I think we should not even check for the extension, at least in the Unix world extension means nothing, we only have to check content-type, as it is the only thing that matters.

[MarkTiedemann]

@qti3e I disagree that the extension of a file "means nothing". Yes, extensions are arbitrary in a way, but they are also hints for programs what kind of content is to be expected within a file. For example, many (but not all) programs (and humans) expect .js files to contain JavaScript. If there is Haskell code in a .js file, then it doesn't suddenly turn into some kind of Haskell file, but it is simply a file that contains invalid JavaScript to those programs. So a program like Node, for example, will throw a parsing or syntax error when reading the file. In a file-system world, the extension of the file is the best and strongest indication of what kind of content a file contains (or should contain) that is available before reading the actual content of the file.

@guybedford I don't think the content type should take precedence over the extension. Instead, I'd propose the following:

• No file extension, no content type -> Should throw an error
• Unsupported file extension, no content type (e.g. .html) -> Should throw an error
• No file extension, unsupported content type (e.g. text/html) -> Should throw an error
• Supported file extension, no content type (e.g. .js) -> Should be fine
• No file extension, supported content type (e.g. application/javascript) -> Should be fine
• Supported file extension, matching content type (e.g. .js, application/javascript) -> Should be fine
• Supported file extension, conflicting content type (e.g. .js, text/html) -> Should throw an error

[aduh95]

@MarkTiedemann one can add

• Unsupported file extension, supported content type (e.g. .html, application/javascript) -> Should be fine

[MarkTiedemann]

@aduh95 I think that's very confusing, and should be avoided.

[qti3e]

@MarkTiedemann

In a file-system world, the extension of the file is the best and strongest indication of what kind of content a file contains (or should contain) that is available before reading the actual content of the file.

Ok... let me disagree with you on that, in the file-system world there is nothing stronger than the magic number of a file which is mostly the first bytes of the content itself, every _real_ binary file format like elf and exe has one.

Also, the file extension is not for computers, but it's for humans, and if you suppose a file extension to have some significant meaning, it's not for machines and systems, and it's only there for us (as humans).

Our responsibility as system designers and library developers is to design for computers in the first degree and let other developers develop for other developers!

So basically we should exclusively ignore a file extension while dealing with remote files. (I'm not sure about local imports)

The classic captcha was a good example when we had a .php file extension and then we sent the Content-Type: image/png and browser rendered the data as a PNG image, but not as an ASCII text.

[MarkTiedemann]

it's for humans

Exactly my point.

[ry]

Related to https://github.com/denoland/deno/pull/859.
But this issue is still not complete.

[kitsonk]

I am working on this now.

We also need to consider resolving local media types as well being determined in the privileged side, so the compiler does not rely upon file extensions at all.