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]
