uHTTPd still in firmware?

Hi support!

Why uHTTPd still present in Gl firmware? As I see you are using NGNIX, no?

uHTTPd is unused, so it just takes space from router's flash. Maybe just remove it, since it already on NGNIX?

Also it will prevent situations discussed on this forum earlier

@alzhao (sorry if I pinging wrong person), can you please take a look?

1 Like

Which router are you using and what does opkg list-installed show?

uhttpd is used by luci.

In the latest firmware uhttpd is used for Luci. Luci has problems with Nginx.

In some old firmware, uhttps is there but not used. Agree that it should be just removed.

I strongly disagree. Nginx should be removed. It's bloat. There's no need for a multi-process, web server capable of c10k requiring over 15x the flash space and 37.4x the RAM when OWRT is a single seat administered, embedded system.

-rwxr-xr-x    1 root     root      673.6K Oct 17  2024 /usr/sbin/nginx*
-rwxr-xr-x    1 root     root       44.4K Oct 17  2024 /usr/sbin/uhttpd*
ps -w | grep nginx | grep -v 'grep' && ps -w | grep uhttpd | grep -v 'grep'
4373 root      7008 S    nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf -g daemon off;
4523 root     11188 S    nginx: worker process
4524 root     10704 S    nginx: worker process
4525 root     10288 S    nginx: worker process
4526 root     10896 S    nginx: worker process
3905 root      1560 S    /usr/sbin/uhttpd -f -h /www -r router -x /cgi-bin -u /ubus -t 60 -T 30 -k 20 -A 1 -n 3 -N 100 -R -p 12

_header
gl-ngx-session
nginx
uhttpd

(firmware 4.6.8-release1)

There's no benefit to Nginx when it doesn't even have proper WebDAV support.

Yes, uhttpd is more lightweight.
GL GUI uses nginx I guess the reason is the early firmware development, nginx was chosen to be able to handle our own API.

If future everything is right, we may consider swapping a lighter http server.

I can't imagine the amount of developer time/'technical debt' that's required for a custom API just to run on OWRT. I've only briefly looked at some of the GL scripts but I can't imagine why write completely custom scripts when uci itself is so easily scriptable.

I could see a custom daemon tunneled thru HTTPS as a endpoint for the GL.iNet app, though... or just push/pull over dropbear:

... but it sure would be nice to get back that RAM from Nginx given LuCI runs Lua to interface with uci.

1 Like

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.