You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@synapse.apache.org by Hiranya Jayathilaka <hi...@gmail.com> on 2009/10/01 08:40:26 UTC
Handling Responses Which Don't Have a Content-Type
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
Re: Handling Responses Which Don't Have a Content-Type
Posted by Ruwan Linton <ru...@gmail.com>.
On Thu, Oct 1, 2009 at 1:09 PM, Hiranya Jayathilaka <hi...@gmail.com>wrote:
>
>
> On Thu, Oct 1, 2009 at 12:32 PM, Ruwan Linton <ru...@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
Re: Handling Responses Which Don't Have a Content-Type
Posted by Hiranya Jayathilaka <hi...@gmail.com>.
On Thu, Oct 1, 2009 at 12:32 PM, Ruwan Linton <ru...@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.
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
Re: Handling Responses Which Don't Have a Content-Type
Posted by Ruwan Linton <ru...@gmail.com>.
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
<hi...@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