hunchentoot serving manifest files, ie. .appcache files.

[Left Right]

@Ron Garret
I didn't mean HT own log, but even then locking isn't the best
solution always: for example, I don't know what bordeaux-threads does
when a thread holding a lock dies, does it release it? What if it
depends on Lisp implementation? Maybe a lock-free queue would be a
better option for log? - I don't know. Anyways, my point was that
these would be non-trivial questions to answer, and while it is easy
to come up with a simple SSE implementation, a real-world
implementation might be a lot more difficult to master.
Environments like PHP running as Apache httpd module don't have this
problem, because they are single threaded, so, there it's a good (and,
practically, only) choice. But it is good in a very limited sense...
as it suffers from high congestion (something that concurrent
execution is meant to address).

A side note: SSE doesn't work (yet?) in Internet Explorer :) Well, I
guess OP was already aware of it.

@Hans Hübner

I haven't tried it, but this is the quote from the front page of
http://www.websocket.org/aboutwebsocket.html

A WebSocket detects the presence of a proxy server and automatically
sets up a tunnel to pass through the proxy. The tunnel is established
by issuing an HTTP CONNECT statement to the proxy server, which
requests for the proxy server to open a TCP/IP connection to a
specific host and port. Once the tunnel is set up, communication can
flow unimpeded through the proxy. Since HTTP/S works in a similar
fashion, secure WebSockets over SSL can leverage the same HTTP CONNECT
technique. [...]

I'm not sure whether SSE can do the same and how well does this
address the problem of proxies in general. From my experience using
Flash sockets (they don't know how to tunnel over HTTP on their own),
there was some obscure extension to HTTP 1.1 which allowed one to
emulate simple TCP over HTTP :) I think that Adobe RTMP uses something
like that as a fallback.
As we actually had to use it (the product was an RP game, where many
players were using computers behind NAT or some sort of corporative
proxies, firewalls etc), we found that emulating TCP over HTTP in that
way suited us better then other options we considered.

On Sun, Mar 2, 2014 at 8:10 AM, Hans Hübner <hans.huebner at gmail.com> wrote:
> While SSE wins over WebSockets in terms of simplicity, it should be noted
> that intermediate http proxies may not deal with the protocol in the
> required ways (i.e. the proxy may not forward the request until the whole
> response has been read).  One way around that is to use https, which will
> implicitly make the proxy forward the connection directly to the origin
> server, but may be forbidden by some proxies altogether.  WebSockets share
> the problem, but as they are defined a bit more strictly than SSE, they may
> see more support in intermediate proxies.
>
> The only universally safe way to push events from a HTTP server to a client
> is to use (long) polling.  Other methods are not advisable if universal
> availability of the service is desired.
>
> It is unfortunate that there is no maintained WebSockets service that works
> well with Hunchentoot.  There once was Hunchensocket, but it did not receive
> any love over the last few years and thus requires considerable work to
> bring it up to date.
>
> -Hans