-
Notifications
You must be signed in to change notification settings - Fork 69
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
Link mime-type notes to issue 105 (re CSP) #119
Conversation
This incorporates the conclusion at the end of WICG#105 (comment) > We should probably not accept any JSON MIME type. based on the assumptions made by existing hosting providers and JSON-producing web services as to what can be safely hosted on origins that appear on CSP source white lists.
Per @Malvoz's observation: > It seems that the convention for MIME-type extensions would suggest > application/importmap+json rather than application/json+importmap > (src: https://www.iana.org/assignments/media-types/media-types.xhtml)
If ti has its own mime type, should it have its own extension as well? (I’m aware browsers wouldn’t pay attention to the extension) |
@ljharb Having a separate extension would not help security-wise. I'd be worried about this scenario:
It's been best practice to not host third-party content on a sensitive origin for some time, but increasing the set of Content-type values that existing applications may unintentionally attach to hosted content is a risk factor. |
@mikesamuel an extension is the typical way that servers decide which mime type to serve a file with; i'm not suggesting it would help security-wise, but i don't see how it'd hurt. (given that browsers would, just like with everything else, ignore the extension and only switch on mime type) |
Major frameworks fill in Content-type based on extension, so these are not orthogonal concerns. For example, the widely used send package uses extension checking. I believe that ends up being used to compute the mime-type for a lot of express apps, at least those that use serve-static.
I was trying to explain how in the scenario I just outlined. Was that not clear? Not convincing? I don't think it's a big enough problem to warrant not recommending an extension. |
Fair that it doesn’t need to be in scope for the PR :-) but no, your example doesn’t seem any less problematic to me than if it uses the json extension. |
@ljharb I don't think we disagree on any "... (should|must) ..." claims so unless you want me to expand on anything, have a great weekend. |
@ljharb |
Now that the actual specification (spec.bs) has become more solid, we can clean up some tentative notes, and delete most of spec.md. Closes #119 by including the appropriate explanatory text in the README, instead of in spec.md.
Now that the actual specification (spec.bs) has become more solid, we can clean up some tentative notes, and delete most of spec.md. Closes #119 by including the appropriate explanatory text in the README, instead of in spec.md.
Now that the actual specification (spec.bs) has become more solid, we can clean up some tentative notes, and delete most of spec.md. Closes WICG#119 by including the appropriate explanatory text in the README, instead of in spec.md.
@mikesamuel, Does this mean that "if a MIME type is accepted as a JSON, then it shouldn't be accepted as an import map (and vice versa)"? (Or just meant that "not all JSON MIME types should be accepted as import maps"?) |
This incorporates the conclusion at the end of #105 (comment)
based on the assumptions made by existing hosting providers and JSON-producing web services as to what can be safely hosted on origins that appear on CSP source white lists.