On Thu, Oct 1, 2009 at 1:09 PM, Hiranya Jayathilaka <[email protected]>wrote:
> > > On Thu, Oct 1, 2009 at 12:32 PM, Ruwan Linton <[email protected]>wrote: > >> Hiranya, >> >> Lets make it a bit more flexible and make it configurable. >> >> We can have a axis2.xml parameter to specify the default content-type if >> there is no content type in the response. Also it should be possible to >> overwrite the axis2.xml parameter from the message context as well. >> >> So ideally when getting the content-type, the logic should be; >> >> if (content-type Http header present) { >> use the Http Content type header as the content type >> } else if (message context has a ContentTypeProperty property) { >> use the message context property as the Content Type >> } else if (axis configuration has a content type parameter) { >> use the axis config parameter >> } else { >> use "application/octet-stream" >> } >> >> Also JMS transport uses this sort of a service parameter, and it is good >> to be consistent with the property across all the transports. >> > > +1. With that approach one could set the msgCtx property using the property > mediator in the in sequence of a proxy and control how responses are handled > in the out sequence. > Yeah, that was the idea... Thanks, Ruwan > > Thanks, > Hiranya > > >> >> Thanks, >> Ruwan >> >> >> >> On Thu, Oct 1, 2009 at 12:10 PM, Hiranya Jayathilaka < >> [email protected]> wrote: >> >>> Hi Folks, >>> >>> It appears that the Synapse NHTTP transport is not properly handling the >>> response messages that don't have a Content-Type header. Currently when the >>> Content-Type header is not present in a response message the following bit >>> of code is executed by the ClientWorker. >>> >>> // there is no response entity-body >>> responseMsgCtx.setProperty(NhttpConstants.NO_ENTITY_BODY, >>> Boolean.TRUE); >>> responseMsgCtx.setEnvelope(new >>> SOAP11Factory().getDefaultEnvelope()); >>> >>> As a result the service client will receive a response with an empty >>> payload. >>> >>> HTTP specs [1] describe how to handle this kind of scenarios as follows. >>> >>> *Any HTTP/1.1 message containing an entity-body SHOULD include a >>>> Content-Type header field defining the media type of that body. If and only >>>> if the media type is not given by a Content-Type field, the recipient MAY >>>> attempt to guess the media type via inspection of its content and/or the >>>> name extension(s) of the URI used to identify the resource. If the media >>>> type remains unknown, the recipient SHOULD treat it as type >>>> "application/octet-stream". * >>>> >>> >>> I propose that we should allow the user to specify a default content type >>> which will be used for the messages that don't have a content-type header. >>> If a default type is not specified by the user we can set set the >>> content-type to "application/octet-stream". WDYT? >>> >>> Thanks, >>> Hiranya >>> >>> [1] - http://www.w3.org/Protocols/rfc2616/rfc2616-sec7.html#sec7.2.1 >>> >>> -- >>> Hiranya Jayathilaka >>> Software Engineer; >>> WSO2 Inc.; http://wso2.org >>> E-mail: [email protected]; Mobile: +94 77 633 3491 >>> Blog: http://techfeast-hiranya.blogspot.com >>> >> >> >> >> -- >> Ruwan Linton >> Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb >> WSO2 Inc.; http://wso2.org >> email: [email protected]; cell: +94 77 341 3097 >> blog: http://ruwansblog.blogspot.com >> > > > > -- > Hiranya Jayathilaka > Software Engineer; > WSO2 Inc.; http://wso2.org > E-mail: [email protected]; Mobile: +94 77 633 3491 > Blog: http://techfeast-hiranya.blogspot.com > -- Ruwan Linton Technical Lead & Product Manager; WSO2 ESB; http://wso2.org/esb WSO2 Inc.; http://wso2.org email: [email protected]; cell: +94 77 341 3097 blog: http://ruwansblog.blogspot.com
