Dropping carriage return characters from web service

[rgliane]

[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?

 

[Steven Cheng[MSFT]]

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]

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?

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]]

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]]

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]

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]]

You're welcome !

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead