cool, thanks!
On Sat, Apr 9, 2011 at 3:55 PM, Raju Bitter <
[email protected]> wrote:
> You can test for yourself with this PHP script:
> <?php
> header("Access-Control-Allow-Origin: http://localhost:8080";);
> header("Content-type: text/xml");
> echo '<?xml version="1.0" encoding="utf-8"?>'
> ?><result>
> <message>OK</message>
> </result>
>
> Put that somewhere on a web server and access the file with a dataset
> in a DHTML app.
>
> On Sat, Apr 9, 2011 at 9:12 PM, Raju Bitter
> <[email protected]> wrote:
> > 1) Origin header
> > Will be sent by browser when making a request to domain different from
> > the one the page was served from.
> >
> > 2) Magic
> > yes, exactly.
> >
> > On Sat, Apr 9, 2011 at 7:01 PM, Henry Minsky <[email protected]>
> wrote:
> >> So I'm not quite clear on the usage here; is the Origin header appended
> >> automatically
> >> by the browser or do we need to add it when we make a request (from a
> laszlo
> >> app)?
> >> Is there anything special we need to do on the laszlo DHTML client app
> side?
> >>
> >> Will this just magically work now with an existing SOLO app if you just
> >> config the server
> >> to send back the Access-control-origin response header?
> >>
> >> On Sat, Apr 9, 2011 at 12:04 PM, Raju Bitter
> >> <[email protected]> wrote:
> >>>
> >>> Yes, it works. For a cross-domain request, the browser sends a
> >>>
> >>> Origin: <SomeURL>, e.g. Origin: http://localhost:8080
> >>>
> >>> header, and the server would respond with an
> >>>
> >>> Access-Control-Allow-Origin: http://localhost:8080
> >>>
> >>> That's all, and it's so easy to configure for Apache, and other
> solutions:
> >>> http://enable-cors.org/
> >>>
> >>> You should really drop support for the proxied mode. The OL proxy
> >>> server made a lot of sense back in 2005/2006, but now - with much
> >>> better media support in Flash and cross-origin resource support in
> >>> Firefox, Safari, Chrome, Webkit, ... - you don't need proxied mode.
> >>> There's always so much confusion around the proxied/non-proxied apps.
> >>> And at the same Laszlo recommends to not use the OL server in
> >>> production mode. That means, we can only use the proxy server when
> >>> testing on development machines. I've had enough situations where I
> >>> had different behavior in apps in SOLO mode compared to proxied mode.
> >>>
> >>> On Mon, Sep 20, 2010 at 6:40 PM, Henry Minsky <[email protected]>
> >>> wrote:
> >>> > I think it will work if the server responds with the right headers to
> >>> > give
> >>> > permission. It looks like more of a pain in the
> >>> > ass than the Flash security protocol, where you only need to put a
> >>> > crossdomain.xml file someplace on the server. With the Cross-Origin
> >>> > Resource Sharing protocol you have to deal with a new request type,
> >>> > "OPTIONS", and supply extra headers in the response. Seems kind of
> >>> > kludgy
> >>> > compared to the Flash solution.
> >>> >
> >>> >
> >>> > On Mon, Sep 20, 2010 at 12:29 PM, P T Withington <[email protected]>
> wrote:
> >>> >>
> >>> >> So, this would work automagically if the server said it was ok? Or
> do
> >>> >> we
> >>> >> need to do something more on the client side to take advantage of
> this?
> >>> >>
> >>> >> On 2010-09-19, at 09:27, Henry Minsky wrote:
> >>> >>
> >>> >> > I was trying to figure out why I was seeing POST requests
> converted
> >>> >> > to
> >>> >> > OPTIONS requests in Firefox and Safari when
> >>> >> > the XMLHTTPRequest was being sent to a "foreign" domain (i.e., a
> >>> >> > security
> >>> >> > violation)
> >>> >> >
> >>> >> > I searched for "OPTIONS" and "POST" and "Firefox" and found this.
> So
> >>> >> > it
> >>> >> > looks like there's a way to configure a server
> >>> >> > to permit cross-domain access (like Flash's crossdomain.xml), to
> >>> >> > compliant
> >>> >> > browsers (which it appears Safari and
> >>> >> > Firefox are, dunno about Opera or IE).
> >>> >> >
> >>> >> >
> >>> >> > https://developer.mozilla.org/en/http_access_control
> >>> >> >
> >>> >> > Overview
> >>> >> >
> >>> >> > The Cross-Origin Resource Sharing standard works by adding new
> HTTP
> >>> >> > headers
> >>> >> > that allow servers to describe the set of origins that are
> permitted
> >>> >> > to
> >>> >> > read
> >>> >> > that information using a web browser. Firefox supports these
> headers
> >>> >> > and
> >>> >> > enforces the restrictions they establish. Additionally, for HTTP
> >>> >> > request
> >>> >> > methods that can cause side-effects on user data (in particular,
> for
> >>> >> > HTTP methods other than GET, or for POST usage with certain MIME
> >>> >> > types),
> >>> >> > the
> >>> >> > specification mandates that browsers "preflight" the request,
> >>> >> > soliciting
> >>> >> > supported methods from the server with an HTTP OPTIONS request
> >>> >> > header,
> >>> >> > and
> >>> >> > then, upon "approval" from the server, sending the actual request
> >>> >> > with
> >>> >> > the
> >>> >> > actual HTTP request method. Servers can also notify clients
> whether
> >>> >> > "credentials" (including Cookies and HTTP Authentication data)
> should
> >>> >> > be
> >>> >> > sent with requests.
> >>> >> >
> >>> >> > Subsequent sections discuss scenarios, as well as a breakdown of
> the
> >>> >> > HTTP
> >>> >> > headers used.
> >>> >> >
> >>> >> >
> >>> >> > --
> >>> >> > Henry Minsky
> >>> >> > Software Architect
> >>> >> > [email protected]
> >>> >>
> >>> >
> >>> >
> >>> >
> >>> > --
> >>> > Henry Minsky
> >>> > Software Architect
> >>> > [email protected]
> >>> >
> >>> >
> >>> >
> >>
> >>
> >>
> >> --
> >> Henry Minsky
> >> Software Architect
> >> [email protected]
> >>
> >>
> >>
> >
>
--
Henry Minsky
Software Architect
[email protected]
