Visual Studio and .NET Framework Home
System.ServiceModel.Channels.MessageEncoder.IsContentTypeSupported Method checks the whole content type string instead of just the media type.
as By Design
4/25/2007 2:09:22 PM
User(s) can reproduce this bug
When the System.ServiceModel.Channels.MessageEncoder.IsContentTypeSupported Method is called in a custom message encoder it checks the whole content type string instead of just the media type.
.NET Framework 3.0 (includes Windows Presentation, Communication and Workflow Foundation)
Windows XP Professional
Operating System Language
Steps to Reproduce
Change the CustomTextMessageEncoder in the Custom Message Encoder: Custom Text Encoder sample (http://msdn2.microsoft.com/en-us/library/ms751486.aspx) so that the client uses the content type "text/xml; charset=iso-8859-1" and the server uses the content type "text/xml;charset=iso-8859-1"
A System.ServiceModel.ProtocolException is thrown:
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=iso-8859-1). If using a custom encoder, be sure that the IsContentTypeSupported method is implemented properly.
The content type should be supported.
TAP Code (if applicable)
You can indicate your satisfaction with how Microsoft handled this issue by completing this quick
3 question survey
to post a comment.
Please enter a comment.
on 10/14/2009 at 11:28 AM
This problem is not only about media type. It is also about charset part.
String comparison violates RFC that allows quotes in charset definition.
Note that the value of a quoted string parameter does not include the
quotes. That is, the quotation marks in a quoted-string are not a
part of the value of the parameter, but are merely used to delimit
that parameter value. In addition, comments are allowed in
accordance with RFC 822 rules for structured header fields. Thus the
following two forms
Content-type: text/plain; charset=us-ascii (Plain text)
Content-type: text/plain; charset="us-ascii"
are completely equivalent.
on 9/5/2007 at 10:31 AM
Thanks for your feedback. This behavior is by design. The base implementation of IsContentTypeSupported requires the entire content-type must match. If your custom encoder only needs to match on the media type, you should override IsContentTypeSupported exactly as you are doing.
Windows Communication Foundation Product Team.
on 4/26/2007 at 6:46 PM
Thanks for your feedback. We have reproduced this bug on Visual Studio Codename Orcas Beta 1, and we are sending this bug to the appropriate group within the VisualStudio Product Team for triage and resolution.
Visual Studio Product Team.
on 4/26/2007 at 1:34 PM
I have attached a sample Orcas solution.
Try to run it and you'll see what I mean.
Uncomment the IsContentTypeSupported in ServerCustomTextMessageEncoder and ClientCustomTextMessageEncoder and it will work.
on 4/26/2007 at 2:16 AM
Thanks for your feedback, we were unable to repro the bug with the steps provided on Visual Studio Codename Orcas Beta 1. If you still see this issue occurring we would like to investigate this issue again. Please provide the exact steps/actions to reproduce the problem or a zipped project file and we will re-investigate.
Visual Studio Product Team.
on 4/25/2007 at 6:48 PM
Thank you for your feedback. We are currently investigating. If this issue is urgent, please call support directly (see http://support.microsoft.com). Thank you, Visual Studio Product Team.
to post a workaround.
Please enter a workaround.
on 2/26/2010 at 7:40 AM
See this url for a workaround:
© 2014 Microsoft