-
-
Notifications
You must be signed in to change notification settings - Fork 1.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Feature Discussion] Adding SSE requests to Slim #1959
Comments
Could you provide links to any explanatory texts for what they are, in your understanding? It sounds interesting. |
SSE's basically create a socket like request over HTTP, however the connection doesn't close unless you ask it to be closed, if the browser hears it close it automatically reopens the connection to begin listening again. They are an HTML5 alternative to web sockets, long polling and short polling, some may say they are still polling but with the added extra of having the browser handle them instead of the developer. if you open the browsers dev tools and reload the example, you will see the request to stocks.php and the request doesn't have a http response but instead it has a eventstream auto updating with the data it receives from the server. Example: (Uses SSE to update stocks live) Information / Tutorials: EDIT: Additional link with spec information and a note NOTE: IE doesn't support EventSource so the Slim endpoint for SSE will need to also allow for a fallback, http://stackoverflow.com/questions/24498141/is-there-a-microsoft-equivalent-for-html5-server-sent-events |
Thanks for the context, it will help the discussion a lot! |
Since they are just plain old HTTP it is possible already to serve SSEs with Slim. Let's assume you have the following JavaScript. var source = new EventSource("/events");
source.onmessage = function(event) {
console.log(event.data);
}; Simple SSE route would look like this. $app->get("/events", function ($request, $response, $arguments) {
$data = time();
return $response
->withHeader("Content-Type", "text/event-stream")
->withHeader("Cache-Control", "no-cache")
->write("data: {$data}\n\n");
}); However this closes the connection and it makes It is possible to make the $app->get("/events-loop", function ($request, $response, $arguments) {
header("Content-Type: text/event-stream");
header("Cache-Control: no-cache");
ob_end_clean();
ob_implicit_flush();
while (true) {
$data = time();
print "data: {$data}\n\n";
usleep(1000000);
}
}); You also need to turn off PHP buffering in
|
Just wanted to see if this should be considered for the v4.0 milestone or not, I would like to see this be a built-in feature of version 4 so developers can use SSE's without much work to get it working, something Slim is really good at, writing little but being able to do a lot. What are everyones thoughts on including this in the v4.0 milestone? Edit: one solution ca be found here ... http://discourse.slimframework.com/t/how-to-use-html5-server-sent-events-sse/879/5 |
You have my vote |
I suspect that this would be solved id #2481 is implemented? |
Yep. Thx.
…On Sun, 16 Sep 2018, 14:21 Rob Allen, ***@***.***> wrote:
I suspect that this would be solved id #2481
<#2481> is implemented?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1959 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AKyv8-Rg4PNlSH3bYjyp1FaRq4pDs-Usks5ubkJlgaJpZM4Jj5Tn>
.
|
Closing in favour of #2481. |
I wanted to start a discussion about if SSE (Server Sent Events) would be a nice addition to Slim, if it would be useful enough to even think about adding or even possible to add.
I recently had a project which needed server bound event triggers, I wasn't able to use Node which for this kind of project I would tend to use and I didn't want to use polling, sort or long, so I chose to use SSE to handle the page updates.
With this project I used Slim, however the SSE endpoints were not able to be used within a Slim response.
What are everyones thoughts on this, would it be nice to allow SSE requests / responses, these requests aren't like standard open and close requests so not sure how they fall in the PSR-7 standard.
The text was updated successfully, but these errors were encountered: