Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of iclelland@google.com designates
 209.85.214.170 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAEeF2TdEhKb9c0ZegZqTEsChMYUThNV=Fw21UUif5BKzUwKWfg@mail.gmail.com>
References: 
 <CABiQX1U81M=L_GbHktdfH_uj46eRpYe6hBx0p1SHjgTCCaD2xg@mail.gmail.com>
	<CAOBL_k4fL9viwQQh+wAKEpC0Qp_9yp=6k7=p9s5Rr6qW40cHfw@mail.gmail.com>
	<CABiQX1WrNEJsG5V8e3S6kUgFvgBE0qbNeue+4Ymn8KeOUy+x6A@mail.gmail.com>
	<CAP7NMPpnurkx6OwSFCsFvph9ZuwYX1=SzrQe+Ki07+qqQ+_raw@mail.gmail.com>
	<CAEeF2TdEhKb9c0ZegZqTEsChMYUThNV=Fw21UUif5BKzUwKWfg@mail.gmail.com>
Date: Wed, 17 Apr 2013 14:41:24 -0400
Message-ID: 
 <CAK_TSXKORGzazu9kW7D-35mYPEgQ=D2H29SCTJVtWRizkrGegQ@mail.gmail.com>
Subject: Re: Making WebView's WebSQL work on Android 3.0+
From: Ian Clelland <iclelland@google.com>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=089e013a26963af29804da92d5c5

--089e013a26963af29804da92d5c5
Content-Type: text/plain; charset=UTF-8

Specifically with iOS, setting the start page to a chrome-extension:// url
causes the underlying UIWebView to apply CORS policies to all XHR requests.

UIWebView seems to use the same restrictions as desktop Safari:
   - Requests coming from file:/// urls do not use the Origin header
   - Requests coming from other schemes (such as chrome-extension://) have
an Origin header applied, and the UIWebView validates the Access-Control-*
headers in the response.

In practice, this means that when we make an XHR to an origin server which
doesn't support CORS, the response is rejected by the UIWebView, and the
XHR completes with an error.

(I'm looking at a couple of ways to work around this; hopefully we don't
have to go as far as replacing the HTTP stack on iOS now, too)

Ian


On Wed, Apr 17, 2013 at 1:34 PM, Michal Mocny <mmocny@chromium.org> wrote:

> Ian has been running into some issues with CORS while working on porting an
> app, I'll let him comment on specifics.
>
>
> On Wed, Apr 17, 2013 at 12:27 PM, Michael Brooks
> <michael@michaelbrooks.ca>wrote:
>
> > Very cool Andrew. Does this affect the cross-origin policy? Many users
> > exploit the ability to make requests across multiple domains.
> >
> > Michael
> >
> >
> > On Wed, Apr 17, 2013 at 8:35 AM, Andrew Grieve <agrieve@chromium.org>
> > wrote:
> >
> > > Just tried it with:
> > >
> > > chrome-extension://asdf/chromeapp.html?foo:1?#asdf?ds#af:s
> > >
> > > Had to make a slight tweak to IceCreamCordovaWebViewClient, but it
> worked
> > > fine.
> > >
> > >
> > > On Wed, Apr 17, 2013 at 12:39 AM, Joe Bowser <bowserj@gmail.com>
> wrote:
> > >
> > > > How does this affect URI handling?  We've had far bigger issues with
> > > > file:///android-asset failing on ICS+.  Did you test with URIs that
> > > contain
> > > > a question mark, pound or a colon?
> > > >
> > > > On Apr 16, 2013 7:23 PM, "Andrew Grieve" <agrieve@chromium.org>
> wrote:
> > > >
> > > >> Found a juicy hack that works around the webview disabling WebSQL
> for
> > > >> file: URLs.
> > > >>
> > > >> For our Chrome Apps plugins, we serve apps from chrome-extension://
> > URLs
> > > >> instead of file:// URLs. This is possible via
> > shouldInterceptRequest(),
> > > >> where we just map the requests to the files.
> > > >>
> > > >> So... I had the idea to test the WebSQL mobile-spec tests under this
> > > >> scheme (while disabling Android's custom WebSQL work-around), and it
> > > seemed
> > > >> to work fine.
> > > >>
> > > >> I think that this means that we could change Cordova app urls to be
> > > >> cordova:// (for ICS+), and could then delete the storage plugin.
> > > >>
> > > >> What do you think?
> > > >>
> > > >
> > >
> >
>

--089e013a26963af29804da92d5c5--