New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling of urls which don't have file extension #702

Closed
kt3k opened this Issue Sep 6, 2018 · 13 comments

Comments

7 participants
@kt3k
Copy link
Contributor

kt3k commented Sep 6, 2018

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

This comment has been minimized.

Copy link
Collaborator

ry commented Sep 6, 2018

I agree

@kitsonk

This comment has been minimized.

Copy link
Contributor

kitsonk commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Contributor

MarkTiedemann commented Sep 7, 2018

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

This comment has been minimized.

Copy link

guybedford commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Collaborator

ry commented Sep 7, 2018

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

@qti3e

This comment has been minimized.

Copy link
Contributor

qti3e commented Sep 7, 2018

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

This comment has been minimized.

Copy link
Contributor

MarkTiedemann commented Sep 8, 2018

@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

This comment has been minimized.

Copy link
Contributor

aduh95 commented Sep 8, 2018

@MarkTiedemann one can add

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

This comment has been minimized.

Copy link
Contributor

MarkTiedemann commented Sep 8, 2018

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

@qti3e

This comment has been minimized.

Copy link
Contributor

qti3e commented Sep 8, 2018

@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

This comment has been minimized.

Copy link
Contributor

MarkTiedemann commented Sep 8, 2018

it's for humans

Exactly my point.

@ry ry added the bug label Sep 10, 2018

@ry ry added this to the v0.2 milestone Sep 10, 2018

@ry

This comment has been minimized.

Copy link
Collaborator

ry commented Oct 11, 2018

Related to #859.
But this issue is still not complete.

@kitsonk

This comment has been minimized.

Copy link
Contributor

kitsonk commented Oct 12, 2018

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.

This was referenced Oct 12, 2018

@ry ry closed this in #1020 Oct 23, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment