Raul,

> No - where is your mobile app running from? If you load the html direct
> (or use Cordova/Phonegap) then there is a CORS.

Right - using Phonegap.

> Long term solution i think is for Tim to have EWB web server respond to
> OPTIONS query.

Maybe using a module with an additional response header would help,
that's what I found in Matthew's link:
http://stackoverflow.com/questions/29954037/how-to-disable-options-request

> For now you could just host the EWB app and data from EWB web server as
> a work around - the issue only happens when app and data are loaded from
> different URL's (i.e. CORS)

Yes, that works anyway.

Thanks Raul and Merry Christmas to you and all guys here!

Uli

Uli,

Did you enable CORS in the EWB Web Server ?

http://www.elevatesoft.com/manual?action=viewtopic&id=ewb2&topic=Configuring_Server

"Enable Cross-Origin Resource Sharing" under "Content" section.

The EWB Web Server does respond to OPTIONS requests when this feature is enabled, so you shouldn't see a 30-second wait/timeout on the browser side.

If you *do* have CORS enabled, then I'll pursue it here further and see what the issue is.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

> Did you enable CORS in the EWB Web Server ?

Yes. I just double checked it and yes.

> If you *do* have CORS enabled, then I'll pursue it here further and see what the issue is.

Thank you. If you need a link to debug, just tell me.

Uli

Uli,

<< Yes. I just double checked it and yes. >>

Okay, I'll see if I can replicate what you're seeing.

Tim Young
Elevate Software
www.elevatesoft.com

Uli,

I fixed this issue for 2.06.  The problem is that the OPTIONS request handler in the EWB Web Server isn't setting the content length for the response, and so Chrome is sitting there waiting on data that will never show up.

Tim Young
Elevate Software
www.elevatesoft.com