Server returns response, not file about fly HOT 3 CLOSED

Hey there!

Does this reference example code we got wrong? I saw there are talks about that in Slack.

The first code sample you show will only serve index.html because, as you've figured out, it's hard-coded in there.

We provide basic functionality for people to arrange in whatever way they need to make things work for their use cases.

In your second example, that seems like what you're trying to do: for every request, check if the path is available as file. The response from this fetch could be a 404 if the file is not found.

If you're trying to load an image, then you're not setting the right content-type header though.

We strongly encourage people to write their own routing logic or use a package that can do that for them. Since there's only one "fetch" handler (that fly.http.respondWith callback), you need to have some form of dispatcher for the logic.

I think we should make that clearer, for sure.

As for your solution description:

All file url paths that are in .fly.yml should be overwritten and only return that file unless otherwise specified.

I'm not sure I understand it. Maybe we need an example app that serves files from pathnames as best it can.

This also makes me wonder if we should try to infer the content-type to avoid confusion and easy-to-make mistakes.

What's the problem you want to solve? I believe the functionality works as intended. We could use a better example for it though :)

from fly.

I'm not sure I understand it. Maybe we need an example app that serves files from pathnames as best it can.

This also makes me wonder if we should try to infer the content-type to avoid confusion and easy-to-make mistakes.

I think we could make a basic static site app that does both of these pretty quickly. It'll be especially useful when we have globbing.

from fly.

@jeromegn

I'm not sure I understand it. Maybe we need an example app that serves files from pathnames as best it can.

After thinking about it, this was not a great idea and I think it would probably create more issues than it would solve. Documentation is probably the best rout in order to help people understand how it is supposed to be used.

Another solution might be doing something similar to what express does and have something like this:

app.use(express.static('public'))

For inferring the content-type, I completely agree - this would be a great feature.

I am happy to write some documentation on how to serve files, I am just not sure where the best place to do that would be. Maybe in a wiki?

from fly.