1217543 - Audit push client server error state scenarios

Status: RESOLVED WONTFIX

(Core :: DOM: Push Subscriptions, defect)

Description

[ewong]

Need someone to look at client server behavior related to:
* webpush server is down
* webpush server returns 500/503
* webpush server wants clients to back off retries
* webpush server is 404
* webpush server connection is attempted to redirect

Comment 1

[ewong]

also confirm the connection timeouts are tuned or refined - maybe from metrics?

Comment 2

[JR Conlin [:jrconlin,:jconlin]]

* webpush server wants to redirect to new/different service
(e.g. This service is shutting down, go there.)
* server is in maintenance window and needs clients to not reconnect for n period.
* protocol version has been sunset / service no longer offered.

Comment 3

[Edwin Wong [:edwong]]

also how do we want to message the user or what does subscribe() return if the service is dead

Comment 4

[Lina Butler [:lina]]

Here's a summary of the current WebSocket client behavior.

The client will back off exponentially, with an initial delay of 5 seconds and capped at the ping interval (30 minutes), if...

* The server is down (a WebSocket connection can't be established. This includes TCP errors and HTTP 500/503/400 responses).

* The `hello` handshake fails.

* The server doesn't respond to a ping within 10 seconds.

* The connection is reset (TCP) or closed (server sends a WebSocket close frame). Exception: the client will not reconnect if the server sends a UDP wake-up close code.

* A `register` request times out (10 seconds).

Comment 5

[Lina Butler [:lina]]

Other points:

* Redirects are not supported. If we want redirects, the server will need to accept the WebSocket upgrade, then send the new URL in a response message.

* `Retry-After` is not supported, since sending this requires accepting the WebSocket upgrade. We discussed this on IRC, and agreed this doesn't really help the server. Having the client use its own backoff logic is sufficient.

* Protocol versions are not supported. We agreed it doesn't make sense to version the extended WebSocket protocol, since we intend to switch to HTTP/2 soon.

Comment 6

[Lina Butler [:lina]]

Closing this out, per Edwin's suggestion. We can reopen if we need to revisit these behaviors.