Hi Nicholas, Yes it will be in effect for all application (Subjected to the fact that it sends an Accept header). If the client does not send an Accept header then everything will be as it used to be. But as Glen suggested we could have a switch to turn this feature off.
Thanks, Keith. On 10/19/07, Nicholas L Gallardo <[EMAIL PROTECTED]> wrote: > > Glen, > > > If the request is SOAP 1.1, we should always return SOAP 1.1 regardless > > of the Accept header, right? > > That's my understanding. I believe this is addressed in the SOAP 1.2 spec > as to what constitutes a mismatch error and what kinds of responses can go > back. > > Would this leave the existing behavior unchanged for services that declare > an explicit SOAP binding in a WSDL? In other words, does this just apply to > endpoints choosing to leverage a RESTful pattern/API, or will all > applications be subject to negotiation? > > -Nick > > > > [image: Inactive hide details for Glen Daniels <[EMAIL PROTECTED]>]Glen > Daniels <[EMAIL PROTECTED]> > > > > *Glen Daniels <[EMAIL PROTECTED]>* > > 10/18/2007 05:41 AM Please respond to > axis-dev@ws.apache.org > > > To > > axis-dev@ws.apache.org > cc > > > Subject > > Re: [AXIS2] Proposal to implement http content negotiation > > > Hi folks: > > +1 from me *if* we make sure there's a flag to allow people to control > whether a given operation supports POX or not. Essentially I'm just > saying we should backport the SOAP-Response MEP to SOAP 1.1, and allow > the user to specify. By default the behavior should be as in Keith's > proposal, but if they indicate that a particular operation is using the > SOAP-Response MEP (this could also be a disablePOX flag or whatever), it > should always return SOAP on a GET. > > Also... > > >> a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 > >> response will be went only when the request is SOAP 1.1 and there is > >> no matching value in the Accept header). > > If the request is SOAP 1.1, we should always return SOAP 1.1 regardless > of the Accept header, right? > > --Glen > > Sanjiva Weerawarana wrote: > > +1 from me. > > > > For some further discussion on this see [1]. In particular [2] gives > > rationale for why its ok to give more weight to POX over SOAP 1.1. > > > > Sanjiva. > > [1] > http://wso2.org/mailarchive/registry-dev/2007-October/thread.html#473 > > [2] http://wso2.org/mailarchive/registry-dev/2007-October/000540.html > > > > keith chapman wrote: > >> Hi Devs, > >> > >> There have been some thought on http content negotiation. With the > >> concept of builders and formatters we have now this could be > >> implemented trivially. The idea is to use the "Accept" http header to > >> serve the response requested by the client. While going through this > >> though I came across a issue though. This occurs when a request is > >> sent via a GET using a browser (Cause the browser automatically adds > >> the Accept http header). The Accept header sent by firefox is "Accept: > >> text/xml,application/xml,application/xhtml+xml,text/html;q=0.9 > ,text/plain;q=0.8,image/png,*/*;q=0.5". > >> The confusion comes in because text/xml is used for both SOAP and REST > >> responses. > >> > >> I believe having http content negotiation as a feature will be a nice > >> addition to Axis2. And I propose that we treat text/xml as a REST > >> response in implementing this. This would mean that you cannot ask for > >> a SOAP 1.1 response uaing http content negotiation (A SOAP 1.1 > >> response will be went only when the request is SOAP 1.1 and there is > >> no matching value in the Accept header). > >> > >> What do u think? Should we go ahead and implement this proposal? > >> > >> Thanks, > >> Keith. > >> > >> -- > >> Keith Chapman > >> WSO2 Inc. > >> Oxygen for Web Services Developers. > >> http://wso2.org/ > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > -- Keith Chapman WSO2 Inc. Oxygen for Web Services Developers. http://wso2.org/
<<graycol.gif>>
<<ecblank.gif>>
