synapse-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ruwan Linton <ruwan.lin...@gmail.com>
Subject Re: Handling Responses Which Don't Have a Content-Type
Date Thu, 01 Oct 2009 08:12:29 GMT
On Thu, Oct 1, 2009 at 1:09 PM, Hiranya Jayathilaka <hiranya911@gmail.com>wrote:

>
>
> On Thu, Oct 1, 2009 at 12:32 PM, Ruwan Linton <ruwan.linton@gmail.com>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 <
>> hiranya911@gmail.com> 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: hiranya@wso2.com;  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: ruwan@wso2.com; cell: +94 77 341 3097
>> blog: http://ruwansblog.blogspot.com
>>
>
>
>
> --
> Hiranya Jayathilaka
> Software Engineer;
> WSO2 Inc.;  http://wso2.org
> E-mail: hiranya@wso2.com;  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: ruwan@wso2.com; cell: +94 77 341 3097
blog: http://ruwansblog.blogspot.com

Mime
View raw message