kj800x / localproxy Goto Github PK

Main benefit: multiplexing of resources when lots of requests (most noticeably when serving lots of largeish imgs or vids, or long running ajax requests). With HTTP 1.1, Chrome will only make up to 6 concurrent requests to the same domain.

Good news, looks like we just need to add http2 to the end of the nginx directive.
Bad news, it only works if the browser connects with SSL which means we need to get #6 (https with self signed certs) working first.

The only issue is the problem of node. I'm gonna need this for deployments on to rPis or BBB/BBG/BBGWs which is where my projects inevitably end up.

Create a localproxy-react-scripts serve command as a convenience to serve the previously built files with the correct route (based on the ##homepage field of the package.json). This will differ from localproxy-react-scripts start since that one will proxy to a dev server, but serve should just serve the last build.

I haven't needed this before since I mostly accompanied my FE with node BEs which can configure the localproxy config to include the FE build folder when they set up their routes, but I'm setting up a FE which just uses an external BE and I realize I don't have a way to serve the build folder at the correct route easily.

Will probably involve changing the type of Route to be a disciminated union over a string field rather than the static Boolean

We should support things like /temp -> /weather as permanent and temporary redirects. I'd implement this as a new type of route and a user could set up a persistent app which redirects the user accordingly (or have old paths as redirect paths in the BE config).

I had a weird issue where my network was misconfigured (I think), and localhost resolved to [::1] instead of an IPv4 address. I think this is fine in-of-itself, but then there was a misconfiguration where [::1] wouldn't resolve even though it was listed in ip addr:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever

We can sidestep this whole thing if we just use 127.0.0.1 instead of localhost. IPv4 is stable enough I don't think we ever need to worry about that being broken, and I don't expect IPv4 loopback to stop working anytime soon.

One major issue is that it always uses URLs relative to / (when the app might not be mounted on /)

In this case, we need to fallback to serving the index.html when we can't find the file matching the request.

Ideas: https://superuser.com/questions/1199616/get-nginx-to-always-serve-index/1199622

We will want better support if the machine doesn't have the localproxy service installed. As of now, if there is no localproxy service installed, we can't start the app (or perhaps it just silently fails? not sure). Can we detect if the localproxy service is not installed and instead spin up our own port 80 server in nodeland and do some forwarding?

Since this is a localproxy, we don't really need caching, especially with routes being handled dynamically, there's a fair chance that we need to bust the cache on every load. I keep running into issues where I load the wrong page but a force refresh fixes it

https://serverfault.com/questions/549200/how-do-i-force-nginx-to-load-new-static-files

Similar to systemctl start / systemctl stop, enable should drop a file to host the current build and also not block. The idea here is you would ssh to a box, run enable and then close the connection and the assets would continue to be served. disable would do the inverse and remove the file if it exists.

This is a bit different from systemd enable / disable because those persist between restarts. Maybe we would want to persist these between restarts but I think localproxy clears all sites when it starts up so it would require a bit more changes (but for serving a static site I suppose there's no reason to clear it on system restarts... it's just files... there are no processes which would be killed).

Also different from localproxy-react-scripts serve because that blocks until closed.

Maybe something here needs to be renamed (although start is already taken by the dev server)

Useful for serving archives. Probably wouldn't be compatible with the autoindex option, but this config:

{
  id: '/home/kevin',
  name: 'kevin',
  routes: [
    {
      static: true,
      route: '/',
      staticDir: '/home/kevin/',
      priority: 0,
      indexFallback: false,
      autoIndex: false,
      zipUnwrap: true,
    }
  ]
}

should take something like http://localhost/foo/bar.zip!folder/file.txt and serve it by extracting folder/file.txt from /home/kevin/foo/bar.zip

This would be a very nice to have

So far I haven't used localproxy as part of a backend app that's running on a real server. Just a few hobby projects on my laptop. If I do end up wanting to have it run on a real server, we probably want to think about being able to run it in a safe way. We definitely don't want to run the localproxy service on a real internet facing server, since it's not super well secured and it's intended to not be publicly reachable. Yet, there is server configuration inside of the localproxy config that would be required for running the server. Perhaps we can "bake" the configuration into an nginx config during the build process and a real prod server can us that instead?

This would be useful for serving local directories where extensions are usually right and sometimes wrong and sometimes just missing.

This is why extensionless images download instead of displaying in the browser.

I think maybe we can patch nginx to run file if it can't figure out the mime type from the extension.

Honestly, these should probably only be accessible from localhost, otherwise anyone can set up routes and access any file from the localproxy host as long as they can make an http connection to it.

Still seem to get issues with @kj800x/localproxy-client trying to acquire it's config file in /etc/localproxy. Problems if the previous process wasn't able to shut down properly. Should probably just overwrite the file with a warning in this case.

https://blog.adriaan.io/one-nginx-error-page-to-rule-them-all.html

On a fresh install, conflicts with nginx's default config

i.e. need to run sudo rm /etc/nginx/sites-enabled/default