Response Content-Types #198
Comments
|
Hey there. Thanks for the report. Do you mind me asking what type of files these are and what the expected MIME type is? We are currently using async-std/tide for the server. Is this a know issue upstream? |
|
Well, in case of font-awesome for example firefox sends this exact accept header: application/font-woff2;q=1.0,application/font-woff;q=0.9,/;q=0.8. Firefox seems to not mind whether the file is woff2, woff or ttf, the header seems to always be the same. Webpack for example (don't know the actual underlying implementation) doesn't include any content-type in its responses. Trunk on the other hand serves them with content-type: text/html;charset=utf-8. I've found the issue 27 on tide. Not quite sure as to how much this relates to the Problem though. |
When you look at the actual content, do you get the fonts or do you get the content of |
|
Ahh, ok. Thats actually the Problem, thanks. Maybe we could change that to reply with a 404 then? |
|
I think this is a duplicate of #192 |
|
Makes sense |
|
Since the other issue got closed, I suppose it makes sense to continue here. Would it be sensible to only fall back to serving |
|
@WorldSEnder that's not a bad idea. Perhaps we could actually evaluate the request's Thoughts? |
|
I find the idea very appealing. They are discussing content negotiation on the other thread there though maybe one could study that for a bit beforehand and/or even join in. |
|
I'm nearly finished up with #202, and I decided to just go ahead and fix this issue as part of the updated. Seems to be working quite nicely now. Should have that code in master soon. |
Stable dist serving with proper index.html fallback after evaluating accept header. Add to changelog: - [x] async everything in tools. - [x] add a subcommand to clean cached tools (wasm-bindgen & wasm-opt). - [x] resolves #198 TODO: - [ ] ensure the shutdown broadcaster is closed as soon as a signal is received, else ^C too early will cause the signal to be missed and other parts of the app which have not initialized will not see the drop.
Stable dist serving with proper index.html fallback after evaluating accept header. Add to changelog: - [x] async everything in tools. - [x] add a subcommand to clean cached tools (wasm-bindgen & wasm-opt). - [x] resolves #198 TODO: - [ ] ensure the shutdown broadcaster is closed as soon as a signal is received, else ^C too early will cause the signal to be missed and other parts of the app which have not initialized will not see the drop.
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Add to changelog: - [x] all download utils have been make fully async. - [x] added a subcommand to clean cached tools (wasm-bindgen & wasm-opt). This may be useful if there are ever issues with old tools which need to be removed. - [x] resolves #198 (more intelligent 404s & index.html). Todo: - [ ] ensure the shutdown broadcaster is closed as soon as a signal is received, else ^C too early will cause the signal to be missed and other parts of the app which have not initialized will not see the drop.
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Add to changelog: - all download utils have been make fully async. - added a subcommand to clean cached tools (wasm-bindgen & wasm-opt). This may be useful if there are ever issues with old tools which need to be removed. - resolves #198 (more intelligent 404s & index.html). - cut over to tokio 1.x. - cut over to axum for web server. Todo: - [ ] ensure the shutdown broadcaster is closed as soon as a signal is received, else ^C too early will cause the signal to be missed and other parts of the app which have not initialized will not see the drop.
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #202 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #202 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #202 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #202 closes #209
Cut over to [email protected]. Much more simple interface, and works quite nicely with the async ecosystem. Cut over to axum for web server. Much better! The updated server stack is now more intelligently handling 404s. This is a common issue where users may end up making a request for some non-html static asset, but they get their path slightly wrong and are served the index.html instead of a 404. This typically results in users struggling to find the problem, and often times users have opened issues in GH. This updated algorithm will now evaluate 404s more closely and only respond with the index.html when the `accept` header allows for text/html or */*. Added an example demonstrating all proxy functionality. closes #198 closes #202 closes #209
|
trunk still serves the index.html for me instead of a 404 when there is a js esm module included via wasm_bindgen which in turn imports another esm module which is not directly referenced from Rust. Took some time to figure out that I have to explicitely import that module from Rust as well (although I am not using it directly from the Rust side). |
|
Feels like an issue with wasmbindgen, as that's the tool which collects all the snippets. Trunk just scoops up what wasmbindgen collects. |
I've added a few static files to my project that I would like to serve with trunk.
Therefore I added them to my template file with
rel="copy-dir"but they get served with the wrong mime-type.Which leads to firefox rejecting them to due a failing sanitizer check.
Can we fix this? What would be the preferred strategy to do so?
The text was updated successfully, but these errors were encountered: