A web server, if possible nginx that can serve at least one static index.html file.

That's it.

RouterOS, as name implies, is a router - it should not serve webpages. The only possibility is hotspot captive portal (and I think it should stay that way). Making webserver is hard (and I say that as an author of one), incorporating existing one is not in MT style and will mean they need to track 3rd party component development...

Here we go again, what a proper router should and should not do? Never-ending story.

There already is web server in RouterOS, no need to make another one. And if it can serve files for WebFig or hotspot, it could surely serve a few more, uploaded by user. If serving user's files from subdirectory would be enough (e.g. http://router/user/<file>), it's a matter of one well placed symlink, and that's it.

Of course the request is kind of a trojan horse. Add a symlink and next request will be for configurable directory name. Add that and ability to serve files under root directory (when web server is not used by WebFig or hotspot) will follow. And request to support virtual hosts with different roots will be next. Still good, nothing hard so far. But why not an ability to run scripts? Nothing special like php, just the ones defined in "/system script". Imagine how many cool thing you could do with that. And it's still nothing too complicated, add new "http" permission to scripts (to select which ones can be run like this), set few variables (info about request), let them spit out whatever they want to send to client and happy end is near. Of course there's always a risk that someone will want some advanced functionality next.

RouterOS, as name implies, is a router - it should not serve webpages. The only possibility is hotspot captive portal (and I think it should stay that way). Making webserver is hard (and I say that as an author of one), incorporating existing one is not in MT style and will mean they need to track 3rd party component development...

It's not that hard to compile nginx. Nor is hard to branch off already stable release and use it for own needs. Had MikroTik been free software I would have done it myself.

RaspberryPi B+ or Arduino+Ethernet module are all you need.

Here we go again, what a proper router should and should not do? Never-ending story.
...
Of course there's always a risk that someone will want some advanced functionality next.

Not to mention the fact that providing script-enhanced HTTP(S) services increases the attack surface of the platform as well. One buffer overflow vulnerability could lead to remote arbitrary code execution exploits; one poorly-written script could throw the door wide open; etc.

Well, maybe I got a little carried away with scripts, it sometimes happens to me when I switch to visionary mode. But every admin would have it in own hands, so it would be just one more way to do something wrong. Don't use it and you're safe.

It's not that hard to compile nginx.

Isn't nginx an overkill for serving one static index.html? Nothing against it, if it was possible to add it to RouterOS (preferably as optional package), I'm sure it would be useful for many users. Not only as web server (what can you really do with just static content...), but also as proper reverse proxy (sure it can be done using external device, but that's exactly what many people prefer not to have).

I've thought that a simple static HTML delivery mechanism could be useful in cases where you wanted to give messages to users, such as "your Internet has been interrupted due to non-payment" "please call customer service to arrange payment details in order to have your service restored" , yadda yadda.

I can live w/o it though, and can easily see why Mikrotik might not want to open that can of worms.

It's not that hard to compile nginx. Nor is hard to branch off already stable release and use it for own needs.

Have you ever worked in any software development, honestly? I deal with JUST libraries every day, I deal with JUST APIs every day and last, but not least, I deal with JUST software-which-provides-functionality-and-according-to-the-docs-should-work-in-a-certain-way-but-heck-why-it-does-not-today. Trust me, it's not that simple to just incorporate something into existing architecture.

Sob also put the problem into proper frames. See the stories with OpenVPN, IKEv2 and TR069 - it all started with simple request and than it evolved. The difference is, these features were actually router-specific. Look at the UPS package - MT made it to support APCs and then angry people started pushing MT to implement another brands with no support from 3rd party manufacturers...

Had MikroTik been free software I would have done it myself.

OpenWRT as MataRouter + nginx?


I don't know, maybe I grew a beard for no reason and it's just silly me trying to separate services and avoid SPOF, but I want to keep my non-criticial equipment serving static files away from my core infrastructure.
...so as PBX, print server, NAS, monitoring server, authentication daemon, log collector, [you name it].

It's not that hard to compile nginx. Nor is hard to branch off already stable release and use it for own needs.

Have you ever worked in any software development, honestly? I deal with JUST libraries every day, I deal with JUST APIs every day and last, but not least, I deal with JUST software-which-provides-functionality-and-according-to-the-docs-should-work-in-a-certain-way-but-heck-why-it-does-not-today. Trust me, it's not that simple to just incorporate something into existing architecture.

Sob also put the problem into proper frames. See the stories with OpenVPN, IKEv2 and TR069 - it all started with simple request and than it evolved. The difference is, these features were actually router-specific. Look at the UPS package - MT made it to support APCs and then angry people started pushing MT to implement another brands with no support from 3rd party manufacturers...

Had MikroTik been free software I would have done it myself.

OpenWRT as MataRouter + nginx?


I don't know, maybe I grew a beard for no reason and it's just silly me trying to separate services and avoid SPOF, but I want to keep my non-criticial equipment serving static files away from my core infrastructure.
...so as PBX, print server, NAS, monitoring server, authentication daemon, log collector, [you name it].

Your comment brings eye to my tear.
Anyhow, to answer your question, honestly:
I dig potato for a living, being a potato miner, i just happen to visit MikroTik forum.

I think that the MikroTik software development team can make index.html web server happen.
It could and should be an optional package.
If something is hard you don't just quit.
I agree with you about doing routing from a system with Linux kernel only and no daemons but since MikroTik is the AK-47 of the networking world there are many use cases, getting the job done plus being inexpensive and somewhat durable is why it sells.

Surely they can. But they will not. I remember that the reason was already mentioned by mikrotik representative on this forum in the past. There are quazilions of options how to run a Web page. You can spend your life by trying them one by one. No need to add another...

I believe I have a very valid reason to want to serve a small redirect page from the MikroTik. I wish to gather variables from the router related to the user making the request and post the results to a real web server. I believe this would be simpler than having to create an API interface from the web server back to the MikroTik, especially since NAT is involved.

I wish to use RADIUS DHCP authentication instead of the hotspot. I have the RADIUS DHCP working. Unauthenticated people get a different subnet that has them restricted to a walled garden that includes a signup server. I can use the web proxy to redirect them to the signup server, but I need to get data, like MAC address, from the MikroTik to the signup server to create the account. The Signup Server is separated from the customer by NAT, so I can't think of any way for the signup server to pull the data with API calls since NAT obscures the IP of the call.

It would be enough if I could create a web proxy rule that allowed me to add variables to the deny and redirect to procedure. But allowing me to redirect to an internal page that gathers the data and posts it to the signup server would mean I don't have to rewrite the signup server.

moany crap

moany crap

Needed it for wpad proxy autoconfig.