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]
>>
>>
>>
>
