Skip to content

Hard-code some MIME types to work around broken Windows setups #3120

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

Closed
wchargin opened this issue Jan 8, 2020 · 4 comments
Closed

Hard-code some MIME types to work around broken Windows setups #3120

wchargin opened this issue Jan 8, 2020 · 4 comments

Comments

@wchargin
Copy link
Contributor

wchargin commented Jan 8, 2020

Context:
#2771 (comment)

TL;DR: We use mimetypes.guess_type from the Python standard library to
guess MIME types, but on Windows any application can corrupt the backing
registry, and it appears that some popular programs (maybe Visual
Studio) do just that. This breaks TensorBoard for users because we send
text/plain for scripts, blocking execution.

Proposed fix: Either (a) at TensorBoard main time, patch the
mimetypes registry to hard-code fixes for .js and any other
known-bad extensions (should be possible with mimetypes.add_type, no
monkey patching required), or (b) find all places that call guess_type
and extract a common helper function that handles the known-bad cases
itself and delegates to mimetypes for the rest. Or something to that
effect.

@wchargin
Copy link
Contributor Author

wchargin commented Jan 8, 2020

User reports: #2771, #3077, #3117.

wchargin added a commit that referenced this issue Jan 10, 2020
Summary:
The standard library’s `mimetypes.guess_types` can give incorrect
results on Windows, because arbitrary programs can influence its
behavior by writing to the registry. This can be worked around by
reinstating the correct MIME types with `mimetypes.add_type`, as in this
patch. Fixes #3120.

Test Plan:
To check that this patch works at all on Windows, edited the registry to
add a bad content type:

```
reg add HKCR\.js /v "Content Type" /d application/x-testing-123
```

…then verified that before this change, `mimetypes.guess_type("foo.js")`
gives the wrong value and TensorBoard does not render properly (strict
MIME type checking error in Chrome, as expected), whereas after this
change `mimetypes.guess_type("foo.js")` gives the correct value and
TensorBoard returns the correct content type in its JavaScript
responses. TensorBoard still does not render on Windows due to unrelated
errors in the debugger plugin.

To check that this set of patches is sufficient, `git grep guess_type`
shows call sites only in `core_plugin` and `projector_plugin`. The
former takes file names from `webfiles.zip`, which has only `html`,
`js`, and `woff2` files (plus a `LICENSE`). The latter has a fixed set
of inputs with extensions `html` and `js`.

wchargin-branch: windows-explicit-mime
@lamarqua
Copy link

lamarqua commented Feb 2, 2020

Did you ever report this issue upstream to the Python project? FWIW I encountered this issue in a completely unrelated context and I will probably mention this workaround (and other related discussions) as a reason for Python to fix this behaviour in the standard library.

@wchargin
Copy link
Contributor Author

wchargin commented Feb 2, 2020

Unfortunately, as far as I can tell, this is by design. See, for
instance, Python bug 10551, wherein multiple Python committers
express the opinion that they’re “not surprised” that Windows is “broken
with respect to MIME types and with respect to its security model” but
that this does not merit a fix because it was an intentional “new
feature in 2.7”.

This same bug is hitting other prominent projects, like Flask,
so I agree that it would be great if the standard library could do
something to fix it, but it doesn’t sound like that’s going to happen.

@lamarqua
Copy link

lamarqua commented Feb 2, 2020

Thanks for the reply. I'll try to make a case to review the behaviour of the mimetype modules.

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

No branches or pull requests

2 participants