Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / ASP.NET / Web Services / February 2007

Tip: Looking for answers? Try searching our database.

Dropping carriage return characters from web service

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
rgliane - 12 Feb 2007 21:17 GMT
[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] - 13 Feb 2007 10:10 GMT
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 - 21 Feb 2007 23:43 GMT
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,
>
[quoted text clipped - 67 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 26 Feb 2007 07:59 GMT
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] - 27 Feb 2007 08:44 GMT
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 - 27 Feb 2007 14:26 GMT
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 ;-)

> Hello Rgliane,
>
[quoted text clipped - 34 lines]
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
Steven Cheng[MSFT] - 28 Feb 2007 00:41 GMT
You're welcome !

Sincerely,

Steven Cheng

Microsoft MSDN Online Support Lead

Rate this thread:







Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.