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