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/threemusketeers/eventsource/EventSourceHandshaker.java#L43
[2] http://www.w3.org/TR/eventsource/


On Aug 9, 2013, at 10:44 AM, Matthias Wessendorf <matzew@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@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@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev