You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tuscany.apache.org by ant elder <an...@gmail.com> on 2011/07/25 22:16:52 UTC

Cross-Origin Resource Sharing support on the HTTP binding

I've hacked some code together to support Cross-Origin Resource
Sharing (CORS) which is newer replacement to JSONP (which we support
with <binding.jsonp>) and i was wondering what the best place to put
it is. I've tried in binding.http but that is a bit old now and hasn't
really kept  up with all the work in binding.rest, i've added it to
binding.rest too but i don't really like the name REST in that binding
and alll the old RPC function that it includes. So now i wondered if
it was time for something new as we have talked about merging or
replacing binding.http/binding.rest in the past so i wonder if it was
time for something like a binding.jaxrs which has all the good new
bits from binding.rest and http and then CORS could be supported with
something like <binding.jaxrs enableCORS="true"> or maybe even have
CORS enabled by default.

Comments or preferences?

   ...ant

Re: Cross-Origin Resource Sharing support on the HTTP binding

Posted by ant elder <an...@apache.org>.
On Thu, Jul 28, 2011 at 9:05 AM, Florian Moga <mo...@gmail.com> wrote:
> On Thu, Jul 28, 2011 at 10:59 AM, ant elder <an...@apache.org> wrote:
>>
>> I'll go add it as an attribute on binding.rest for now and we can see
>> what thats like. I would quite like to keep it simple without needing
>> extra optional config which is why it would be good to have it enabled
>> by default and to not be something like an optional wireFormat or
>> operationSelector.
>>
>>   ...ant
>
> Sounds good to me.
>
> Florian

I've just committed some minimal code to show how Cross-Origin
Resource Sharing works by setting some Access-Control headers in the
REST binding. To try it out run the
samples/getting-started/helloworld-jaxrs sample with "mvn tuscany:run"
and then in a browser open the standalone web page
samples/getting-started/helloworld-jaxrs/cors.html and click the link.

This code just shows whats needed to get a CORS client running, to do
it more completely we'd need to add support for it to the scdl to
enable/disable the function and perhaps some control of the header
values. I could do that in binding.rest or perhaps in a binding.jaxrs
to keep it more separate from all the old rest support.

   ...ant


   ...ant

Re: Cross-Origin Resource Sharing support on the HTTP binding

Posted by Florian Moga <mo...@gmail.com>.
On Thu, Jul 28, 2011 at 10:59 AM, ant elder <an...@apache.org> wrote:
>
> I'll go add it as an attribute on binding.rest for now and we can see
> what thats like. I would quite like to keep it simple without needing
> extra optional config which is why it would be good to have it enabled
> by default and to not be something like an optional wireFormat or
> operationSelector.
>
>   ...ant
>

Sounds good to me.

Florian

Re: Cross-Origin Resource Sharing support on the HTTP binding

Posted by ant elder <an...@apache.org>.
On Tue, Jul 26, 2011 at 4:55 AM, Luciano Resende <lu...@gmail.com> wrote:
> On Mon, Jul 25, 2011 at 1:16 PM, ant elder <an...@gmail.com> wrote:
>> I've hacked some code together to support Cross-Origin Resource
>> Sharing (CORS) which is newer replacement to JSONP (which we support
>> with <binding.jsonp>) and i was wondering what the best place to put
>> it is. I've tried in binding.http but that is a bit old now and hasn't
>> really kept  up with all the work in binding.rest, i've added it to
>> binding.rest too but i don't really like the name REST in that binding
>> and alll the old RPC function that it includes. So now i wondered if
>> it was time for something new as we have talked about merging or
>> replacing binding.http/binding.rest in the past so i wonder if it was
>> time for something like a binding.jaxrs which has all the good new
>> bits from binding.rest and http and then CORS could be supported with
>> something like <binding.jaxrs enableCORS="true"> or maybe even have
>> CORS enabled by default.
>>
>> Comments or preferences?
>>
>>   ...ant
>>
>
> What is the old RPC stuff that you want to remove from REST ? If you
> are referring for the old Collection support, I'm +1 on cleaning up
> that from REST binding. If you are referring to the different
> operation selectors, then I believe we should leave it there as I have
> couple scenarios that require that functionality.  Having said that, I
> really wouldn't like to create yet a 3rd binding. Is there a way we
> can enable CORS as an optional operationSelector.
>

I'll go add it as an attribute on binding.rest for now and we can see
what thats like. I would quite like to keep it simple without needing
extra optional config which is why it would be good to have it enabled
by default and to not be something like an optional wireFormat or
operationSelector.

   ...ant

Re: Cross-Origin Resource Sharing support on the HTTP binding

Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Jul 25, 2011 at 1:16 PM, ant elder <an...@gmail.com> wrote:
> I've hacked some code together to support Cross-Origin Resource
> Sharing (CORS) which is newer replacement to JSONP (which we support
> with <binding.jsonp>) and i was wondering what the best place to put
> it is. I've tried in binding.http but that is a bit old now and hasn't
> really kept  up with all the work in binding.rest, i've added it to
> binding.rest too but i don't really like the name REST in that binding
> and alll the old RPC function that it includes. So now i wondered if
> it was time for something new as we have talked about merging or
> replacing binding.http/binding.rest in the past so i wonder if it was
> time for something like a binding.jaxrs which has all the good new
> bits from binding.rest and http and then CORS could be supported with
> something like <binding.jaxrs enableCORS="true"> or maybe even have
> CORS enabled by default.
>
> Comments or preferences?
>
>   ...ant
>

What is the old RPC stuff that you want to remove from REST ? If you
are referring for the old Collection support, I'm +1 on cleaning up
that from REST binding. If you are referring to the different
operation selectors, then I believe we should leave it there as I have
couple scenarios that require that functionality.  Having said that, I
really wouldn't like to create yet a 3rd binding. Is there a way we
can enable CORS as an optional operationSelector.

-- 
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/