Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Joseph Fonseka]

Hi Colin

On Sat, Jan 24, 2015 at 11:05 PM, Colin Roy-Ehri  wrote:

> One elegant solution would be to have the default /* resources not include
> the OPTIONS method.  In the absence of an explicitly defined api OPTIONS
> resource, of course an app calling OPTIONS should return the methods
> defined in the API.
>
+1 that is more elegant, going bit further we can respond to OPTIONS from
the gateway by default and if OPTIONS method it selected it will be send to
back-end.

Then we have to modify the UI so that users will only select OPTIONS it if
they absolutely want it.

Regards
Jo







> I look forward to having CORS work better with this kind of enhancement.
> :)
>
> -Colin
> On Jan 24, 2015 3:20 AM, "Isuru Udana"  wrote:
>
>> Hi All,
>>
>> Following statement is extracted from the spec[1]
>>
>> "If no Max-Forwards field is present in the request, then the forwarded
>> request MUST NOT include a Max-Forwards field."
>>
>> So according to this, if the header is not present, request can be
>> forward to the backend. But it doesn't clearly say whether we must forward
>> the request or not. But it is more natural to forward the request rather
>> blocking it as this is an optional header.
>>
>> I'm not sure how good it is to have a global property to control this as
>> it will affect all the APIs in the server (For most of the APIs, request
>> might need to be forwarded to backend in absence of this header)
>> Can we do this at the synapse configuration level without altering the
>> synapse code ?
>>
>> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>
>> Thanks.
>>
>> On Tue, Jan 13, 2015 at 3:25 PM, Amila De Silva  wrote:
>>
>>> Doing this as a mediation extension would make it more re-usable IMO.
>>>
>>> On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara  wrote:
>>>
 On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:

> Ok, so I think we need to have a property which can be
> enabled/disabled. This property decides whether the OPTIONS request should
> be forwarded to the back-end or not. Whenever the Max-Forwards header is
> not present in the request, this property gets prominence. When present,
> Max-Forwards get prominence.
>
> And I think this needs to be done at the Synapse level rather than
> handling at an API Manager handler level.
>

 +1 including this in the Synapse level makes good sense.

>
> Thanks,
> NuwanD.
>
> On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka 
> wrote:
>
>> Hi
>>
>> @Amila
>> For options call we can respond per API basis, based on the HTTP
>> methods defined in the API. And those methods can be sent via "Allow"
>> header. Also the same methods can be sent in CORS headers too.
>>
>> @Nuwan
>> Yes the Max-Forwards is the problem and according to the spec it is
>> to be honored by proxy servers. But API Gateway is more of an API facade
>> which does masking so shouldn't it be hiding internal implementation
>> details from outside ? (Ex the implemented methods in the back-end 
>> server).
>> If so then we should not send the OPTIONS call to the back-end.
>>
>> @Ruwan
>> IMO we should return the OPTIONS call from Gateway also in ESB if the
>> Max-Forwards is set to 0 it will return before hitting the in sequence.
>>
>> Thanks
>> Jo
>>
>>
>>
>>
>>
>> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara 
>> wrote:
>>
>>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias 
>>> wrote:
>>>


 On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
 wrote:

>
> Hi
>
> Currently in API Manager we send the OPTIONS call to the back-end
> server to respond. But if the API does not expose all the HTTP 
> methods in
> back-end, OPTIONS call response will be invalid.
>
> 1. Should we respond to the OPTIONS call from the gateway with the
> Allow header including only the HTTP methods exposed by the API.
>
> 2. If we are doing above should we give an option to the user to
> override in case if he want to send it to back-end.
>

 Whether the OPTIONS call goes to the back-end or not is dominated
 by the Max-Forwards header. According to the spec [1], it seems like 
 the
 request should be forwarded when the Max-Forwards header is not 
 present.

>>>
>>> First of all +1, but since we are implicitly enabling OPTIONS for
>>> the API, and we are including a property that can be configured by the
>>> users if they to enable sending options call to the back end (Which by 
>>> the
>>> way needs to be a configuration that can be done on a per API basis, i
>>> believe), should we not introduce the Max-Forward : 0 header when
>>> intercepting the options call at the gate

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Colin Roy-Ehri]

I agree that an OPTIONS request should not expose backend service methods,
and should in most cases not be sent to the backend.  In some customer
cases, such as I saw in New Zealand,  customers require the OPTIONS call to
be passes through to the backend for a response.

One elegant solution would be to have the default /* resources not include
the OPTIONS method.  In the absence of an explicitly defined api OPTIONS
resource, of course an app calling OPTIONS should return the methods
defined in the API.

I look forward to having CORS work better with this kind of enhancement.  :)

-Colin
On Jan 24, 2015 3:20 AM, "Isuru Udana"  wrote:

> Hi All,
>
> Following statement is extracted from the spec[1]
>
> "If no Max-Forwards field is present in the request, then the forwarded
> request MUST NOT include a Max-Forwards field."
>
> So according to this, if the header is not present, request can be forward
> to the backend. But it doesn't clearly say whether we must forward the
> request or not. But it is more natural to forward the request rather
> blocking it as this is an optional header.
>
> I'm not sure how good it is to have a global property to control this as
> it will affect all the APIs in the server (For most of the APIs, request
> might need to be forwarded to backend in absence of this header)
> Can we do this at the synapse configuration level without altering the
> synapse code ?
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>
> Thanks.
>
> On Tue, Jan 13, 2015 at 3:25 PM, Amila De Silva  wrote:
>
>> Doing this as a mediation extension would make it more re-usable IMO.
>>
>> On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara  wrote:
>>
>>> On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:
>>>
 Ok, so I think we need to have a property which can be
 enabled/disabled. This property decides whether the OPTIONS request should
 be forwarded to the back-end or not. Whenever the Max-Forwards header is
 not present in the request, this property gets prominence. When present,
 Max-Forwards get prominence.

 And I think this needs to be done at the Synapse level rather than
 handling at an API Manager handler level.

>>>
>>> +1 including this in the Synapse level makes good sense.
>>>

 Thanks,
 NuwanD.

 On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka 
 wrote:

> Hi
>
> @Amila
> For options call we can respond per API basis, based on the HTTP
> methods defined in the API. And those methods can be sent via "Allow"
> header. Also the same methods can be sent in CORS headers too.
>
> @Nuwan
> Yes the Max-Forwards is the problem and according to the spec it is to
> be honored by proxy servers. But API Gateway is more of an API facade 
> which
> does masking so shouldn't it be hiding internal implementation details 
> from
> outside ? (Ex the implemented methods in the back-end server). If so then
> we should not send the OPTIONS call to the back-end.
>
> @Ruwan
> IMO we should return the OPTIONS call from Gateway also in ESB if the
> Max-Forwards is set to 0 it will return before hitting the in sequence.
>
> Thanks
> Jo
>
>
>
>
>
> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara 
> wrote:
>
>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
>>> wrote:
>>>

 Hi

 Currently in API Manager we send the OPTIONS call to the back-end
 server to respond. But if the API does not expose all the HTTP methods 
 in
 back-end, OPTIONS call response will be invalid.

 1. Should we respond to the OPTIONS call from the gateway with the
 Allow header including only the HTTP methods exposed by the API.

 2. If we are doing above should we give an option to the user to
 override in case if he want to send it to back-end.

>>>
>>> Whether the OPTIONS call goes to the back-end or not is dominated by
>>> the Max-Forwards header. According to the spec [1], it seems like the
>>> request should be forwarded when the Max-Forwards header is not present.
>>>
>>
>> First of all +1, but since we are implicitly enabling OPTIONS for the
>> API, and we are including a property that can be configured by the users 
>> if
>> they to enable sending options call to the back end (Which by the way 
>> needs
>> to be a configuration that can be done on a per API basis, i believe),
>> should we not introduce the Max-Forward : 0 header when intercepting the
>> options call at the gateway? and sending it back. Or should just the drop
>> the message and respond back, with the allow origin headers and what not?
>>
>>>
 3. Is there a valid requirement to show the OPTIONS method in AP

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Isuru Udana]

Hi All,

Following statement is extracted from the spec[1]

"If no Max-Forwards field is present in the request, then the forwarded
request MUST NOT include a Max-Forwards field."

So according to this, if the header is not present, request can be forward
to the backend. But it doesn't clearly say whether we must forward the
request or not. But it is more natural to forward the request rather
blocking it as this is an optional header.

I'm not sure how good it is to have a global property to control this as it
will affect all the APIs in the server (For most of the APIs, request might
need to be forwarded to backend in absence of this header)
Can we do this at the synapse configuration level without altering the
synapse code ?

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

Thanks.

On Tue, Jan 13, 2015 at 3:25 PM, Amila De Silva  wrote:

> Doing this as a mediation extension would make it more re-usable IMO.
>
> On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara  wrote:
>
>> On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:
>>
>>> Ok, so I think we need to have a property which can be enabled/disabled.
>>> This property decides whether the OPTIONS request should be forwarded to
>>> the back-end or not. Whenever the Max-Forwards header is not present in the
>>> request, this property gets prominence. When present, Max-Forwards get
>>> prominence.
>>>
>>> And I think this needs to be done at the Synapse level rather than
>>> handling at an API Manager handler level.
>>>
>>
>> +1 including this in the Synapse level makes good sense.
>>
>>>
>>> Thanks,
>>> NuwanD.
>>>
>>> On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka  wrote:
>>>
 Hi

 @Amila
 For options call we can respond per API basis, based on the HTTP
 methods defined in the API. And those methods can be sent via "Allow"
 header. Also the same methods can be sent in CORS headers too.

 @Nuwan
 Yes the Max-Forwards is the problem and according to the spec it is to
 be honored by proxy servers. But API Gateway is more of an API facade which
 does masking so shouldn't it be hiding internal implementation details from
 outside ? (Ex the implemented methods in the back-end server). If so then
 we should not send the OPTIONS call to the back-end.

 @Ruwan
 IMO we should return the OPTIONS call from Gateway also in ESB if the
 Max-Forwards is set to 0 it will return before hitting the in sequence.

 Thanks
 Jo





 On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara 
 wrote:

> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
>> wrote:
>>
>>>
>>> Hi
>>>
>>> Currently in API Manager we send the OPTIONS call to the back-end
>>> server to respond. But if the API does not expose all the HTTP methods 
>>> in
>>> back-end, OPTIONS call response will be invalid.
>>>
>>> 1. Should we respond to the OPTIONS call from the gateway with the
>>> Allow header including only the HTTP methods exposed by the API.
>>>
>>> 2. If we are doing above should we give an option to the user to
>>> override in case if he want to send it to back-end.
>>>
>>
>> Whether the OPTIONS call goes to the back-end or not is dominated by
>> the Max-Forwards header. According to the spec [1], it seems like the
>> request should be forwarded when the Max-Forwards header is not present.
>>
>
> First of all +1, but since we are implicitly enabling OPTIONS for the
> API, and we are including a property that can be configured by the users 
> if
> they to enable sending options call to the back end (Which by the way 
> needs
> to be a configuration that can be done on a per API basis, i believe),
> should we not introduce the Max-Forward : 0 header when intercepting the
> options call at the gateway? and sending it back. Or should just the drop
> the message and respond back, with the allow origin headers and what not?
>
>>
>>> 3. Is there a valid requirement to show the OPTIONS method in API
>>> Design phase, shouldn't it be enabled by default.
>>>
>> +1
>>
> +1
>
>>
>> [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>
>>>
>>> Thanks
>>> Jo
>>>
>>> Related
>>> https://wso2.org/jira/browse/APIMANAGER-1704
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *Joseph Fonseka*
>>>  WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>

[Architecture] Should the OPTIONS call be terminated at the API gateway.

[Joseph Fonseka]

Hi

Currently in API Manager we send the OPTIONS call to the back-end server to
respond. But if the API does not expose all the HTTP methods in back-end,
OPTIONS call response will be invalid.

1. Should we respond to the OPTIONS call from the gateway with the Allow
header including only the HTTP methods exposed by the API.

2. If we are doing above should we give an option to the user to override
in case if he want to send it to back-end.

3. Is there a valid requirement to show the OPTIONS method in API Design
phase, shouldn't it be enabled by default.

Thanks
Jo

Related
https://wso2.org/jira/browse/APIMANAGER-1704







-- 
*Joseph Fonseka*
 WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Joseph Fonseka]

Hi

@Amila
For options call we can respond per API basis, based on the HTTP methods
defined in the API. And those methods can be sent via "Allow" header. Also
the same methods can be sent in CORS headers too.

@Nuwan
Yes the Max-Forwards is the problem and according to the spec it is to be
honored by proxy servers. But API Gateway is more of an API facade which
does masking so shouldn't it be hiding internal implementation details from
outside ? (Ex the implemented methods in the back-end server). If so then
we should not send the OPTIONS call to the back-end.

@Ruwan
IMO we should return the OPTIONS call from Gateway also in ESB if the
Max-Forwards is set to 0 it will return before hitting the in sequence.

Thanks
Jo





On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara  wrote:

> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>
>>
>>
>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka  wrote:
>>
>>>
>>> Hi
>>>
>>> Currently in API Manager we send the OPTIONS call to the back-end server
>>> to respond. But if the API does not expose all the HTTP methods in
>>> back-end, OPTIONS call response will be invalid.
>>>
>>> 1. Should we respond to the OPTIONS call from the gateway with the Allow
>>> header including only the HTTP methods exposed by the API.
>>>
>>> 2. If we are doing above should we give an option to the user to
>>> override in case if he want to send it to back-end.
>>>
>>
>> Whether the OPTIONS call goes to the back-end or not is dominated by the
>> Max-Forwards header. According to the spec [1], it seems like the request
>> should be forwarded when the Max-Forwards header is not present.
>>
>
> First of all +1, but since we are implicitly enabling OPTIONS for the API,
> and we are including a property that can be configured by the users if they
> to enable sending options call to the back end (Which by the way needs to
> be a configuration that can be done on a per API basis, i believe), should
> we not introduce the Max-Forward : 0 header when intercepting the options
> call at the gateway? and sending it back. Or should just the drop the
> message and respond back, with the allow origin headers and what not?
>
>>
>>> 3. Is there a valid requirement to show the OPTIONS method in API Design
>>> phase, shouldn't it be enabled by default.
>>>
>> +1
>>
> +1
>
>>
>> [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>
>>>
>>> Thanks
>>> Jo
>>>
>>> Related
>>> https://wso2.org/jira/browse/APIMANAGER-1704
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *Joseph Fonseka*
>>>  WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>
>


-- 

-- 
*Joseph Fonseka*
 WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Sanjeewa Malalgoda]

On Wed, Jan 14, 2015 at 8:33 AM, Lakmali Baminiwatta 
wrote:

> Hi,
>
> On 14 January 2015 at 00:32, Joseph Fonseka  wrote:
>
>> Hi
>>
>> With related to CORS the headers they should be set in the gateway as
>> well since we are configuring CORS in gateway so the headers should be as
>> the configuration of the gateway not the back-end.
>>
> +1.

>
> +1. OPTIONS verb exposed through API Gateway should return the supported
> headers of the relevant resource in the API Gateway. If the back-end
> supports all the HTTP verbs, but mapped API resource only supports GET,
> then returning allowed methods of the back-end in not correct.
>
>
> Thanks,
> Lakmali
>
>>
>> Also we can capture allowed domains per API basis. Allowed methods and
>> headers are already captured in API definition.
>>
>> Regards
>> Jo
>>
>> On Tue, Jan 13, 2015 at 3:37 PM, Sanjeewa Malalgoda 
>> wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
>>> wrote:
>>>

 Hi

 Currently in API Manager we send the OPTIONS call to the back-end
 server to respond. But if the API does not expose all the HTTP methods in
 back-end, OPTIONS call response will be invalid.

 1. Should we respond to the OPTIONS call from the gateway with the
 Allow header including only the HTTP methods exposed by the API.

>>> When we consider CORS use cases preflight call happens as OPTIONS call.
>>> So shouldn't we pass them to back end without doing something in gateway?
>>> IMO this should be configurable via some kind of configuration. And it
>>> would be ideal if we can do this per API level without having global
>>> parameter to all APIs in system
>>>
>>> Thanks,
>>> sanjeewa.
>>>

 2. If we are doing above should we give an option to the user to
 override in case if he want to send it to back-end.

 3. Is there a valid requirement to show the OPTIONS method in API
 Design phase, shouldn't it be enabled by default.

 Thanks
 Jo

 Related
 https://wso2.org/jira/browse/APIMANAGER-1704







 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * *


>>>
>>>
>>> --
>>>
>>> *Sanjeewa Malalgoda*
>>> WSO2 Inc.
>>> Mobile : +94713068779
>>>
>>>  blog
>>> :http://sanjeewamalalgoda.blogspot.com/
>>> 
>>>
>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>>  WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
> Lakmali Baminiwatta
>  Senior Software Engineer
> WSO2, Inc.: http://wso2.com
> lean.enterprise.middleware
> mobile:  +94 71 2335936
> blog : lakmali.com
>
>


-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

 blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Lakmali Baminiwatta]

Hi,

On 14 January 2015 at 00:32, Joseph Fonseka  wrote:

> Hi
>
> With related to CORS the headers they should be set in the gateway as well
> since we are configuring CORS in gateway so the headers should be as the
> configuration of the gateway not the back-end.
>

+1. OPTIONS verb exposed through API Gateway should return the supported
headers of the relevant resource in the API Gateway. If the back-end
supports all the HTTP verbs, but mapped API resource only supports GET,
then returning allowed methods of the back-end in not correct.


Thanks,
Lakmali

>
> Also we can capture allowed domains per API basis. Allowed methods and
> headers are already captured in API definition.
>
> Regards
> Jo
>
> On Tue, Jan 13, 2015 at 3:37 PM, Sanjeewa Malalgoda 
> wrote:
>
>>
>>
>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka  wrote:
>>
>>>
>>> Hi
>>>
>>> Currently in API Manager we send the OPTIONS call to the back-end server
>>> to respond. But if the API does not expose all the HTTP methods in
>>> back-end, OPTIONS call response will be invalid.
>>>
>>> 1. Should we respond to the OPTIONS call from the gateway with the Allow
>>> header including only the HTTP methods exposed by the API.
>>>
>> When we consider CORS use cases preflight call happens as OPTIONS call.
>> So shouldn't we pass them to back end without doing something in gateway?
>> IMO this should be configurable via some kind of configuration. And it
>> would be ideal if we can do this per API level without having global
>> parameter to all APIs in system
>>
>> Thanks,
>> sanjeewa.
>>
>>>
>>> 2. If we are doing above should we give an option to the user to
>>> override in case if he want to send it to back-end.
>>>
>>> 3. Is there a valid requirement to show the OPTIONS method in API Design
>>> phase, shouldn't it be enabled by default.
>>>
>>> Thanks
>>> Jo
>>>
>>> Related
>>> https://wso2.org/jira/browse/APIMANAGER-1704
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> --
>>> *Joseph Fonseka*
>>>  WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>>
>> *Sanjeewa Malalgoda*
>> WSO2 Inc.
>> Mobile : +94713068779
>>
>>  blog
>> :http://sanjeewamalalgoda.blogspot.com/
>> 
>>
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
>  WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 
Lakmali Baminiwatta
 Senior Software Engineer
WSO2, Inc.: http://wso2.com
lean.enterprise.middleware
mobile:  +94 71 2335936
blog : lakmali.com
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Joseph Fonseka]

Hi

With related to CORS the headers they should be set in the gateway as well
since we are configuring CORS in gateway so the headers should be as the
configuration of the gateway not the back-end.

Also we can capture allowed domains per API basis. Allowed methods and
headers are already captured in API definition.

Regards
Jo

On Tue, Jan 13, 2015 at 3:37 PM, Sanjeewa Malalgoda 
wrote:

>
>
> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka  wrote:
>
>>
>> Hi
>>
>> Currently in API Manager we send the OPTIONS call to the back-end server
>> to respond. But if the API does not expose all the HTTP methods in
>> back-end, OPTIONS call response will be invalid.
>>
>> 1. Should we respond to the OPTIONS call from the gateway with the Allow
>> header including only the HTTP methods exposed by the API.
>>
> When we consider CORS use cases preflight call happens as OPTIONS call. So
> shouldn't we pass them to back end without doing something in gateway? IMO
> this should be configurable via some kind of configuration. And it would be
> ideal if we can do this per API level without having global parameter to
> all APIs in system
>
> Thanks,
> sanjeewa.
>
>>
>> 2. If we are doing above should we give an option to the user to override
>> in case if he want to send it to back-end.
>>
>> 3. Is there a valid requirement to show the OPTIONS method in API Design
>> phase, shouldn't it be enabled by default.
>>
>> Thanks
>> Jo
>>
>> Related
>> https://wso2.org/jira/browse/APIMANAGER-1704
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Joseph Fonseka*
>>  WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
>  blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>


-- 

-- 
*Joseph Fonseka*
 WSO2 Inc.; http://wso2.com
lean.enterprise.middleware

mobile: +94 772 512 430
skype: jpfonseka

* *
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Sanjeewa Malalgoda]

On Tue, Jan 13, 2015 at 3:37 PM, Sanjeewa Malalgoda 
wrote:

>
>
> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka  wrote:
>
>>
>> Hi
>>
>> Currently in API Manager we send the OPTIONS call to the back-end server
>> to respond. But if the API does not expose all the HTTP methods in
>> back-end, OPTIONS call response will be invalid.
>>
>> 1. Should we respond to the OPTIONS call from the gateway with the Allow
>> header including only the HTTP methods exposed by the API.
>>
> When we consider CORS use cases preflight call happens as OPTIONS call. So
> shouldn't we pass them to back end without doing something in gateway? IMO
> this should be configurable via some kind of configuration. And it would be
> ideal if we can do this per API level without having global parameter to
> all APIs in system
>
> Thanks,
> sanjeewa.
>
>>
>> 2. If we are doing above should we give an option to the user to override
>> in case if he want to send it to back-end.
>>
>> 3. Is there a valid requirement to show the OPTIONS method in API Design
>> phase, shouldn't it be enabled by default.
>>
>> Thanks
>> Jo
>>
>> Related
>> https://wso2.org/jira/browse/APIMANAGER-1704
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Joseph Fonseka*
>>  WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
>  blog
> :http://sanjeewamalalgoda.blogspot.com/
> 
>
>
>


-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

 blog
:http://sanjeewamalalgoda.blogspot.com/

___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Amila De Silva]

Doing this as a mediation extension would make it more re-usable IMO.

On Tue, Jan 13, 2015 at 3:10 PM, Ruwan Yatawara  wrote:

> On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:
>
>> Ok, so I think we need to have a property which can be enabled/disabled.
>> This property decides whether the OPTIONS request should be forwarded to
>> the back-end or not. Whenever the Max-Forwards header is not present in the
>> request, this property gets prominence. When present, Max-Forwards get
>> prominence.
>>
>> And I think this needs to be done at the Synapse level rather than
>> handling at an API Manager handler level.
>>
>
> +1 including this in the Synapse level makes good sense.
>
>>
>> Thanks,
>> NuwanD.
>>
>> On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka  wrote:
>>
>>> Hi
>>>
>>> @Amila
>>> For options call we can respond per API basis, based on the HTTP methods
>>> defined in the API. And those methods can be sent via "Allow" header. Also
>>> the same methods can be sent in CORS headers too.
>>>
>>> @Nuwan
>>> Yes the Max-Forwards is the problem and according to the spec it is to
>>> be honored by proxy servers. But API Gateway is more of an API facade which
>>> does masking so shouldn't it be hiding internal implementation details from
>>> outside ? (Ex the implemented methods in the back-end server). If so then
>>> we should not send the OPTIONS call to the back-end.
>>>
>>> @Ruwan
>>> IMO we should return the OPTIONS call from Gateway also in ESB if the
>>> Max-Forwards is set to 0 it will return before hitting the in sequence.
>>>
>>> Thanks
>>> Jo
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara  wrote:
>>>
 On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:

>
>
> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
> wrote:
>
>>
>> Hi
>>
>> Currently in API Manager we send the OPTIONS call to the back-end
>> server to respond. But if the API does not expose all the HTTP methods in
>> back-end, OPTIONS call response will be invalid.
>>
>> 1. Should we respond to the OPTIONS call from the gateway with the
>> Allow header including only the HTTP methods exposed by the API.
>>
>> 2. If we are doing above should we give an option to the user to
>> override in case if he want to send it to back-end.
>>
>
> Whether the OPTIONS call goes to the back-end or not is dominated by
> the Max-Forwards header. According to the spec [1], it seems like the
> request should be forwarded when the Max-Forwards header is not present.
>

 First of all +1, but since we are implicitly enabling OPTIONS for the
 API, and we are including a property that can be configured by the users if
 they to enable sending options call to the back end (Which by the way needs
 to be a configuration that can be done on a per API basis, i believe),
 should we not introduce the Max-Forward : 0 header when intercepting the
 options call at the gateway? and sending it back. Or should just the drop
 the message and respond back, with the allow origin headers and what not?

>
>> 3. Is there a valid requirement to show the OPTIONS method in API
>> Design phase, shouldn't it be enabled by default.
>>
> +1
>
 +1

>
> [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>
>>
>> Thanks
>> Jo
>>
>> Related
>> https://wso2.org/jira/browse/APIMANAGER-1704
>>
>>
>>
>>
>>
>>
>>
>> --
>> *Joseph Fonseka*
>>  WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
> Nuwan Dias
>
> Associate Tech Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>


>>>
>>>
>>> --
>>>
>>> --
>>> *Joseph Fonseka*
>>>  WSO2 Inc.; http://wso2.com
>>> lean.enterprise.middleware
>>>
>>> mobile: +94 772 512 430
>>> skype: jpfonseka
>>>
>>> * *
>>>
>>>
>>
>>
>> --
>> Nuwan Dias
>>
>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>> email : nuw...@wso2.com
>> Phone : +94 777 775 729
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Amila De Silva*

WSO2 Inc.
mobile :(+94) 775119302
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Ruwan Yatawara]

On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias  wrote:

> Ok, so I think we need to have a property which can be enabled/disabled.
> This property decides whether the OPTIONS request should be forwarded to
> the back-end or not. Whenever the Max-Forwards header is not present in the
> request, this property gets prominence. When present, Max-Forwards get
> prominence.
>
> And I think this needs to be done at the Synapse level rather than
> handling at an API Manager handler level.
>

+1 including this in the Synapse level makes good sense.

>
> Thanks,
> NuwanD.
>
> On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka  wrote:
>
>> Hi
>>
>> @Amila
>> For options call we can respond per API basis, based on the HTTP methods
>> defined in the API. And those methods can be sent via "Allow" header. Also
>> the same methods can be sent in CORS headers too.
>>
>> @Nuwan
>> Yes the Max-Forwards is the problem and according to the spec it is to be
>> honored by proxy servers. But API Gateway is more of an API facade which
>> does masking so shouldn't it be hiding internal implementation details from
>> outside ? (Ex the implemented methods in the back-end server). If so then
>> we should not send the OPTIONS call to the back-end.
>>
>> @Ruwan
>> IMO we should return the OPTIONS call from Gateway also in ESB if the
>> Max-Forwards is set to 0 it will return before hitting the in sequence.
>>
>> Thanks
>> Jo
>>
>>
>>
>>
>>
>> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara  wrote:
>>
>>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>>>


 On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
 wrote:

>
> Hi
>
> Currently in API Manager we send the OPTIONS call to the back-end
> server to respond. But if the API does not expose all the HTTP methods in
> back-end, OPTIONS call response will be invalid.
>
> 1. Should we respond to the OPTIONS call from the gateway with the
> Allow header including only the HTTP methods exposed by the API.
>
> 2. If we are doing above should we give an option to the user to
> override in case if he want to send it to back-end.
>

 Whether the OPTIONS call goes to the back-end or not is dominated by
 the Max-Forwards header. According to the spec [1], it seems like the
 request should be forwarded when the Max-Forwards header is not present.

>>>
>>> First of all +1, but since we are implicitly enabling OPTIONS for the
>>> API, and we are including a property that can be configured by the users if
>>> they to enable sending options call to the back end (Which by the way needs
>>> to be a configuration that can be done on a per API basis, i believe),
>>> should we not introduce the Max-Forward : 0 header when intercepting the
>>> options call at the gateway? and sending it back. Or should just the drop
>>> the message and respond back, with the allow origin headers and what not?
>>>

> 3. Is there a valid requirement to show the OPTIONS method in API
> Design phase, shouldn't it be enabled by default.
>
 +1

>>> +1
>>>

 [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

>
> Thanks
> Jo
>
> Related
> https://wso2.org/jira/browse/APIMANAGER-1704
>
>
>
>
>
>
>
> --
> *Joseph Fonseka*
>  WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


 --
 Nuwan Dias

 Associate Tech Lead - WSO2, Inc. http://wso2.com
 email : nuw...@wso2.com
 Phone : +94 777 775 729

>>>
>>>
>>
>>
>> --
>>
>> --
>> *Joseph Fonseka*
>>  WSO2 Inc.; http://wso2.com
>> lean.enterprise.middleware
>>
>> mobile: +94 772 512 430
>> skype: jpfonseka
>>
>> * *
>>
>>
>
>
> --
> Nuwan Dias
>
> Associate Tech Lead - WSO2, Inc. http://wso2.com
> email : nuw...@wso2.com
> Phone : +94 777 775 729
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Nuwan Dias]

Ok, so I think we need to have a property which can be enabled/disabled.
This property decides whether the OPTIONS request should be forwarded to
the back-end or not. Whenever the Max-Forwards header is not present in the
request, this property gets prominence. When present, Max-Forwards get
prominence.

And I think this needs to be done at the Synapse level rather than handling
at an API Manager handler level.

Thanks,
NuwanD.

On Tue, Jan 13, 2015 at 2:38 PM, Joseph Fonseka  wrote:

> Hi
>
> @Amila
> For options call we can respond per API basis, based on the HTTP methods
> defined in the API. And those methods can be sent via "Allow" header. Also
> the same methods can be sent in CORS headers too.
>
> @Nuwan
> Yes the Max-Forwards is the problem and according to the spec it is to be
> honored by proxy servers. But API Gateway is more of an API facade which
> does masking so shouldn't it be hiding internal implementation details from
> outside ? (Ex the implemented methods in the back-end server). If so then
> we should not send the OPTIONS call to the back-end.
>
> @Ruwan
> IMO we should return the OPTIONS call from Gateway also in ESB if the
> Max-Forwards is set to 0 it will return before hitting the in sequence.
>
> Thanks
> Jo
>
>
>
>
>
> On Tue, Jan 13, 2015 at 1:11 PM, Ruwan Yatawara  wrote:
>
>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias  wrote:
>>
>>>
>>>
>>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka 
>>> wrote:
>>>

 Hi

 Currently in API Manager we send the OPTIONS call to the back-end
 server to respond. But if the API does not expose all the HTTP methods in
 back-end, OPTIONS call response will be invalid.

 1. Should we respond to the OPTIONS call from the gateway with the
 Allow header including only the HTTP methods exposed by the API.

 2. If we are doing above should we give an option to the user to
 override in case if he want to send it to back-end.

>>>
>>> Whether the OPTIONS call goes to the back-end or not is dominated by the
>>> Max-Forwards header. According to the spec [1], it seems like the request
>>> should be forwarded when the Max-Forwards header is not present.
>>>
>>
>> First of all +1, but since we are implicitly enabling OPTIONS for the
>> API, and we are including a property that can be configured by the users if
>> they to enable sending options call to the back end (Which by the way needs
>> to be a configuration that can be done on a per API basis, i believe),
>> should we not introduce the Max-Forward : 0 header when intercepting the
>> options call at the gateway? and sending it back. Or should just the drop
>> the message and respond back, with the allow origin headers and what not?
>>
>>>
 3. Is there a valid requirement to show the OPTIONS method in API
 Design phase, shouldn't it be enabled by default.

>>> +1
>>>
>> +1
>>
>>>
>>> [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
>>>

 Thanks
 Jo

 Related
 https://wso2.org/jira/browse/APIMANAGER-1704







 --
 *Joseph Fonseka*
  WSO2 Inc.; http://wso2.com
 lean.enterprise.middleware

 mobile: +94 772 512 430
 skype: jpfonseka

 * *


>>>
>>>
>>> --
>>> Nuwan Dias
>>>
>>> Associate Tech Lead - WSO2, Inc. http://wso2.com
>>> email : nuw...@wso2.com
>>> Phone : +94 777 775 729
>>>
>>
>>
>
>
> --
>
> --
> *Joseph Fonseka*
>  WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 
Nuwan Dias

Associate Tech Lead - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Should the OPTIONS call be terminated at the API gateway.

[Nuwan Dias]

On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka  wrote:

>
> Hi
>
> Currently in API Manager we send the OPTIONS call to the back-end server
> to respond. But if the API does not expose all the HTTP methods in
> back-end, OPTIONS call response will be invalid.
>
> 1. Should we respond to the OPTIONS call from the gateway with the Allow
> header including only the HTTP methods exposed by the API.
>
> 2. If we are doing above should we give an option to the user to override
> in case if he want to send it to back-end.
>

Whether the OPTIONS call goes to the back-end or not is dominated by the
Max-Forwards header. According to the spec [1], it seems like the request
should be forwarded when the Max-Forwards header is not present.

>
> 3. Is there a valid requirement to show the OPTIONS method in API Design
> phase, shouldn't it be enabled by default.
>
+1

[1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

>
> Thanks
> Jo
>
> Related
> https://wso2.org/jira/browse/APIMANAGER-1704
>
>
>
>
>
>
>
> --
> *Joseph Fonseka*
>  WSO2 Inc.; http://wso2.com
> lean.enterprise.middleware
>
> mobile: +94 772 512 430
> skype: jpfonseka
>
> * *
>
>


-- 
Nuwan Dias

Associate Tech Lead - WSO2, Inc. http://wso2.com
email : nuw...@wso2.com
Phone : +94 777 775 729
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture