Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Do you want to request a feature or report a bug?
What did you expect to see?
static file server , comparable with nginx , so we can serve our static files in node.js applications more faster and cpu safe.
Once a simple file server is implemented, someone will discover an edge case it does not cover. They will create an issue that will eventually need to be solved under the pressure of thumbs up reactions. Shortly afterwards, a new edge case will be found and the cycle will repeat. The community will end up with a bloated version of traefik that can do 80% of what nginx is needed for, but still lacking several critical features for certain audiences.
At the moment there exists a simple rule: Want to serve files? Add a container with nginx and expose it to traefik.
Crossing the borderline and implementing a simple file server will turn the rule into something like: Want to serve files? You can use traefik if you don’t need to restrict symlink following and if you don’t need to configure cache control for path regexp. Oh and also not when path overriding based on an HTTP header is necessary. There are 10 other cases traefik does not work well with, but I can’t remember them now.
I strongly prefer the first option as it will never require a painful shift from one tool to another following a tiny tweak in how the static content needs to be served. The more focused the tools are, the easier they are in practice.
Hi @Amenocy, thank you for your interest in the project, and for your proposal.
The Traefik project aims to follow the "Separation of Concerns" principles. Its core is to be a reverse-proxy, which role is to route requests.
One of the values behind Traefik is to be simple to use, which requires to focus on the reverse-proxy function.
In a world where containers and VMs are able to start in a few seconds, the overhead of starting a web server for serving files is a few orders of magnitude smaller than having a "one size fit all" tool which is bloated and hard to maintain or even release.
As explained by @kachkaev, the amount of unwanted behaviours caused by packing too many features into Traefik increases the risk to have an unstable software over time.
A static file server can be a tedious system to build and maintain: serving files under a peak of requests with blocking I/Os, serving heavy files requires chunking, not even mentioning the caching feature.
This is why we are going to decline this feature as of today.
Please feel free to contribute by proposing design implementations, to discuss this with the maintainers if you do not agree, keeping in mind that such a feature requires commitment from the sender to ensure it will be maintained over time.