I hope you'll apply for Early Access and put our new service through its paces.

A colleague just published more details here https://blog.cloudflare.com/cloudflare-traffic-manager-the-d...

As you know, when terminating a WebSocket connection due to releases CloudFlare now signals this action to both client and origin server by sending the 1001 status code (aka "going away", see section 7.4.1 of RFC 6455), so both sides are aware that the WebSocket termination is only a transient event, and that they can expect to immediately re-establish a connection again on retry.

We're working on additional refinements to the release process to minimize disruptions.

(I work at CloudFlare.)

Aye! Well aware. I actually think you added that for us specifically! Anyways, it's worth noting for anyone interested that they'll need to be able to handle spikey reconnects.

In our case, we keep a buffer of the last N websocket messages sent to the client, and when the client reconnects, it sends the last sequence id that the client saw, and the server catches it up.

https://discordapp.com/developers/docs/topics/gateway#resumi...

Working on that. Lots and lots of certs to issue. Seeing about making message "smarter" (checking your individual status) if possible.

Glad to see Page Rule helped. Some revision on cache-control headers would help further.

Just reached out via email to the site owner with some info/tips. We want to help.

CloudFlare doesn't cache HTML by default, though you can enable that with Page Rules. http://blog.cloudflare.com/introducing-pagerules-advanced-ca...

And the origin needs to be responding long enough for us to keep a copy in cache, once the Page Rule is enabled.

Thanks, appreciate it. Are you with Cloudflare?

Yes, I work at CloudFlare.