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" <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> On Tue, Jan 13, 2015 at 2:54 PM, Nuwan Dias <[email protected]> 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 <[email protected]> >>>> 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 <[email protected]> >>>>> wrote: >>>>> >>>>>> On Tue, Jan 13, 2015 at 12:55 PM, Nuwan Dias <[email protected]> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Jan 13, 2015 at 11:40 AM, Joseph Fonseka <[email protected]> >>>>>>> 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 >>>>>>>> >>>>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Nuwan Dias >>>>>>> >>>>>>> Associate Tech Lead - WSO2, Inc. http://wso2.com >>>>>>> email : [email protected] >>>>>>> Phone : +94 777 775 729 >>>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> -- >>>>> *Joseph Fonseka* >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: +94 772 512 430 >>>>> skype: jpfonseka >>>>> >>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>> >>>>> >>>> >>>> >>>> -- >>>> Nuwan Dias >>>> >>>> Associate Tech Lead - WSO2, Inc. http://wso2.com >>>> email : [email protected] >>>> Phone : +94 777 775 729 >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>> >>>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> *Amila De Silva* >> >> WSO2 Inc. >> mobile :(+94) 775119302 >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Isuru Udana* > Senior > *Software Engineer* > WSO2 Inc.; http://wso2.com > email: [email protected] cell: +94 77 3791887 > blog: http://mytecheye.blogspot.com/ > twitter: http://twitter.com/isudana > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > >
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
