Re: Server-sent Events and HTTP Proxies

(I have quoted the entire mail for context.)

On Mon, 27 Oct 2008, John Fallows wrote:
>
> 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.

I agree with the above analysis. In practice I expect authors will use 
blocks of garbage in comments to overflow the proxy buffers and force the 
proxies to send the data, with the size of the comment garbage being 
either statically decided during development, or dynamically determined by 
the script (doing so is relatively easy if tedious). This certainly isn't 
optimal, by any means.


> 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.

I don't really want to do this because introducing the concept of 
unencrypted SSL connections would likely to confusion and I'm sure at 
least one person would end up using it wrongly, with potentially 
disastrous (and undetected) results.

It would be a bit like fixing the problem of smoke detectors having false 
alarms by shipping them with a push switch that toggles them on and off 
(with no indication of whether the alarm is actually on or off).

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Wednesday, 12 November 2008 20:04:21 UTC