Added possibility to use reroutes

[SiXoS]

Added possibility to use reroutes. It works by specifying a JSON file with the -R parameter. The json file is a list which is looped through for each http request. It does a find-replace call on the url of the request with the defined reroute rules. If the url is changed, a log is printed (except if you are in silent mode). I have added the following simple reroute to the example in bublic:

[
   {
     "match": {"regexp":"/img/([a-z]+).png", "flags":"i"},
     "replace": "/img/$1_reroute.png"
   }
]

This will reroute all png images to /img/<original name>_reroute.png.

You can also chain the reroute by specifying abortOnMatch: false. For example, lets say that we want to move the reroute images to a different folder instead without changing the existing rule:

[
  {
    "match": {"regexp":"/img/([a-z]+).png", "flags":"i"},
    "replace": "/img/$1_reroute.png",
    "abortOnMatch": false
  },
  {
     "match": {"regexp":"/img/([a-z]+)_reroute.png", "flags":"i"},
     "replace": "/img/rerouted/$1.png"
  }
]

[SiXoS]

I'll fix the stylechecks immediately!

[brandonros]

Nice work man! What do you personally use this for?

[SiXoS]

I have a small typescript library which is a SPA. I'm using History to navigate. When I refresh the page I get 404 as that page doesn't exist. So I'm basically rerouting all non-static paths to index.html.

[BigBlueHat]

Rewriting URLs is great and potentially quite useful. However, I think #369 is probably a better (because simpler) for solving this History hacking scenario.

Additionally, while I think the URL rewriting could be quite useful for other reasons, I'd like to avoid creating a new JSON format for dealing with redirect URL encoding.

Lastly, I think a clearer use case (or two) for this would also be fabulous. If the default doc solves the History hacking situation, then we'll need another reason for possibly adding URL rewriting.

There's also some URL rewriting history laying about here that's probably worth a dig through--as well as ecstatic issues and such.

Thanks for proposing this idea! Let me know if #369 would fix your particular situation.

[BigBlueHat]

Oh. And tests. Of course. 😁

[SiXoS]

Yes, #369 would solve my problem and is a more straightforward solution.

You can also handle all failing requests with the fallback feature so I guess that is a better solution.

EDIT: Fits better with the general concept of this tool as well.

[BigBlueHat]

Thanks again for submitting this, @SiXoS. I'm going to close this for now (at least) until we get a few more things sorted out with some of the similar conversations going on. I'm not opposed to a rerouting system, but would like it to be as standards (or prevailing pattern) based as possible. Appreciate you starting this conversation, though!

[BigBlueHat]

I'd actually like to revisit the concept of a URL rewriter for this project. However, I'd like it to use some common rewriter format found in OpenAPI, CouchDB, or similar. It doesn't have to bee too painfully powerful, but some basic to/from handling could go along way--including solving for #369 issues without directly the Web. 😸

[SiXoS]

What about using the Firebase way? I would imagine a lot of people that uses this tool uses Firebase hosting and only uses it locally for development. It is very simple though. They could then use the same rules for the server and locally. Of course, this is just an assumption and it is very likely that I'm way off track.

[BigBlueHat]

@SiXoS nice find! It's quite similar to the CouchDB's rewrites, but I like the inclusion of headers, redirects, and rewrites in one place.

There's also a prevailing pattern in the OpenAPI spec (and similar) to use URI Templates for defining "changeable" parts of a URI. I built a little playground for that eons ago, if you want to take a look: http://bigbluehat.github.io/vue-uri/

There's still a concern I'm working through about introducing a config file. The tagline here is "a simple zero-configuration command-line http server." This is a completely additional "config" similar to my .headers proposal...so...it becomes a "meta" question about the future of the project, not just the technical feasibility or even usefulness of it.

However, I'm keen to have something like this available (for myself and others), so let's discuss it more! 😁

I'll open an issue for that and mention this PR.

Would you be open to converting this code to using the JSON format from Firebase (at least as a starting point)?

[thornjad]

Closing because this is out of scope and due to inactivity