Dodrio JS utility import responds with mime type text/html about trunk HOT 11 CLOSED

Should be working like a champ now! Let me know if it is not.

from trunk.

Huh that seems odd but you are correct. I would expect a 404 in that case, or a redirect. Thanks for saving me some time!

from trunk.

@nkconnor as of Trunk 0.4.0 (just recently released) we are now handling JS snippets from wasm-bindgen properly, and your above example related to dodrio should now work as-is. Let me know if you run into any issues.

I would like to keep this issue open for now, as our discussion related to client-side routes vs server-side routes is quite good and I am planning on building a better solution for this in 0.5.0.

from trunk.

Request URL: http://localhost:8080/snippets/dodrio-f9c304c889d98e4f/js/change-list-interpreter.js
Request Method: GET
Status Code: 200 OK
Remote Address: 127.0.0.1:8080
Referrer Policy: no-referrer-when-downgrade

Response Headers
content-length: 222
content-type: text/html;charset=utf-8
date: Tue, 01 Sep 2020 13:51:59 GMT

Request Headers
Accept: /
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: no-cache
Connection: keep-alive
Cookie: io=4pyCjFi3fjX5JioRAAAV
Host: localhost:8080
Origin: http://localhost:8080
Pragma: no-cache
Referer: http://localhost:8080/index-c2c5851d339f524.js
Sec-Fetch-Dest: script
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/83.0.4103.116 Safari/537.36

from trunk.

Maybe it got removed.. http-rs/tide@64525d9.

It looks like the new mime type is generated from this crate https://github.com/http-rs/http-types here https://github.com/http-rs/http-types/blob/main/src/body.rs#L374

from trunk.

Ok, based on reviewing the above content you've posted, the server is returning the index.html file. This is because the file you are requesting probably does not exist in your dist dir, so the server falls-back to serving the index.html file (which is where the content-type: text/html;charset=utf-8 response header is coming from.

So, I suppose your next question will be: how can I serve the JS file? I would recommend using the <link rel="trunk-dist" href="snippets/dodrio-f9c304c889d98e4f/js/change-list-interpreter.js"/> described in Trunk README here. NOTE: you will need to make sure that the path to the JS file is correct from your source HTML file.

Let me know if that helps.

from trunk.

https://github.com/thedodd/trunk/blob/master/src/cmd/serve.rs#L114

is that done explicitly here, I guess? seems like this might trip people up further down the road

from trunk.

So, I suppose your next question will be: how can I serve the JS file? I would recommend using the described in Trunk README here. NOTE: you will need to make sure that the path to the JS file is correct from your source HTML file.

Also, FWIW this import is defined by an external crate https://github.com/fitzgen/dodrio

from trunk.

is that done explicitly here, I guess?

That is correct. If we don't serve the index.html, then client side routing will not work on a fresh request; i.e., if you have a client side route /ui/services/xyz/details, if you try to request that page from the server and it returns a 404, that would be incorrect behavior, because that is not supposed to be a resource on the server, it is supposed to be client side route. As such, we have to serve the index.html as a fallback.

In a production context, your server should be configured to differentiate between client side routes and requests for other resources. Using a /ui/ URI prefix is a great way to do that. In Trunk, we can not safely make that assumption.

We could add a CLI flag similar to --public-url except specifically for client side routes. Maybe something like --client-prefix. If we had that, then we could serve the index.html as a fallback for anything under the client prefix, and then serve a 404 for anything outside of the client prefix which is not found.

@nkconnor thoughts?

from trunk.

I see what you mean. My experience level here is pretty low so I might not be able to add much.

I wonder what other tools are doing to handle the same problem. Are those Sec-Fetch headers reliable enough that we could differentiate Sec-Fetch: document = client side routing, for example.

from trunk.

I think that overall this is pretty closely related to some of the work which needs to be done over in #29 . I'll create a new meta issue which will encapsulate the feature request here, as well as the feature request over there in #29.

from trunk.