allow different cache times for different urls

[lanterndev]

Currently http-server allows you to configure the "cache-control: max-age" value for all urls. But often you want a short max-age for e.g. /{index.html} and a long max-age for urls to versioned assets like /styles/f35ac111.main.css.

Would you accept a patch to allow specifying different max-ages for different urls? (This could be implemented most generally by matching the request url against one or more configurable regexes which map to corresponding max-ages, for instance. But if it's simpler, just giving the long cache time to everything that isn't in the root directory, or every asset with a name like a1b2c3d4.filename.ext would probably work for many use cases.)

[kilianc]

+1 on this. Multiple -c args should be supported. I would be ok with just not setting cache for .html files but since the implementation is very simple we could probably aim to have something like:

$ http-server -c31536000:**/*.css -c-1:**/*.html

?

[kilianc]

I would be ok PRing to this if a PR is welcome.

[derhuerst]

I'm not sure this is possible in the scope of http-server.

First of all, "http-server is a simple […] command-line http server". I think it's sad that JS projects on GitHub trying to keep things simple (and leave advanced use cases to others) are constantly made more complex. But that's just MHO.

Second, http-server is just a layer on top of ecstatic, which seems to allow only one caching duration.

[kilianc]

Second, http-server is just a layer on top of ecstatic, which seems to allow only one caching duration.

@derhuerst the issue on ecstatic is right here in this thread, with a merged PR to add support to custom caching.

First of all, "http-server is a simple […] command-line http server". I think it's sad that JS projects on GitHub trying to keep things simple (and leave advanced use cases to others) are constantly made more complex. But that's just MHO.

It still seems reasonable to me that a static assets server has advanced support for caching. Adding this has not impact on who's not gonna have a use for multiple caching values.

Also, what do you think is going to happen if this doesn't land? People are going to use ecstatic or connect and roll out their own server.

[derhuerst]

@kilianc

Second, http-server is just a layer on top of ecstatic, which seems to allow only one caching duration.

@derhuerst the issue on ecstatic is right here in this thread, with a merged PR to add support to custom caching.

Sorry, didn't see this.

It still seems reasonable to me that a static assets server has advanced support for caching. Adding this has not impact on who's not gonna have a use for multiple caching values.

Also, what do you think is going to happen if this doesn't land? People are going to use ecstatic or connect and roll out their own server.

I've been following the http-server's issues for quite a while and noticed a situation similar to many other FOSS projects: In the beginning, the software is small and simple. It has a narrow & shallow dependency graph. It does one thing and does it well. 😁

After a while, more and more tiny features get added, which all support a completely valid and reasonable use case. The software gets bigger and bigger, harder to maintain, etc. In the end, the tool will end up like curl, rsync or httpie, which all do a dozen of things very well. One has to google for the correct usage or best patterns, another StackOverflow tag emerges because of the number of questions regarding the usage. 😄

This is all not really a problem, for a lot of feature requests however, it just seems like http-server is – as it is described in the readme – not suitable for this kind of pluggable features.

To move on from general panicking, I see two specific features being requested quite often.

A web server with CLI-pluggable modules is needed. Something like express, ecstatic or koa, but configurable from the command line. Different features could be used more easily than setting up a JS file, just by passing flags. One would get the benefits of the CLI (aliasing, autocompletion, familiar syntax) "for free". Requested features that go in this direction: #35, #63, #83, #110, #139, #201, #67.

Second, a comfortable way to serve single page applications. This might become a possible duplicate of spa-server, spaserve and devserve. Issues regarding this: #69 and #95, #7, #80, #254.

Please keep in mind this is just my opinion and I'm not sure in what direction @indexzero wants to go with this project.

[kilianc]

@derhuerst thanks for taking the time to write back.

I disagree. A A web server with CLI-pluggable modules is a bad idea. At that point I might require htt-server as a library and handle the CLI myself. I still believe adding strong cache support is in the scope of a popular static assets server like this project. Let's hope this lands or I will end up rolling out another yet module for the wrong reasons.

Everything you said seems unrelated. Let's see what happens and leaver the politics out of it.

[derhuerst]

@kilianc

A "web server with CLI-pluggable modules" is a bad idea.

That is my personal opinion as well, just like I believe in small CLI projects (like what http-server has been like). But apparently (see the referenced issues) many people want a CLI HTTP server with a lot of features.

I still believe adding strong cache support is in the scope of a popular static assets server like this project.

I agree to this as it is phrased right now. But I also think that a detailed cache control should not be part of a small-scope module like this.

Everything you said seems unrelated.

It seems unrelated as it is a lot more general, because I tried to sum up what my impression of the feature requests of http-server is.

[houston3]

Created a pull request for this #404

[thornjad]

So, I am inclined to agree with @derhuerst and say this is not really in scope of http-server since it feels like creeping. However, ecstatic does now accept a function to be passed, and as a wrapper around ecstatic, it entirely makes sense to pass this through as in #404.