Redesign and refactor HTTP API's static file handling

The way HTTP API resources handle static files could be improved. Here is a list of issues to be addressed over time.

public routeStaticDirectory(
    method: string,
    path: string,
    filePath: string,
    contentType?: string) {

• Remove the method parameter. Anything other than “GET” doesn’t make sense for serving static files. (done in #26)
• Provide a way to upload entire directories, not needing explicit file-by-file declarations.
• Enable regular expression captures, e.g. “/static/([^/]+)/(.)+” -> “/$1/$2”
• Compare the design with Rest, Heroku, GAE, and other providers. Ensure we have feature parity. (See #4 for reference.)

Related issues:

• Support “folders” in the Lumi layer (https://github.com/pulumi/pulumi-fabric/issues/240)

[joeduffy]

Note that this last bullet is https://github.com/pulumi/pulumi-fabric/issues/153.

[lukehoban]

If you are suggesting that the static routing do something unique to knowing what files are on disk in determining what routes it will wire up - that’s possible - but even further away from Express semantics (where static is just middleware, and has no direct visibility in routing). And it doesn’t generalize at all into other routing.

I think we should continue the discussion on #4 with a proposal on what it would mean to take a fundamentally different approach here that aligns deeply with Express. I’m very open to that - I’d feel much better if I had a high confidence approach that would get us there. And I don’t believe it’s impossible - I just don’t yet know how to do it yet. I’ll plan to do another pass at a strategy we could take that would get closer to Express semantics as part of 0.9.