It requires js to build the index. Therefore, it's not useable for rustdoc since it'll require extra dependencies. But thanks for the info!
Stork creator (who admittedly knows nothing about the Rustdoc build system) here. Totally fine if you don't want to keep pulling this thread, but I wanted to clarify that building the index is a completely native, non-JS process; it's all contained within the executable.
The frontend search being in JS isn't an issue.
I was misled by the README when reading " brew install". By re-reading it, it's not required. Strange to require brew to download rust.
I should go ahead and note one other issue with using wasm:
At least on Windows, you cannot run wasm from a webpage loaded by opening the HTML directly from the filesystem into your browser. (Which currently works and is what
cargo doc --open does.) You need to run an actual server and connect to that instead. The reason is because wasm must be loaded with a correct MIME type of
application/wasm, and the filesystem does not do that.
This may be a browser thing, but I'm not sure who's at fault here or if this is by design, tbh. Browsers could skip the MIME type check for
file:// URIs if they wanted to.
It's a very important detail, thanks a lot @CAD97! Yes, it needs to be able to run without server.
That's a really dumb problem to have. =/
It's been, what, two years since wasm MVP shipped?
It's not just a Windows thing. Trying to load a
webpacked site from disk in Safari gives
[Error] Cross origin requests are only supported for HTTP. [Error] Fetch API cannot load file:///Users/nemo157/sources/cbor.nemo157.com/dist/048579358ee0369cf25b.module.wasm due to access control checks.
and in Firefox
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at file:///Users/nemo157/sources/cbor.nemo157.com/dist/048579358ee0369cf25b.module.wasm. (Reason: CORS request not http).
file:// urls either:
To get modules to work correctly in a browser, you need to make sure that your server is serving them with a
You need to pay attention to local testing — if you try to load the HTML file locally (i.e. with a
So, unless something changes about the
file:// security context it doesn't look like serverless (no, not that serverless) WASM is going to be a thing
I guess it would work, but that's a really inefficient way of storing and delivering wasm. It'd be nice to have a more idiomatic alternative.
Strange to require brew to download rust.
Ha! When I have some time, I'll put it in Cargo. My intended audience (at least at the start of the project) was web developers over Rustaceans, though it might be time for that to change
@jameslittle230 the more important thing is that rustdoc locally generated documentation can be used offline (I personally would be ok with having
cargo doc --open spawn a little web server to get around
file:// issues, but my opinion doesn't matter much).
(EDIT: gah, why can't I retarget which post this is a reply to)
I see, if that's the case then Stork probably isn't a good fit for now.
Thanks for considering and chatting!
Where should I go to find out why these restrictions apply to
I suppose it'd be a big security issue if you could, from an
https:// URI, read an arbitrary
file:// URI, especially if you're getting raw bytes (like via WASM loading APIs) rather than "just" attempting to interpret the file as HTML, CSS, or JS. But I would think that
file:// requests could (should?) be considered same-origin for CORS.
Similarly, it might make sense to turn off strict MIME checking for
file:// URIs, since the fs doesn't (can't?) set a MIME type. Or maybe have the browser set the MIME type for files via extension, the same way a file serving web server would.
I understand that "load this through
py -m http.server or similar isn't that big of a requirement for developers... except when it is, like for
cargo doc --open/
file:// has just been on the way out for a long time; it's been hampered in various browsers for various reasons for years. It's also not consistent between browsers what restrictions exist. It's not a heavily used feature and so it's often neglected, or fixes come in that (IMHO) are a bit too heavy handed, because it doesn't really matter (or so it seems to me, anyway).
The issue then is, if I can get you to download and open an HTML file, I can make it send me any file on your computer. (Or if it's restricted to files within the same directory, I can still read any file in your Downloads folder, or your Desktop, or wherever you save it.)
"Don't open HTML files from untrusted sources" is good advice, of course, but browser makers still consider this too big a risk to leave up to caveat user. (I believe there are already risks of this sort, but the goal is to reduce these over time rather than increase them.)
CVE-2019-11730 makes mention of this being exploited in a "popular Android messaging app".
That doesn't seem unreasonable to me as a workaround. (Though I also think it's worth having a conversation with browser vendors about MIME types and WebAssembly.)
Well, except for the fact that
stork.wasm is 222kB currently, so that'd be 300kB of base64 in your JS.
At the very least, you'd want a "
file:// hack" mode and a "real server" mode.
So I think the path forward would be to get a WASM API that works for
file:// URIs. And probably, that's letting
<script type="module"> work on
file:// URIs, and the planned
import * as wasm from 'file.wasm'; for modules to also work for
file:// URIs. And that "probably" is "just" having browsers assign MIME types to
file:// URIs based on filetype.
And hopefully CORS doesn't get in the way of module imports for
file:// URIs, though I will admit that allowing reading arbitrary files is almost definitely a no-no.
What I've always wanted is an offline:// scheme which works like file:// with relaxed same-origin rules but also forbids all network access.