Welcome to Windows Communication Foundation (WCF)
Top Tasks :

WCF Team Bloggers

Browse by Tags

All Tags » Answers » Encoders   (RSS)

  • Not Omitting the XML Declaration

    Why doesn't a message start with an XML declaration? The XML declaration is a processing instruction at the beginning of an XML document that gives information about the format and logical structure of the document. You've probably seen the most commonly used XML declaration on many documents. <? xml version ="1.0" encoding ="UTF-8" ? > Both the version and the encoding in this example declaration are the default values. XML documents aren't required to start with a declaration because default values are assumed. Processors that are sensitive to the size of the produced document omit the declaration to avoid transmitting redundant information. The text encoder is an example of an XML processor that can recognize when the default values are being used and omit the declaration to save space. In some cases you want the XML declaration even when it's unnecessary because the receiver is expecting the document to start with a particular sequence of characters. Since the optimization in the text encoder isn't the result of a configuration setting, some amount of manual work is required to produce messages that contain unnecessary processing instructions. You can recreate this effect using a custom message encoder that is even simpler than the sample custom text encoder . You don't need to support a custom content type or to do any special processing when reading a message. You do need the shell for a message encoder and message encoder factory plus the logic in WriteMessage to insert the processing instruction. The sample writes the processing instruction using XmlWriterSettings although you can choose any method you wish. Next time: Flowing Additional Identity Information Read More...
  • Reader Quotas with Untyped Messages

    I have an operation contract that uses untyped messages. When using the message, I get an error telling me to change the quota settings on the XmlReader. Where are these quotas located? I'm not using an XmlReader. A message represents an XML InfoSet. While there are many different ways to access the content of a Message, in a standard implementation, all of these methods are wrappers around the core XmlReader and XmlWriter infrastructure. If there is no obvious XmlReader, then that means that the XmlReader is being used by the internal implementation of the message. Therefore, whoever created the Message must have been the one that knew about the XmlReader and its quotas. Since most of the messages that you deal with inside of a service operation were created by the message encoder of the binding, the first place to look for the quota settings are either on the binding or the binding element. Next time: Sticky Sessions Read More...
  • Adding HTTP Headers

    Why doesn't anything happen when I try to add HTTP headers from a message encoder? The problem here is a basic issue of timing. Recall the interface contract that a message encoder has with its transport. The transport receives a message from the next channel up in the channel stack, does some processing on the message, and calls WriteMessage on the message encoder when it wants to write out the message body. The message encoder does not necessarily see all of the message content. Some message content, such as framing, is independent of the message encoding and directly handled by the transport. In fact, the message encoder may not be called at all if there is no content for it to write. HTTP headers are an example of content that is handled by the transport rather than the message encoder. The message encoding transforms the body of the message, but HTTP headers are always sent as text. In the call to WriteMessage, the message encoder does get a Message object, which has a handle to the HTTP headers. However, if you look at the format of a raw HTTP message, then you would see that the HTTP headers are completely written out before the message body is written out. When streaming an HTTP message, the headers may even be transmitted before the message body is written out. Therefore, you should guess that it's unlikely that the message encoder can do anything with the HTTP header collection because the HTTP headers may already have been transmitted. If you want to change the HTTP headers, then you should make sure that all of the changes are made before the transport is given the message. Next time: WCF Case Studies Read More...
  • Handling Message Encoder Errors

    This time it's two questions that have the same answer. What contract does the message encoder have for producing a message from ReadMessage? What should the transport do if the message encoder doesn't produce a message from the buffer you give it? The contract of the message encoder is that it will always either throw an exception or produce exactly one message each time ReadMessage is called. This means that a properly-written message encoder will never fail to produce a message without throwing an exception out of ReadMessage for the transport to handle. As you might recall, the contract that the transport must abide by is that operations should only throw exceptions that are subtypes of CommunicationException, TimeoutException, or some fatal exception type (such as OutOfMemoryException). The transport should catch all exception types that it knows the message encoder will produce, such as XmlException, and wrap those in some instance of CommunicationException. A good choice would be ProtocolException. However, the transport should not just eat all types of exceptions. It's best to let a stray exception through unless it is a specific, known type because you run the risk of trapping a fatal exception. What happens to the message after the transport gets it back from the message encoder is no longer constrained by the contract of the message encoder. Next time: How to Configure MaxItemsInObjectGraph Read More...

Copyright © 2006 Microsoft Corporation. All Rights Reserved. | Terms of Use | Privacy Statement | Contact Us