As I read RFC8030, webpush is supposed to be https on 443. While that strikes me as unreasonable -- it seems obvious that the push service should be able to be on other ports, and the URL should be used by the server -- push servers should be able to be configured to follow the RFC, and this should be the standard approach. The example config is on 5283, without tcp.
Ideally:
- the example config would say what the plan is for where it listens, and how that relates to the specs
- the example config would be https
- the example config would be 443
However, 443 is, I assert for most self-hosting individuals, in use for an actual web server. Thus, it would be great if there were an example showing how to listen on a port, perhaps without TLS, while also giving some nginx configuration to reverse proxy https://hostname.example.com:443/up/ back to mod_unified_push. This requires push_url support.
I did manage to listen on another port and TLS, and got UP Example, Element X, and DAVx5 receiving push notificaitons (with Conversations as my UP distributor, of course). That might well be entirely ok in practice.
I realize this sounds a bit like a support request, but I'm really trying to say that it's a bug for the default config not to align with the RFC and not to document how it does or does not comply.
As I read RFC8030, webpush is supposed to be https on 443. While that strikes me as unreasonable -- it seems obvious that the push service should be able to be on other ports, and the URL should be used by the server -- push servers should be able to be configured to follow the RFC, and this should be the standard approach. The example config is on 5283, without tcp.
Ideally:
However, 443 is, I assert for most self-hosting individuals, in use for an actual web server. Thus, it would be great if there were an example showing how to listen on a port, perhaps without TLS, while also giving some nginx configuration to reverse proxy
https://hostname.example.com:443/up/back tomod_unified_push. This requirespush_urlsupport.I did manage to listen on another port and TLS, and got UP Example, Element X, and DAVx5 receiving push notificaitons (with Conversations as my UP distributor, of course). That might well be entirely ok in practice.
I realize this sounds a bit like a support request, but I'm really trying to say that it's a bug for the default config not to align with the RFC and not to document how it does or does not comply.