Skip to content
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.

Sign up for GitHub

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

Jump to bottom

HTML module should require a new MIME type #742

Open
annevk opened this issue Mar 6, 2018 · 10 comments
Open

HTML module should require a new MIME type #742

annevk opened this issue Mar 6, 2018 · 10 comments
Labels
modules

Comments

@annevk
Copy link
Collaborator

annevk commented Mar 6, 2018

It seems navigating directly to an HTML module should not result in rendering and script execution. A download seems safer. (Need to make sure it doesn't get sniffed, either.)
@annevk annevk added the modules label Mar 6, 2018
@rniwa rniwa changed the title Require a new MIME type HTML module should require a new MIME type Mar 9, 2018
@rniwa
Copy link
Collaborator

rniwa commented Mar 9, 2018

text/html-module or application/html-module perhaps? I guess we'd need to make a recommendation for a new file extension as well. e.g. mymodule.htmlmodule. If regular HTML files and HTML modules both end with .html or .htm, it's going to be really annoying to give a different MIME type in various server environment as well as local environment. e.g. file on macOS and Windows probably won't be able to get the right MIME type.

@tomalec
Copy link
Contributor

tomalec commented Mar 28, 2018

I'd like to give another use case for using specific mime types.
Currently, I'm using HTML Imports to build client-side includes driving SPA. I'd like to use HTML Modules for this as well.

I would like to be able to request the same URL to open a new complete page (text/html) as one to request a module with the partial view and dependencies (text/html+module) to morph existing page into.

@ExE-Boss
Copy link

ExE-Boss commented May 11, 2018 •
edited
Loading

If anything, it should probably be application/html-module+html or application/xhtml-module+xml.

(The content after the + signifies encoding, so text/html+module would violate the MIME type specification, but text/module+html or application/module+html wouldn’t)

Another issue, at least when using HTML modules inside a XHTML document, is that XML determines the element type based on the namespace, which is what #752 intends to solve.

@ExE-Boss ExE-Boss mentioned this issue May 19, 2018
Open
@annevk
Copy link
Collaborator Author

annevk commented Oct 5, 2018

I don't think we should use + here since we don't want to parse everything as +html as HTML (as we do with +xml) and we don't want to allow navigating to these resources either. Navigating to them should download them or result in some special view.

text/html-module and .htmlm (after .jsm) seem most reasonable.

@dandclark
Copy link
Contributor

I still want to question whether this is a necessary change to make.

@annevk said:

"It seems navigating directly to an HTML module should not result in rendering and script execution. A download seems safer."

Is there a security issue? What is the threat?

If you want the module to be downloaded when navigated to directly, it could be served with a content-disposition header, which will be ignored when loaded as a module.

If you want to differentiate an HTML page's behavior based on whether it's loaded as an HTML module or stand-alone page, you can feature detect whether you are executing a script module as part of an HTML module using import.meta.document. Maybe there are use cases like displaying a module's documentation if it's requested as a top-level page.

In terms of prior art… fetching module scripts today requires that the mime-type match the existing JS mime-types. Why does an HTML module need a new one?
https://html.spec.whatwg.org/multipage/webappapis.html#fetch-a-single-module-script

Additionally, a new mime-type comes with costs to roll out the feature in that servers must be configured to map extensions to new mime-types.

These are some arguments against a new mime-type; can someone articulate the arguments in favor of a new one?

@annevk
Copy link
Collaborator Author

annevk commented Jan 31, 2019

The reason is that the processing model is vastly different. So directly navigating to the page might lead to some exploit.

E.g., elsewhere there was an argument that CSP would not need to apply. So if servers don't send CSP headers for these resources, problem... Etc.

@mildred
Copy link

mildred commented Jan 31, 2019

The reason is that the processing model is vastly different. So directly navigating to the page might lead to some exploit.

if a new top level element is required #752 (everything wrapper under <htmlmodule>), then the user-agent can ignore the module when directly navigating to it.

@annevk
Copy link
Collaborator Author

annevk commented Jan 31, 2019

If we want to reuse the HTML parser (and it seems like we do) a new top-level element is not an option.

@ExE-Boss
Copy link

ExE-Boss commented Jan 31, 2019 •
edited
Loading

But the HTML parser is also used for fragments, which don’t contain the <html>, <head> and <body> elements by default.

@BigBlueHat
Copy link

Maybe HTML modules MUST be fragments?

That would seem to map to the "single file" Web Component styles frequently used, but also address @tomalec's SPA use case (where sub-content is pulled into an SPA via HTML imports/modules).

@annevk annevk mentioned this issue Feb 14, 2019
Merged
@annevk annevk mentioned this issue Apr 23, 2019
Open
@Malvoz Malvoz mentioned this issue Jul 14, 2020
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
modules
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
7 participants
@tomalec @mildred @BigBlueHat @rniwa @annevk @dandclark @ExE-Boss