When using HTML5 SSE, methods to deal with reconnection and errors include: 1. Understand the default reconnection mechanism. EventSource retrys 3 seconds after the connection is interrupted by default. You can customize the interval through the retry field; 2. Listen to error events to deal with connection failures or parsing errors, distinguish error types and execute corresponding logic, such as network problems relying on automatic reconnection, server errors manually delay reconnection, and authentication failure refresh token; 3. Actively control reconnection logic, such as manually closing and rebuilding the connection, setting the maximum number of retry times, and combining navigator.onLine to judge network status to optimize retry strategies. These measures can improve application stability and user experience.

When using HTML5 Server-Sent Events (SSE), handling reconnections and errors is key to ensuring application stability. Browsers will try to reconnect automatically by default, but the default mechanism is often not enough, especially when the network is unstable or server-side errors. We need to actively intervene to enhance our fault tolerance.

Understand the default reconnection mechanism of SSE

When the connection is interrupted, the EventSource object automatically tries to reconnect, with a default interval of 3 seconds. This time can be customized by sending retry: field in the server response. For example:

 retry: 5000

This tells the browser to wait 5000 milliseconds (i.e. 5 seconds) before the next retry. If not set, the browser will use the default value.

It should be noted that this reconnection mechanism is suitable for situations where the server is "temporarily unavailable", such as short-term network disconnection or service restart. However, if the server returns an HTTP error (such as 4xx or 5xx), the browser will not automatically retry, and we need to handle it manually at this time.

Listen to an error event and respond

SSE provides an error event that allows us to capture connection failures, parsing errors, etc. While the browser will automatically reconnect in some cases, it may stop trying when some serious errors occur. Therefore, it is very critical to listen to error event and respond appropriately.

You can add a listener like this:

 const eventSource = new EventSource('your-endpoint');

eventSource.addEventListener('error', (err) => {
  console.error('SSE error:', err);
  // Custom reconnect logic can be triggered here});

In this callback, you usually need to judge the error type. For example:

• If it is a network problem, continue to rely on the browser's automatic reconnection;
• If it is a server error (such as returning 500), it may require manual rebuilding of the connection after delay;
• If it is a problem such as authentication failure, you may need to refresh the token first and then reconnect.

Here you can add a common reconnection strategy:

• Record the number of failures;
• Set the maximum number of retry times;
• After the upper limit is reached, the user is prompted to check the network or notify the system administrator.

Actively control the reconnect logic to improve reliability

Sometimes, we want to control reconnection behavior more carefully. For example, actively trigger the connection after the network is restored, or decide whether to continue polling based on the service status.

A common practice is to manually close the current connection and create a new EventSource instance after an error is detected:

 let retryCount = 0;
const maxRetries = 5;

eventSource.addEventListener('error', () => {
  if (retryCount < maxRetries) {
    setTimeout(() => {
      eventSource.close();
      const newEventSource = new EventSource(&#39;your-endpoint&#39;);
      // Rebound event listener...
      retryCount ;
    }, 5000); // Custom retry interval} else {
    console.log(&#39;The number of retrys has reached the upper limit&#39;);
  }
});

In addition, you can also use navigator.onLine to determine whether it is currently online. If it is offline, pause and try again, and continue to try after restoring the network.

Basically that's it

The core of handling SSE reconnection and errors is to understand the default behavior of the browser and supplement your own logic based on it. You can improve the stability and user experience of connection by setting retry time, listening to error events, implementing a custom retry mechanism, etc. Although it doesn't seem complicated, a slight negligence may lead to messages being lost or connections being stuck, so pay more attention to details.

The above is the detailed content of Handling reconnections and errors with HTML5 Server-Sent Events.. For more information, please follow other related articles on the PHP Chinese website!