Dropping carriage return characters from web service

Discussion in 'ASP .Net Web Services' started by rgliane, Feb 12, 2007.

  1. rgliane

    rgliane Guest

    [This is a repost of my 12/26/2006 question per Charisse from MS Customer
    Service. Waiting on an official MS response but all are welcome to chime in]

    I have a web service that returns a String as part of the return . The
    String has embedded CR (x13) and LF (x10) in it. When the client code gets
    it though, the CRs have been stripped out and only the LFs are present.

    I saw an article that said I need to convert the String to Unicode (UTF-8)
    before I return but that does not seem to do anything. The byte arrays are
    different in ASCII versus UTF-8. But they convert to the same String value
    .... which makes sense since .NET String is Unicode already and CR/LF have the
    same hex values in ASCII and UTF-8.

    I also thought of using HttpUtility.UrlEncode on the server and decoding on
    the client. This would probably work in most cases but one of my clients is
    a Pockect PC and HttpUtility does not appear to be supported.

    I guess I could just add in a CR every time I see a LF but I would rather
    understand why this is occurring. Does anyone have a solution for this? It
    seems like such a common scenario. Also, is there an easy way for me to see
    the actual messages received and sent to the web service, preferably through
    Visual Studio?
     
    rgliane, Feb 12, 2007
    #1
    1. Advertising

  2. Hello Rgliane,

    Regarding on the CR(X0D) LF(x0A) characters issue, it is actually due to
    the response conversion(in the client proxy's internal code) against the
    string data in soap response message. Based on my tracing, both the 0D
    and 0A chars are correctly sent back to the client-side, however, it is in
    the SoapHttpClientProtocol(base class of client proxy)'s code, when it read
    the content from the response stream, for string value, it will filtered
    the "0A" char. I haven't got the exact code logic, based on reflector's
    diassembled code, it is during the "ReadResponse" method.

    So far I think for string type parameter or return value, it will force
    this normalizing rules on the control character, if you do need to get the
    exact character list, I suggest you consider transfer the string as byte
    array (encoding it before transfer and decode it after received). e.g.

    =========================
    [WebMethod]
    public byte[] GetBinaryData()
    {
    string str = string.Empty;

    str = "abc\r\n";


    return Encoding.Unicode.GetBytes(str);

    }
    =====================

    =======client code==========

    byte[] bytes = proxy.GetBinaryData();

    string str = Encoding.Unicode.GetString(bytes);

    Console.WriteLine(str.Length);
    =====================

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead



    ==================================================

    Get notification to my posts through email? Please refer to
    http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
    ications.



    Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
    where an initial response from the community or a Microsoft Support
    Engineer within 1 business day is acceptable. Please note that each follow
    up response may take approximately 2 business days as the support
    professional working with you may need further investigation to reach the
    most efficient resolution. The offering is not appropriate for situations
    that require urgent, real-time or phone-based interactions or complex
    project analysis and dump analysis issues. Issues of this nature are best
    handled working with a dedicated Microsoft Support Engineer by contacting
    Microsoft Customer Support Services (CSS) at
    http://msdn.microsoft.com/subscriptions/support/default.aspx.

    ==================================================



    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Steven Cheng[MSFT], Feb 13, 2007
    #2
    1. Advertising

  3. rgliane

    rgliane Guest

    Using a byte array is what I came up with also before my re-post of the
    question. It works...I'm just surprised that the proxy was written to drop
    the character. I could possibly understand if it was written for a UNIX
    system where the LF is sufficient to designate EOL but the proxy code is
    specifically for Windows. Weird...

    Is there any way to configure the proxy creation so that it stops doing
    this? Or if not now, can this be an enhancement request?

    "Steven Cheng[MSFT]" wrote:

    > Hello Rgliane,
    >
    > Regarding on the CR(X0D) LF(x0A) characters issue, it is actually due to
    > the response conversion(in the client proxy's internal code) against the
    > string data in soap response message. Based on my tracing, both the 0D
    > and 0A chars are correctly sent back to the client-side, however, it is in
    > the SoapHttpClientProtocol(base class of client proxy)'s code, when it read
    > the content from the response stream, for string value, it will filtered
    > the "0A" char. I haven't got the exact code logic, based on reflector's
    > diassembled code, it is during the "ReadResponse" method.
    >
    > So far I think for string type parameter or return value, it will force
    > this normalizing rules on the control character, if you do need to get the
    > exact character list, I suggest you consider transfer the string as byte
    > array (encoding it before transfer and decode it after received). e.g.
    >
    > =========================
    > [WebMethod]
    > public byte[] GetBinaryData()
    > {
    > string str = string.Empty;
    >
    > str = "abc\r\n";
    >
    >
    > return Encoding.Unicode.GetBytes(str);
    >
    > }
    > =====================
    >
    > =======client code==========
    >
    > byte[] bytes = proxy.GetBinaryData();
    >
    > string str = Encoding.Unicode.GetString(bytes);
    >
    > Console.WriteLine(str.Length);
    > =====================
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    >
    > ==================================================
    >
    > Get notification to my posts through email? Please refer to
    > http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
    > ications.
    >
    >
    >
    > Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
    > where an initial response from the community or a Microsoft Support
    > Engineer within 1 business day is acceptable. Please note that each follow
    > up response may take approximately 2 business days as the support
    > professional working with you may need further investigation to reach the
    > most efficient resolution. The offering is not appropriate for situations
    > that require urgent, real-time or phone-based interactions or complex
    > project analysis and dump analysis issues. Issues of this nature are best
    > handled working with a dedicated Microsoft Support Engineer by contacting
    > Microsoft Customer Support Services (CSS) at
    > http://msdn.microsoft.com/subscriptions/support/default.aspx.
    >
    > ==================================================
    >
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
    >
     
    rgliane, Feb 21, 2007
    #3
  4. Thanks for your followup Rgliane,

    So far I haven't found any better solution. I'll help you consult some
    other ASMX webservice experts to see whether there is anything else we can
    do here to workaround the issue.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Steven Cheng[MSFT], Feb 26, 2007
    #4
  5. Hello Rgliane,

    I have got some further information on this issue. For the client-side
    proxy, we can override its "GetReaderForMessage" method get the underlying
    XMLReader and than turn off its "Normalization". You can put the overrdie
    method in a separate partial class file(so that it won't be overwritten
    when update the proxy):

    ===============
    public partial class Service :
    System.Web.Services.Protocols.SoapHttpClientProtocol
    {

    protected override System.Xml.XmlReader
    GetReaderForMessage(SoapClientMessage message, int bufferSize)
    {
    XmlTextReader reader =
    (XmlTextReader)base.GetReaderForMessage(message, bufferSize);

    reader.Normalization = false;

    return reader;
    }
    ==============

    Also, as some other WS engineers has pointed, this string normalization is
    conform to the XML specification, therefore, if you do the change, it will
    only work for your particular client, and other webservice proxy(such as
    java based) will still do this string normaliation, so this behavior is not
    dedicated to .net framework implementation.

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead


    This posting is provided "AS IS" with no warranties, and confers no rights.
     
    Steven Cheng[MSFT], Feb 27, 2007
    #5
  6. rgliane

    rgliane Guest

    This is exactly what I need! Thanks for the continued effort.

    As for it being per the XML specification...just further evidence why I
    dislike stuff out of a committee ;-)


    "Steven Cheng[MSFT]" wrote:

    > Hello Rgliane,
    >
    > I have got some further information on this issue. For the client-side
    > proxy, we can override its "GetReaderForMessage" method get the underlying
    > XMLReader and than turn off its "Normalization". You can put the overrdie
    > method in a separate partial class file(so that it won't be overwritten
    > when update the proxy):
    >
    > ===============
    > public partial class Service :
    > System.Web.Services.Protocols.SoapHttpClientProtocol
    > {
    >
    > protected override System.Xml.XmlReader
    > GetReaderForMessage(SoapClientMessage message, int bufferSize)
    > {
    > XmlTextReader reader =
    > (XmlTextReader)base.GetReaderForMessage(message, bufferSize);
    >
    > reader.Normalization = false;
    >
    > return reader;
    > }
    > ==============
    >
    > Also, as some other WS engineers has pointed, this string normalization is
    > conform to the XML specification, therefore, if you do the change, it will
    > only work for your particular client, and other webservice proxy(such as
    > java based) will still do this string normaliation, so this behavior is not
    > dedicated to .net framework implementation.
    >
    > Sincerely,
    >
    > Steven Cheng
    >
    > Microsoft MSDN Online Support Lead
    >
    >
    > This posting is provided "AS IS" with no warranties, and confers no rights.
    >
    >
     
    rgliane, Feb 27, 2007
    #6
  7. You're welcome !

    Sincerely,

    Steven Cheng

    Microsoft MSDN Online Support Lead
     
    Steven Cheng[MSFT], Feb 28, 2007
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. =?Utf-8?B?V2ViTWF0cml4?=

    Newline & carriage return characters over SOAP HTTP

    =?Utf-8?B?V2ViTWF0cml4?=, Mar 13, 2006, in forum: ASP .Net
    Replies:
    0
    Views:
    690
    =?Utf-8?B?V2ViTWF0cml4?=
    Mar 13, 2006
  2. Replies:
    2
    Views:
    11,274
    Boudewijn Dijkstra
    Aug 30, 2005
  3. Wesley C

    Preserving Carriage Return in a Web service

    Wesley C, Dec 16, 2003, in forum: ASP .Net Web Services
    Replies:
    2
    Views:
    405
    Alin Popovici
    Jan 8, 2004
  4. Ron Gliane

    Dropping carriage return characters from web service

    Ron Gliane, Jan 25, 2007, in forum: ASP .Net Web Services
    Replies:
    3
    Views:
    223
    Luke Zhang [MSFT]
    Feb 9, 2007
  5. Steve Anderson
    Replies:
    3
    Views:
    257
    Steve Anderson
    Jun 21, 2004
Loading...

Share This Page