Sounds like a great idea, and would presumably let us rip a whole bunch of poorly-supported code out of the server.
Who's volunteering? On 2011-04-09, at 17:09, Raju Bitter wrote: > Actually that would be very cool, to get rid of the "proxied" > functionality. Makes things a lot easier, in my eyes. Consistent app > behavior when testing local apps with remote backends and when the app > is deployed on the same domain as the backend is. Many people seem to > be confused by the proxy server, since they want to deploy their apps > with the OL server running in production. > > On Sat, Apr 9, 2011 at 10:35 PM, Joseph Silverman > <[email protected]> wrote: >> Read all about it at https://developer.mozilla.org/en/http_access_control - >> crossdomain.xml for dhtml, and so much more. >> On Apr 9, 2011, at 1:29 PM, Henry Minsky wrote: >> >> 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] >> >> >> >>
