views:

167

answers:

1

The problem I have is that the client is sending me a string of data as a stream. WCF then normalizes (removes the CR part of CRLF) and I get a hash mismatch between server and client on that specific string.

    public void SomeWcfContract(Stream input)
    {
        try
        {
            string processed = ReadStream(input);
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.OK;
        }
        catch (Exception ex)
        {
            WebOperationContext.Current.OutgoingResponse.StatusCode = HttpStatusCode.InternalServerError;
        }
    }


    private string ReadStream(Stream input)
    {
        string output;

        using (var reader = new StreamReader(input, Encoding.UTF8))
        {
            output = reader.ReadToEnd();
        }

        return output;
    }

I read a post about this here : http://stackoverflow.com/questions/1115459/xml-deserialization-standardising-line-endings-how-to-stop-it-net

It's the exact same problem I have but I use the standard XmlSerializer of WCF. Do I need to create my own XmlSerializer implementation or can I add the "fix" to the settings somehow?

This seems to be a VERY nasty bug with the WCF XmlDictionaryReader what happens is that when WCF serializes the incoming stream to a Message all instances of carriage return in (CRLF) is removed and replaced with LF. According to this it's a known bug in WCF. EDIT I reported this as a bug to Microsoft : https://connect.microsoft.com/wcf/feedback/details/532196/xmldictionaryreader-is-normalizing-incoming-stream-removing-cr-of-crlf#details

A: 

This seems to fix that problem:

    [WebInvoke(BodyStyle = WebMessageBodyStyle.Bare, 
        UriTemplate = UriTemplates.SomeWcfContract), OperationContract]
    void SomeWcfContract(Stream vcard);

I guess it makes sense since this would cause the parameter not to be wrapped or something like that.

mhenrixon