Search

WCF-BasicHttp : Response binding ISO8859-1 instead of utf-8 by BizTalk - Paris

Active

7
1
Sign in
to vote
Type: Bug
ID: 685161
Opened: 8/23/2011 5:37:53 AM
Access Restriction: Public
2
Workaround(s)
5
User(s) can reproduce this bug
I'm calling a distant WebService through a WCF-BasicHttp, and the Webservice's Response encoding is on ISO8859-1, below is the error :

The adapter failed to transmit message going to send port "xxx" with URL "http://xxx.lde:83/xxx/server.php". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.ServiceModel.ProtocolException: The content type text/xml; charset=ISO-8859-1 of the response message does not match the content type of the binding (text/xml; charset=utf-8). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly. The first 888 bytes of the response were: '<?xml version="1.0" encoding="ISO-8859-1"?>

Could you please add or support more encodings rather than only the actuel 3 supported UTF-8, UTF-16 and Big Endean Unicode encodings.
Details (expand)

Product Language

English

Version

BizTalk 2010 Beta

Category

Adapters

Repro Steps

You will need a distant WebService that responds with ISO8859-1 encoding.
Then write a simple orchestration that calls this WebService the error should happen when the response is received

File Attachments
0 attachments
Sign in to post a comment.
Posted by Joshua Bair on 7/30/2012 at 2:04 PM
I would also like to request that ISO-9959-1 be added to the default WCF TextMessageEncoder. According to Wikipedia:

ISO-8859-1 is (according to the standards at least) the default encoding of documents delivered via HTTP with a MIME type beginning with "text/" (however the draft HTML 5 specification requires that documents advertised as ISO-8859-1 actually be parsed with the Windows-1252 encoding.[2]) It is the default encoding of the values of certain descriptive HTTP headers, and defines the repertoire of characters allowed in HTML 3.2 documents (HTML 4.0, however, is based on Unicode).

http://en.wikipedia.org/wiki/ISO/IEC_8859-1

Thanks,

Joshua
Sign in to post a workaround.
Posted by Joshua Bair on 7/30/2012 at 2:14 PM
I forgot one important step in my workaround:

Step 4:
Modify your CustomTextMessageEncoder class to add the following override:

        public override bool IsContentTypeSupported(string contentType)
        {
            return true;
        }

This will allow you to receive ISO-8859-1 encoded XML data from a non-Microsoft web server.
Posted by Joshua Bair on 7/30/2012 at 2:11 PM
I have successfully created a work around for this problem, although it currently only works if you know in advance that the service you are about to contact returns ISO-8859-1 encoded data.

Step 1:
Follow the instructions described by this Custom Text Encoder example: http://msdn.microsoft.com/en-us/library/ms751486.aspx

Step 2:
Modify your CustomTextMessageBindingElement class by adding the following overrides:

        public override IChannelFactory<TChannel> BuildChannelFactory<TChannel>(BindingContext context)
        {
            context.BindingParameters.Add(this);

            return base.BuildChannelFactory<TChannel>(context);
        }

        public override IChannelListener<TChannel> BuildChannelListener<TChannel>(BindingContext context)
        {
            context.BindingParameters.Add(this);

            return base.BuildChannelListener<TChannel>(context);
        }

        public override bool CanBuildChannelFactory<TChannel>(BindingContext context)
        {
            context.BindingParameters.Add(this);

            return base.CanBuildChannelFactory<TChannel>(context);
        }

        public override bool CanBuildChannelListener<TChannel>(BindingContext context)
        {
            context.BindingParameters.Add(this);

            return base.CanBuildChannelListener<TChannel>(context);
        }


Step 3:
Modify your code (or web.config) to use an instance of the CustomTextMessageBindingElement class above.

This worked for me, but only if configured properly before the ISO-8859-1 service is contacted. I will continue to research if the custom message encoder can be further modified to handle SOAP messages using any encoding value, and will add more information as it becomes available.