Check this forum discussion: http://forum.openlaszlo.org/showthread.php?p=47363#post47363
That's really useful for the DHTML runtime. ;-) On Thu, Apr 14, 2011 at 12:14 PM, Raju Bitter <[email protected]> wrote: > I've created a JIRA issue where we can start collecting information: > http://jira.openlaszlo.org/jira/browse/LPP-9897 > > On Sat, Apr 9, 2011 at 8:01 PM, Max Carlson <[email protected]> wrote: >> Yes, it should magically work if the server does this. You may have to >> change the client to not try to route through the LPS proxy though... >> On Apr 9, 2011, at 10:01 AM, Henry Minsky 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] >> >> >> >> >
