Add ability to serve gzip compressed resources

[dolfs]

Using web pack, as we do, it is easy to generate duplicates of various bundles that are gzip-ed and have a name that is identical except for an additional suffix of .gz.

If a request comes in that contains the "Accept-Encoding: gzip" header, it would be nice if we would serve up any .gz version of a resource, if it exists. This does not require building on-the-fly gzip capability into the server.

It would come at the cost of an extra stat call to see if the gz resource exists unless we also have the server build a resource map at startup. Probably not important enough performance wise for now.

[dolfs]

FYI for my current ui-refactor in progress, the .gz variants will reduce overall resource load from 344K to 101K, so it is worthwhile.

[scottlamb]

I agree that'd be a nice bit of polish, though probably not urgent. (If you have bandwidth for video, you probably have bandwidth for the uncompressed files.)

In general, the way the static file serving is done now is kind of silly. It scans for files once at startup; so if you add files to the static file dir while it's serving, it will still say they don't exist. It'd be nicer to have something for serving a directory properly, perhaps added to my http-serve crate. That could check for the .gz variant first if the already-written http_serve::should_gzip function returns true.

I'd also like to support self-contained builds for distribution that bundle all the static files into the binary.

[dolfs]

The urgency argument does not apply if you are trying to check your "stuff" from a mobile out in the field. I do this using a VPN over cellular (because I do not want to expose Moonfire on an extern port).

Having said that, it is still not truly urgent, but a but more important than the "if you have video bandwidth" argument.

[scottlamb]

Yeah, fair point. Let's call it milestone-1.0?. (Incidentally, I haven't filed issues for this yet, but I really would like to address for 1.0 the "do not want to expose Moonfire on an external port" thing. It needs user authentication, and it either needs built-in https + letsencrypt support or at least instructions for sticking Apache/nginx in front for https.)

[dolfs]

Given the lack of easy options in the rust portion, sticking nginx in front for http is probably an easier option, although it will require installing extra packages. The user authentication will require a number of things: Database support in the schema (perhaps just username/password hash) no real need for usernames being email, unless you need forgot my password functions etc. A way of manipulating those database entries Perhaps through moonfire-nvr config Or additional UI for people identified as admin A short term fix, which might be less work, is to also use nginx to stick basic http authentication in front Even with nginx we would have to figure out letsencrypt support. That takes al little work due to those certs expiring frequently and needing an automated “fetch and install a new one” functionality. Dolf Starreveld email <mailto:[email protected]>

…

On Mar 8, 2018, at 22:06, Scott Lamb ***@***.*** ***@***.***>> wrote: Yeah, fair point. Let's call it milestone-1.0?. (Incidentally, I haven't filed issues for this yet, but I really would like to address for 1.0 the "do not want to expose Moonfire on an external port" thing. It needs user authentication, and it either needs built-in https + letsencrypt support or at least instructions for sticking Apache/nginx in front for https.) — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#25 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABRU1QYvOVzKp0-3_c7lwz5aOcDdbmEJks5tchvtgaJpZM4Sjx1U>.

[scottlamb]

Lemme open separate issues for these. I've been thinking a bit about how they might work.

[scottlamb]

See #26 (user authentication) and #27 (https). I opened a ton of other issues, too, for most of my mental todo list.