Re: [aerogear-dev] How should unified push clients handle HTTP 302?
Hello
It actually reminds me the work done in 3musket33rs project when implementing Cordova
plugin for EventSource support on Android [1].
According to EventSource spec [2], search for "Event stream requests can be
redirected using HTTP 301 and 307 redirects as with normal HTTP requests. Clients will
reconnect if the connection is closed; a client can be told to stop reconnecting using the
HTTP 204 No Content response code."
Could be a way to deal with it.
As Matthias suggested let's follow on JIRA ticket.
Cheers
Corinne
[1]
https://github.com/3musket33rs/BrowserPush/blob/master/src/android/org/th...
[2] http://www.w3.org/TR/eventsource/
On Aug 9, 2013, at 10:44 AM, Matthias Wessendorf <matzew(a)apache.org> wrote:
Hi Karel,
I tested OpenShift as well (with CURL), which lead me to create this JIRA:
https://issues.jboss.org/browse/AGPUSH-240
Right now -> nothing; but some ideas in the above ticket
On Fri, Aug 9, 2013 at 10:16 AM, Karel Piwko <kpiwko(a)redhat.com> wrote:
Hi All,
during testing OpenShift cartridge for Unified Push Server, I've realized that
if cartridge is idle, a request wakes it up and returns HTTP 302, so the
original requests is not processed. The subsequent requests is processed fine,
as expected.
I'm wondering whether we should make this transparent to use client users or
they would need to tread this on their own.
Your thoughts?
Karel
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
--
Matthias Wessendorf
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev
Attachments:
- attachment.html (text/html — 3.5 KB)