I've looked into this and I don't think Deno.readFile() is sufficient to serve static resources. I also don't think it is sufficient to even be able to efficiently "proxy" content as well.

For serving static files, the current Deno APIs/logic that are needed:

• An efficient way to determine if the file exists or not. Currently using (await Deno.stat(path)).isFile)
• An efficient way to support Last-Modified headers. Currently using (await Deno.stat(path)).mtime)
• An efficient way to calculate and compare ETags, both weak and strong. Currently using the Deno.FileInfo returned from Deno.stat to determine if the file is larger than what I want to read into memory to be able to calculate the strong tag or reverting to mtime and size to calculate a weak one.
• A way to send a range. While some files are read into memory if they are "small" enough, there is logic to handle large files which requires a Deno.File and the ability to "seek" in the file, where I use a limited reader to read out the amount of bytes required.
• I also currently "stream" large bodies using the LimitedReader which implements the Deno.Reader and reads out of the Deno.File reader.
• This hints at the fact that I need to try to calculate headers before starting to read large files and I need to know if it is a large file before I open it.

With proxying of files, it is much better and easier to just stream the fetch() body in the response. Using Deno.readFile() would just be problematic for many reasons.