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.
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
