I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
I have read in w3schools about usage of server sent events in html5. it says:
- Set the "Content-Type" header to "text/event-stream" - Specify that the page should not cache - Output the data to send (*Always* start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
- Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
Personally I much prefer server-side events (SSE). It’s a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that’s the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
Don't forget that sockets are concurrent by design: in a simplest scenario, you'd allocate a thread per connection. Not a very efficient way of dealing with it, but at least it is easy to implement in a way that you don't run into deadlocks or other errors caused by multiple threads accessing shared state. But if you choose to use server events, you would have to be very careful to write re-entrant functions to serve the request, which is particularly difficult because Hunchentoot relies on a handful of global variables to function... you may easily run yourself into a situation where two functions try to write to the same output stream, even at the level that Unicode byte sequences become interleaved and the receiving side would fail with arcane low-level decoding errors (happened to me before).
On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret ron@flownet.com wrote:
Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
you may easily run yourself into a situation where two functions try to write to the same output stream
I don’t think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn’t, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe.
rg
On Mar 1, 2014, at 12:58 PM, Left Right olegsivokon@gmail.com wrote:
Don't forget that sockets are concurrent by design: in a simplest scenario, you'd allocate a thread per connection. Not a very efficient way of dealing with it, but at least it is easy to implement in a way that you don't run into deadlocks or other errors caused by multiple threads accessing shared state. But if you choose to use server events, you would have to be very careful to write re-entrant functions to serve the request, which is particularly difficult because Hunchentoot relies on a handful of global variables to function... you may easily run yourself into a situation where two functions try to write to the same output stream, even at the level that Unicode byte sequences become interleaved and the receiving side would fail with arcane low-level decoding errors (happened to me before).
On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret ron@flownet.com wrote:
Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
It doesn't help if HT does it's part right. Imagine, for the sake of argument that your code inside a handler writes to the log file. The handle of the log file is shared between all threads (or else there would be a log file per thread? Not something you want to do, right?). So, imagine you have two long-living requests, which you serve in server-events fashion: first starts writing to the file stream while at the same time the second handles data. Just as the first one is about to finish to write to the log, the second one finished writing data and wants to write to the log as well: boom, you have a race: two threads fighting over the ownership of the log file handle! Sockets don't particularly help in this scenario, but IMO they make the programmer more aware of what happens to the program (I'm not a big fun of implicit parallelism...)
On Sat, Mar 1, 2014 at 11:46 PM, Ron Garret ron@flownet.com wrote:
you may easily run yourself into a situation where two functions try to write to the same output stream
I don't think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn't, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe.
rg
On Mar 1, 2014, at 12:58 PM, Left Right olegsivokon@gmail.com wrote:
Don't forget that sockets are concurrent by design: in a simplest scenario, you'd allocate a thread per connection. Not a very efficient way of dealing with it, but at least it is easy to implement in a way that you don't run into deadlocks or other errors caused by multiple threads accessing shared state. But if you choose to use server events, you would have to be very careful to write re-entrant functions to serve the request, which is particularly difficult because Hunchentoot relies on a handful of global variables to function... you may easily run yourself into a situation where two functions try to write to the same output stream, even at the level that Unicode byte sequences become interleaved and the receiving side would fail with arcane low-level decoding errors (happened to me before).
On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret ron@flownet.com wrote:
Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
If HT doesn’t have a mutex around log file writes that’s a bug in the HT logging code IMHO. Without a mutex, interleaved log file entries can happen even with ordinary HTTP requests. SSE has nothing to do with it.
On Mar 1, 2014, at 2:30 PM, Left Right olegsivokon@gmail.com wrote:
It doesn't help if HT does it's part right. Imagine, for the sake of argument that your code inside a handler writes to the log file. The handle of the log file is shared between all threads (or else there would be a log file per thread? Not something you want to do, right?). So, imagine you have two long-living requests, which you serve in server-events fashion: first starts writing to the file stream while at the same time the second handles data. Just as the first one is about to finish to write to the log, the second one finished writing data and wants to write to the log as well: boom, you have a race: two threads fighting over the ownership of the log file handle! Sockets don't particularly help in this scenario, but IMO they make the programmer more aware of what happens to the program (I'm not a big fun of implicit parallelism...)
On Sat, Mar 1, 2014 at 11:46 PM, Ron Garret ron@flownet.com wrote:
you may easily run yourself into a situation where two functions try to write to the same output stream
I don't think so. The default HT taskmaster on a multi-threaded Lisp spawns a thread per connection and rebinds all the globals. If it didn't, then *any* simultaneous connections would have problems, not just SSE connections. And even on a single-threaded Lisp, subsequent requests would just be blocked until the SSE handler was done. That would certainly be a problem, but not the one you describe.
rg
On Mar 1, 2014, at 12:58 PM, Left Right olegsivokon@gmail.com wrote:
Don't forget that sockets are concurrent by design: in a simplest scenario, you'd allocate a thread per connection. Not a very efficient way of dealing with it, but at least it is easy to implement in a way that you don't run into deadlocks or other errors caused by multiple threads accessing shared state. But if you choose to use server events, you would have to be very careful to write re-entrant functions to serve the request, which is particularly difficult because Hunchentoot relies on a handful of global variables to function... you may easily run yourself into a situation where two functions try to write to the same output stream, even at the level that Unicode byte sequences become interleaved and the receiving side would fail with arcane low-level decoding errors (happened to me before).
On Sat, Mar 1, 2014 at 10:04 PM, Ron Garret ron@flownet.com wrote:
Personally I much prefer server-side events (SSE). It's a lot simpler than websockets. On the client side all you do is:
var source=new EventSource(URL); source.onmessage=function(event) { do_something_with(event.data); }
and on the server arrange for URL to have a content-type header of text/event-stream, and send lines of the form:
data: [your data] <newline><newline>
to the stream you obtain from calling (ht:send-headers). (Note: this stream is a binary stream so you have to encode strings to bytes and use write-sequence, or wrap it in a flexi-stream, but that's the only complication.)
rg
On Feb 28, 2014, at 1:40 PM, Left Right olegsivokon@gmail.com wrote:
Not exactly answering your question, but if you are looking for push functionality in browser, then WebSockets might be a better option. The reason server-sent events exist is by and large due to the handicapped nature of most popular web-development stack in use today, such as PHP interpreter that has to be started on every connection by an HTTP server, such as Apache httpd or ngnx. This means that traditional setup works in a stateless manner. This is unlike, say, most Java HTTP servers (Tomcat, JBoss etc) or Python (Twisted, Tornado), where the setup is normally stateful, meaning that you wouldn't need to restart the interpreter upon each request, instead, your server would persist the state until it is shut down. Hunchentoot belongs to the later category.
Now, because it's not really possible to persist a PHP session across multiple requests, a technique first known as long polling appeared. The operating principle was that the server, in response to an HTTP request would not close the connection immediately, instead it would keep sending the information, whenever the application state at the server would demand it. The receiving side (the browser) would listen to updates on this connection and interpret them as "pushes". Event stream is a refinement of this scheme.
WebSockets, on the other hand, are plain TCP sockets, which means that they don't require HTTP wrapping to function. I haven't had much experience with JavaScript WebSockets, but I used their analogy in Flash quite a bit. It was a relief not to depend on the bizarre rules of HTTP protocol and its encodings, headers and so on. So I would expect the same to hold for WebSockets.
Best,
Oleg
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
Set the "Content-Type" header to "text/event-stream" Specify that the page should not cache Output the data to send (Always start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.com wrote: > > I > have another question about hunchentoot. Is it possible to use server > sent events with hunchentoot, like other html5 improvements mentioned in > w3schools-html5 such as app cache, local storage, session storage? as that > one related to and depend on the server side support. >
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
@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@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
i am also scanning hunchentoot documentation. i have found about outgoing headers, the accessor header-out and setf of it creates a new one if not exists. maybe sent content type header can be setf ed by this at the beginnig of the lisp function that has been dispatched to the url. by url I mean script mentioning it as eventSource("url") in html5 document. same for cache-control header.
Is there any inside thing in the implementation of server that shuld be changed? Am I naively thinking above not regarding implementation of the server?
On Fri, Feb 28, 2014 at 11:09 PM, Faruk S. Can farukscan@gmail.com wrote:
I have read in w3schools about usage of server sent events in html5. it says:
- Set the "Content-Type" header to "text/event-stream"
- Specify that the page should not cache
- Output the data to send (*Always* start with "data: ")
that is in echo line in php code as echo "data: The server time is: {$time}\n\n";
- Flush the output data back to the web page
http://www.w3schools.com/html/html5_serversentevents.asp examples here are in php for server side. i am using hunchentoot on common lisp.
On Fri, Feb 28, 2014 at 10:27 PM, Faruk S. Can farukscan@gmail.comwrote:
I have another question about hunchentoot. Is it possible to use server sent events with hunchentoot, like other html5 improvements mentioned in w3schools-html5 such as app cache, local storage, session storage? as that one related to and depend on the server side support.
-
Faruk S. Can -
Hans Hübner -
Left Right -
Ron Garret