This is my Aphlict configuration:

(It's quite possible that I am doing something wrong here)

Yea, so I think the path forward is to check the version of WS and to add some docs about it in the aphlict changes, and just the general updating guide.

From IRC, this may be an issue with older ws (0.7.1) except that I also have 0.7.1 locally. But we should possibly upgrade / recommend upgrading / something like that.

I also tried swapping the ".key" and ".crt" but that gave me the same error as using a bogus file.

Other stuff I tried:

I can't immediately reproduce this...

From IRC, the HTTPS server didn't even start up (no port in netstat). So my first guess is that there's some 'error' handler we need to install, and that should tell us what the issue is (bad SSL key / weird Node stuff / who knows what).

This is now in production and appears to be working properly.

Thank you for the update, I didn't think of using Conference. I haven't found anything that directed me to /status, just had the url as part of our validation after an upgrade, and went to use it.

There's a new status panel in Config → Notification Servers. I'm consolidating cluster status information there.

Following the upgrade, is there a way to send test notifications and /notification/status/ is now a 404 error?

It should be fixed in HEAD, it just only regenerates once every 24 hours or something I think.

https://secure.phabricator.com/book/phabricator/article/notifications/ needs to be modified to fit the new world.

Here's how I modified the configuration on this host (secure.phabricator.com) to account for this change.

this guy is pretty cool I like him 🐗

💯💯💯

Per T6915, I'm likely to split the Phabricator side config into a list of services. If you run multiple servers, you list all of them and Phabricator can survive the loss of some subset gracefully. This should be easier for everyone to configure, too.

I'm currently thinking about making this configuration push-based instead of pull-based: each server is told about other servers it should publish to when it starts up. When it receives a notification, it publishes to all those servers (with reasonable mechanisms in place to prevent cycles).

I haven't been successful locally in getting a GC'd node to reach an appreciable level of memory consumption, and the production servers are currently at ~1.5GB.

I think the ~1.5GB node instance size is also expected.

At least locally, I can't manage to get node to not leak:

Per T9293, client-uri and server-uri should be split into client-port, client-host, admin-port and admin-host.

I'll make a note on T10697 to split these options into explicit host and port options. The use of uri options which combined hosts and ports was intended to make specifying hosts and ports more convenient, but I think it's clear that it was a grievous error.

In T9293#167654, @epriestley wrote:

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

Using client-uri will cause us to use wss:// on pages which are http:// on the client. This seems very confusing/unexpected to me. Although this is probably fine usually, it defies user intent and may not work if, for example, the server certificate is self-signed and the user is using http specifically because their client does not recognize the CA. Such a user would be confused: "I'm connecting with HTTP and it says HTTP in my browser, but I'm getting an SSL certificate error. I specifically switched to HTTP because I know that this client can not trust the certificate."

In T9293#167652, @epriestley wrote:

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

$_SERVER['HTTPS'] should always reflect the SSL-ness of the original connection. If it does not, it is misconfigured.

In T9293#167637, @epriestley wrote:

We will not trust X-Forwarded-Proto, X-Forwarded-For, etc., by default because they are not trustworthy in the general case (they are completely client-controlled if you aren't behind a load-balancer).

I plan to make these options explicit instead. This tangled maze of inferring things from various values is a bad state of affairs. See T10697.

To resolve this, configure your server so that $_SERVER['HTTPS'] is set correctly. This impacts other checks, so it is much better to fix it than try to guess our way around it by examining aphlict.client-uri.

This doesn't describe a reproducible problem. See Providing Reproduction Steps.

I plan to separate this configuration and make these options all explicit, see T10697.

The Aphlict logs don't reveal anything useful, and could use some attention: they're heavily geared toward setup/debugging, not maintenance/operations.

I would vote for X-Forwarded-Proto support in AphrontRequest::isHTTPS

Sorry, I picked a really bad name for it originally.

oh

This task has nothing to do with any user-visible behavior and is purely a performance/network optimization, despite all the discussion about batching emails here. :)

Sounds like this has been resolved.

In T10481#162637, @tycho.tatitscheff wrote:

Have you launched aphlict in debug mode ?
https://secure.phabricator.com/book/phabricator/article/notifications/#troubleshooting

Are behind a nginx proxy or direct connected. If you are connected directly maybe your port isn't open.

Have you launched aphlict in debug mode ?
https://secure.phabricator.com/book/phabricator/article/notifications/#troubleshooting

Adding if (matches[2]) before content[matches[1]] = matches[2] in aphlict_server.js (to allow the default to kick in for otherwise empty values on the cli) resolves the problem for me.

To the best of my current knowledge, there are no actual problems with the Node server (empirically, it is easy to install and maintain, stable, and works well) and no viable pure PHP alternatives anyway, so I have currently have no plans to ever pursue this. See above for a description of the type of new information which could affect these plans.

@aaa