Server-sent Events and HTTP Proxies

An HTTP proxy can participate in a request from browser to server in one of
two ways:

   1. The browser is explicitly aware of the HTTP proxy due to local browser
   configuration (perhaps automated).
   2. The browser is unaware of the HTTP proxy at the IP gateway, and all
   HTTP traffic is implicitly routed by the OS to the IP gateway address.

As currently specified in
http://www.w3.org/html/wg/html5/#server-sent-events, HTTP proxies may buffer
fragments of the HTTP response, because they may legitimately assume that an
entire HTTP response is expected by the browser.  This buffering behavior is
clearly bad for the end-to-end latency of message delivery and should be
avoided if possible.

There are 3 possible solutions to the HTTP proxy buffering issue for
Server-sent Events:

   1. Use HTTP CONNECT verb over an unencrypted connection to setup a tunnel
   through the HTTP proxy.
   2. Fallback to non-streaming case, instead use "long-polling" technique
   where response is completed on each message delivery.
   3. Leverage HTTPS, which implicitly uses HTTP CONNECT verb over an
   encrypted connection to setup a secure tunnel through the HTTP proxy.

Use of HTTP CONNECT is anticipated by proxies only for HTTPS use, and the
default configuration for some proxies, such as Squid, may limit the use of
HTTP CONNECT to connect to the standard HTTPS port 443 on the target HTTP
server.  The browser can only send HTTP CONNECT to a proxy it is explicitly
aware of, so this does not handle the other case where the HTTP proxy is
installed at the IP gateway address.

Falling back to a "long-polling" strategy for HTTP proxies is functionally
viable, although both server performance and network bandwidth utilization
would suffer.  This would also require immediate reconnect by the client,
but setting the SSE retry timeout to zero would have serious side-effects
for the network failure scenario, due to constant reconnect attempts by the
client.

Using HTTPS does seem to address all the relevant concerns about intervening
HTTP proxies, because they create a tunnel to the server and cannot know the
contents of the secure stream thereafter.  Due to the combination of
encryption and HTTP/1.1 persistent connections, the HTTP proxy cannot know
which bytes describe the end of an HTTP response, so it cannot legally
buffer the response.

However, adding encryption into the mix increases CPU and memory utilization
at both the client and server for otherwise open communication, just because
there is an HTTP proxy in between.  Only the server can reliably detect the
presence of the HTTP proxy, to cover both explicit and implicit proxy
scenarios described above.

Perhaps the SSL encryption overhead can be addressed by specifying that it
is legal to redirect an HTTP Server-sent Events request from http:// scheme
to https:// scheme, and in that scenario allow the client to accept null
encryption if offered by the server.  In all other cases, when the actual
eventsource URL is https:// then null encryption would not be allowed by the
client, as is the behavior today.

Kind Regards,
John Fallows.
-- 
>|< Kaazing Corporation >|<
John Fallows | CTO | +1.650.943.2436
800 W. El Camino Real, Ste 180 | Mountain View, CA 94040, USA