Dropping carriage return characters from web service

[Ron Gliane]

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?

 

[Ron Gliane]

I enabled WSE and I think that you are right about the service sending the
correct output. To test it, I had the service send out:

"XX[CR][LF]XX YY[LF]YY"

where [CR] and [LF] represent the embedded control characters. What I saw
in the trace was:

<GetNoteResult>XX
XX YY[LF]YY</GetNoteResult>

Since the second XX was on another line, I assume that the CR was in the
output. So it seems like the client side is the culprit. The client showed
this result:

"XX[LF]XX YY[LF]YY"

The CR was specifically removed and not the CRLF combo.

Unfortunately, I am having trouble making the client spit out the WSE
diagnostic log. I enabled WSE on the client project, specified input and
output files, and verified that the proxy class inherits from
Microsoft.Web.Services3.WebServicesClientProtocol. But when I run it, no
logs are created. Very frustrating! Am I missing a step? Also, any ideas
why the client would not translate the XML correctly?

Thanks in advance for any help.

 

[Ron Gliane]

The client and web service are part of the same VS solution and I am
bypassing the proxy for local addresses. So there should be no connection
interference. As for the tracing, the server logs are created fine but the
client logs are not produced. No error messages or seemingly anything wrong.
It just does not get created.

In the WSE options, I enabled the traces and even made them unique names so
nothing (e.g. the server process) would try to write to the same files. After
I run the client, logs for the server are created but nothing for the client,
not even empty files. Writing to the same directory as well so I know it has
permission to write there.

 

[Luke Zhang [MSFT]]

Hello,

The data passed by Web service will be serialized into XML format. In XML,
both CR and LF are treated as a white space and therefore get normalized in
the process. You can read more about it in the W3C Recommendation:

http://www.w3.org/TR/2004/REC-xml-20040204/#sec-common-syn.

I think replacing LF with CR+LF is a simple way to get around this.

Sincerely,

Luke Zhang

Microsoft Online Community Support
==================================================
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.