HttpFileService could provide more options related to trailing slash

[anuraaga]

I was trying to clean up code using the new file service capabilities (removing hacky path mapping to redirect everything to index.html for example) but found I can't remove all my hacks since we use "clean URLs" without a trailing slash to read index.html for that page. The current HttpFileService will read index.html for requests that end with / but not otherwise. Adding an option to HttpFileServiceBuilder that allows URLs without an extension to have slash added before resolving the file would make this simpler.

For reference, firebase's related setting
https://firebase.google.com/docs/hosting/full-config#control_trailing_slashes

[trustin]

Sounds like a good idea. Interested in sending a pull request?

[anuraaga]

@trustin I'm thinking of working on this now. I realized, the current HttpFileService already has a branch for where the path doesn't end with slash but the index exists, and it uses an HTTP redirect. Just wondering, is this a convention from other servers? It's a bit surprising behavior to me and I'm wondering if I can't just make it not use an HTTP redirect without adding a new option.

[trustin]

@anuraaga I didn't think much about redirection, but HttpServerHandler also makes use of redirection when received a path that does not end with slash:

https://github.com/line/armeria/blob/master/core/src/main/java/com/linecorp/armeria/server/HttpServerHandler.java#L461-L483

I guess I just wanted to make them consistent, but I think we can change that if other servers behave differently.

[anuraaga]

From what I've seen, I think most servers will give 404 and both of us may be being too nice to try to infer a response :)

I guess it's common for HttpFileService to be serving a static SPA, and redirecting the URL will often break those since they have their own routing config - I myself have been confused when this happened to me in the past. But consistency with HttpServerHandler seems more important. In that case, for the behavior in this issue it seems good to add a flag so users opt-in to behavior that does not follow HttpServerHandler's.

I'm also wondering though if we need to have a server-level flag that controls whether empty is redirected to slash, or slash is redirected to empty? I guess it's similar to the trailingSlash config parameter in the firebase config I linked, though that config option I've found to be a bit silly since it's happy to redirect index.js to index.js/ which I don't think anyone would ever want...

[trustin]

nginx and Apache HTTPd at least seem to send a redirect response when a client sent a request to a directory without a trailing slash (empty-to-slash), which matches the current HttpServerHandler behavior. I guess this kind of redirection is common for directories.

However, they indeed don't send a redirect when showing an index file. That being said, I guess we can:

• keep the current HttpServerHandler behavior as-is
• make HttpFileService redirect for empty-to-slash cases while serving an index file without redirection

Additionally, we might want to add some configuration property to Server, like TrailingSlashPolicy if we need more flexibility?

[anuraaga]

Thanks for checking the behavior! It sounds like they follow armeria's current behavior then. I guess I'll add a flag, and it's basically similar to doing this sort of config in nginx when needing slash-less URLs - https://stackoverflow.com/a/31189870