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

Elm reactor doesn't serve large files correctly #1972

Open
mgree opened this issue Aug 20, 2019 · 7 comments
Open

Elm reactor doesn't serve large files correctly #1972

mgree opened this issue Aug 20, 2019 · 7 comments

Comments

@mgree
Copy link

mgree commented Aug 20, 2019

Quick Summary: elm reactor doesn't properly serve a wasm file (magic numbers corrupted; downloaded binary files differ in size).

Seems to be the same as elm-lang/elm-reactor#214.

SSCCE

Put z3w.wasm from https://github.com/cpitclaudel/z3.wasm/releases/tag/v0.1 in a directory and serve it from elm reactor. Download z3w.wasm---the file sizes differ. Doing the same procedure with python -m http.server yields a file of correct size.

$ ls -al | grep z3w.wasm
-rw-r--r--@  1 mgree  staff  18267869 Aug 20 14:59 elm.z3w.wasm
-rw-r--r--@  1 mgree  staff  18267216 Aug 20 14:42 py.z3w.wasm
-rw-r--r--@  1 mgree  staff  18267216 Aug 20 14:42 z3w.wasm
  • Elm: 0.19.0
  • Browser: Firefox 68.0.1 and Chrome 76.0.3809.100
  • Operating System: OS X 10.13.6

Probable fix

The reactor seems to be sending the wasm file as text/html rather than application/octet-stream:

$ wget -O elm.z3w.wasm http://localhost:8000/app/z3w.wasm
--2019-08-20 14:59:51--  http://localhost:8000/app/z3w.wasm
Resolving localhost (localhost)... 127.0.0.1, ::1, fe80::1
Connecting to localhost (localhost)|127.0.0.1|:8000... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: ‘elm.z3w.wasm’

I suspect that text munging (e.g., null bytes, newlines, carriage returns, etc.) is the source of the problem. Doing better Content-Type inference would help (see also elm-lang/elm-reactor#217).
@Anton-4
Copy link

Anton-4 commented Jan 28, 2020

I have a similar problem with a csv file. My csv file content is wrapped with:

<!DOCTYPE HTML>
<html>

<head>
	<meta charset="UTF-8">
	<title>~/data/category-brands.csv</title>
	<style type="text/css">
		@import url(/_elm/source-code-pro.ttf);

		html,
		head,
		body,
		pre {
			margin: 0;
			height: 100%;
		}

		body {
			font-family: "Source Code Pro", monospace;
		}
	</style>
	<link type="text/css" rel="stylesheet"
		href="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/styles/default.min.css">
	<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/9.3.0/highlight.min.js"></script>
	<script>
		if (hljs) { hljs.initHighlightingOnLoad(); }
	</script>
</head>

<body style="background-color: #F0F0F0;">
    <pre><code>
        ...csv file content
    </code></pre>
</body>

</html>

I suspect adding , ".csv" ==> "text/csv" to the mimeTypeDict in this reactor backend file could solve the problem. I might try to fix this myself next week.

@mgree
Copy link
Author

mgree commented Jan 30, 2020

Nice! I suspect that the ideal approach here would either:

  1. allow us to specify local additions/overrides for that mimeTypeDict; or
  2. use OS mimetype information.
    The former seems like an easy patch, even though the latter is probably a better bet for what the reactor is used for.

@Anton-4
Copy link

Anton-4 commented Feb 3, 2020

Thanks for the suggestions. Using OS mimetype information on windows and proper mime guessing will require some work, this python example could be a good guide. I'm going to start out by simply adding to the dict.

@mgree
Copy link
Author

mgree commented Feb 3, 2020

Awesome! If you're making the PR, could you add , ".wasm" ==> "application/wasm" too? :)

@Anton-4
Copy link

Anton-4 commented Feb 4, 2020

Sure :) . Just to double check; in your first comment you said it needed to be "application/octet-stream" but it needs to be "application/wasm"?

@mgree
Copy link
Author

mgree commented Feb 4, 2020

Honestly, any application type will do, since that's what should disable CRLF and null-byte munging. I think the application/wasm is more standard these days. Thank you! :)

Also: if they're open to adding a new dependency, https://hackage.haskell.org/package/mime-types seems like it would work just fine as a platform-independent, extension-based approach.

@Anton-4
Copy link

Anton-4 commented Feb 5, 2020

Interesting, excellent find!

Anton-4 added a commit to Anton-4/compiler that referenced this issue Feb 7, 2020
@Anton-4
Added many more MIME types, should fix some file contents being erron…
698de76 
…eously wrapped in HTML when using reactor elm#1972
@Anton-4 Anton-4 mentioned this issue Feb 7, 2020
Open
@Anton-4 Anton-4 mentioned this issue Jun 9, 2020
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mgree @Anton-4