Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add static file server #4240

Closed
Amenocy opened this issue Nov 28, 2018 · 4 comments
Closed

Add static file server #4240

Amenocy opened this issue Nov 28, 2018 · 4 comments

Comments

@Amenocy
Copy link

@Amenocy Amenocy commented Nov 28, 2018

Do you want to request a feature or report a bug?

Feature

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.
similar to nginx config:

   root /home/myapp;

    index index.html index.htm index.nginx-debian.html;

    server_name _;

    location /public/ {
            alias /home/myapp/public/;
    }

    location / {
            proxy_pass http://IPADRESSOFNODEJSSERVER:8080;
   }
@kachkaev

This comment has been minimized.

Copy link
Contributor

@kachkaev kachkaev commented Nov 28, 2018

Why not to just spin up an nginx container behind traefik? :)

@Amenocy

This comment has been minimized.

Copy link
Author

@Amenocy Amenocy commented Nov 29, 2018

it is very simple to do with go.lang and I think we don't need to add more complexity and risk of nginx :)

@kachkaev

This comment has been minimized.

Copy link
Contributor

@kachkaev kachkaev commented Nov 29, 2018

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.

@dduportal

This comment has been minimized.

Copy link
Contributor

@dduportal dduportal commented Nov 29, 2018

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.