Add support for static HTTP response headers

[jimlawhorn]

Add --headers argument support and update doco

[BigBlueHat]

Thanks for sending in a PR!

Given that this will add the same header to ever request, what's the use case for this?

[jimlawhorn]

My specific use case was for app development. I'm using http-server to test/develop API consumption against. I have vendor provided apps that provide some information in the headers that are necessary to consume the response data correctly. Rather than go through the process of setting up the data in the system (which I can't necessarily do), I just have saved responses that I serve up with http-server. I had been using Fiddler Autoresponder to inject the headers and http-server, but it made more sense to me to just add it as an option to the http-server.

From a non-development standpoint, I didn't see any way to set the Access-Control-Allow-Methods, Content-Security-Policy, or some of the more common standard X-* headers. I don't know if anyone is using for production settings, but I figured if there was a --cors option, someone is at least testing with it. These are all common headers that we have in the web server, rather than code.

[BigBlueHat]

Completely agree that header customization is needed, but the scenarios where one would add the same header to all requests seem few. Take a look at #360 for something I'd like to get added at some point. It would allow per-file (at least) header customization via a .headers file (which is a convention...sadly not yet a standard) used by other projects. Your thoughts and help here would be most welcome!

[jimlawhorn]

The .headers idea is significantly better in a lot of ways and if done correctly, would be easy enough to use for static headers (like I need). Unless you think there's value to this PR in addition to that functionality, I'm going to close this PR and take a crack at the headers idea.

[BigBlueHat]

FWIW, it looks like the underlying node-ecstatic does support a --H option for site-wide header usage: https://github.com/jfhbrook/node-ecstatic#optsheaders

Consequently, it probably makes sense to expose that option via http-server after all.

I'd still love .headers made available (and perhaps upstreamed to node-ecstatic if they're interested).

Balancing flexibility and focus is tricky. Input welcome!

[numical]

+1 from me.
My use case is using http-server in dev and local testing to emulate a front-end proxy that is adding custom HTTP headers that my client-side app reads.

[BigBlueHat]

@numical would you like to take a crack at a PR for #360?

For this PR specifically, I'd like to rename the --headers switch to match ecstatic's (and curl's) -H switch naming because it's shorter and more common among similar apps.

@jimlawhorn would you be up for tackling the above tweak?

[numical]

Cannot commit at the moment - sorry.
Struggling even to keep my projects up to date.
However, if I get a chance, will take a look. Just pls don't wait for me!

[numical]

@BigBlueHat - I have got as far as forking the repo and taking a look. Looks interesting if I can find the time! In the meantime could you accept this @jimlawhorn's current PR? It would satisfy my current needs.

[jimlawhorn]

I'm looking at updating the original PR.

[jimlawhorn]

@numical would you like to take a crack at a PR for #360?

For this PR specifically, I'd like to rename the --headers switch to match ecstatic's (and curl's) -H switch naming because it's shorter and more common among similar apps.

@jimlawhorn would you be up for tackling the above tweak?

Submitted updates for the static header options. I opened #460 a while ago for the dynamic headers. Not seen any feedback on it, but I'd love any comments.

[BigBlueHat]

@jimlawhorn this is looking good! Could you add some tests to handle the new feature?

Also, it might be good to make "H" the alias, so the code reads more clearly (i.e. argv.H looks odd...).

Thanks!

[thornjad]

Closing in favor of the simpler and older #282