Help please: Exception when with <input type="file"> but not with Textbox

[Drew Berkemeyer]

I've encounted a pretty strange problem and I'm not quite sure what to make
of it.

I have a web service that consumes an XML file as well as a few other
parameters. This web service works fine if I use the web test interface. It
also works fine if I call it from an ASP.NET page that has a text box where
the XML is pasted and then passed on. However, I get an exception if I use
an <input type="file"> control on the ASP page that allows the user to load
the XML file before posting back to the server.

I've added a temporary text box to this ASP.NET page so that I could
actually load *both* values and compare the two.

Here's the kicker, when I compare the two strings they are *identical*! Yet,
if I subsequently call the web service twice: once with the XML pasted into
the text box and then a second time with the XML loaded from the <input
type="file"> control, the later call fails!

Here is a code snippet to show what i'm talking about:

' strXMLContent is a string that is holding the contents of a file loaded by
the user
' with the <input type="file"> control
'
' txtTemp.Text is the contents of the exact same file that were pasted into
the ASPX page
' Notice that the comparison below shows the strings are *EXACTLY THE SAME*
If (String.Compare(strXMLContent, txtTemp.Text) = 0) Then
_lblStatusLabel.Text = "XML content is identical"
Else
_lblStatusLabel.Text = "XML content is not the same."
End If

' This call succeeds
bytePDF = wsPDF.CreatePDF(txtTemp.Text,
TestDWS_ASPX.PDF_WS.WatermarkID.TSILogo, enDealPart)
' This call throws an exception
bytePDF = wsPDF.CreatePDF(strXMLContent,
TestDWS_ASPX.PDF_WS.WatermarkID.TSILogo, enDealPart)

Here is the text of the exception:
'', hexadecimal value 0x00, is an invalid character. Line 6, position 117.
Description: An unhandled exception occurred during the execution of the
current web request. Please review the stack trace for more information
about the error and where it originated in the code.

Exception Details: System.Xml.XmlException: '', hexadecimal value 0x00, is
an invalid character. Line 6, position 117.

Source Error:

Line 40:
<System.Web.Services.Protocols.SoapDocumentMethodA ttribute("http://localhost/DWS/CreatePDF",
RequestNamespace:="http://localhost/DWS/",
ResponseNamespace:="http://localhost/DWS/",
Use:=System.Web.Services.Description.SoapBindingUs e.Literal,
ParameterStyle:=System.Web.Services.Protocols.Soap ParameterStyle.Wrapped)>
_
Line 41: Public Function CreatePDF(ByVal xmlTSI As String, ByVal
nWatermarkID As WatermarkID, ByVal enDealPart As dpDealPart) As
<System.Xml.Serialization.XmlElementAttribute(Data Type:="base64Binary")>
Byte()
Line 42: Dim results() As Object = Me.Invoke("CreatePDF", New
Object() {xmlTSI, nWatermarkID, enDealPart})
Line 43: Return CType(results(0),Byte())
Line 44: End Function
Source File: C:\TSI\MyProjects\DWS\TestDWS_ASPX\Web
References\PDF_WS\Reference.vb Line: 42

Stack Trace:

[XmlException: '', hexadecimal value 0x00, is an invalid character. Line 6,
position 117.]
System.Xml.XmlScanner.ScanHexEntity()
System.Xml.XmlTextReader.ParseBeginTagExpandCharEn tities() +1036
System.Xml.XmlTextReader.Read() +216
System.Xml.XmlReader.ReadElementString()
System.Web.Services.Protocols.SoapHttpClientProtoc ol.ReadSoapException(XmlReader
reader)
System.Web.Services.Protocols.SoapHttpClientProtoc ol.ReadResponse(SoapClientMessage
message, WebResponse response, Stream responseStream, Boolean asyncCall)
System.Web.Services.Protocols.SoapHttpClientProtoc ol.Invoke(String
methodName, Object[] parameters)
TestDWS_ASPX.PDF_WS.DWS.CreatePDF(String xmlTSI, WatermarkID
nWatermarkID, dpDealPart enDealPart) in
C:\TSI\MyProjects\DWS\TestDWS_ASPX\Web References\PDF_WS\Reference.vb:42
TestDWS_ASPX.WebForm1._btnCreatePDF_Click(Object sender, EventArgs e) in
C:\TSI\MyProjects\DWS\TestDWS_ASPX\index.aspx.vb:1 01
System.Web.UI.WebControls.Button.OnClick(EventArgs e)
System.Web.UI.WebControls.Button.System.Web.UI.IPo stBackEventHandler.RaisePostBackEvent(String
eventArgument)
System.Web.UI.Page.RaisePostBackEvent(IPostBackEve ntHandler
sourceControl, String eventArgument)
System.Web.UI.Page.RaisePostBackEvent(NameValueCol lection postData)
System.Web.UI.Page.ProcessRequestMain() +1292

-------------------------------------------------------

At first I thought that perhaps when I was decoding the uploaded file that I
was using the wrong encoder. However, I have since tried using a UTF-8
encoder and it didn't fix anything.

Does anyone have *any clues* as to what is going on?

Thank you in advance for your assistance. Any input at all is greatly
appreciated.

Sincerely,
Drew Berkemeyer

[Steven Cheng[MSFT]]

Hi Drew,

From your description, the same webservice call with the two string content
( which are proved as idential via String.Compare) will result different
behavior. Currently, I think we can do the following tests:

1. Try using the String.Equals( ) instead of the String.Compare (which will
make use of the current culture info when do the comparation) to make sure
that the two string are exactly idential. ( or save to the txt file via the
same encoding to compare the file content).

2. Make sure whether the error occurs before the webservice request be
processed at the serverside or after the serverside processing( when the
client retrieve the response content). You may create another simple
webservice( or webmethod which take a string parameter ) and do the same
test on the given file or text.

3. If possible, you can also try using the MS SOAP tookit3 's Trace
Utility to capture the RAW SOAP message to see whether the two request
have any difference. The soap Toolkit3 can be downloaded at the following
address:

http://www.microsoft.com/downloads/d...0DD-CEEC-4088-
9753-86F052EC8450&displaylang=en

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Drew Berkemeyer]

This is *excellent* feedback. Thank you so much for your help.

I will install the SOAP toolkit.

Yesterday I installed Ethereal (http://www.ethreal.com/) and captured the
HTTP stream. I discovered in doing this that the <input type=file> content
apears to have a trailing zero that apparantlly is not showing up in the
String.Compare call and is not present in the text that is posted into the
Textbox control. Since I do not have conclusive evidence as to exactly what
is going on I won't post the results yet.

Instead, I'll install the SOAP toolkit and do just a little more research
and post my results here.

Thank you again for taking the time to help me out. It is really
appreciated.

Sincerely,
Drew Berkemeyer
http://www.berkemeyer.com/

"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:iW**************@cpmsftngxa10.phx.gbl...

Hi Drew,

From your description, the same webservice call with the two string
content
( which are proved as idential via String.Compare) will result different
behavior. Currently, I think we can do the following tests:

1. Try using the String.Equals( ) instead of the String.Compare (which
will
make use of the current culture info when do the comparation) to make sure
that the two string are exactly idential. ( or save to the txt file via
the
same encoding to compare the file content).

2. Make sure whether the error occurs before the webservice request be
processed at the serverside or after the serverside processing( when the
client retrieve the response content). You may create another simple
webservice( or webmethod which take a string parameter ) and do the same
test on the given file or text.

3. If possible, you can also try using the MS SOAP tookit3 's Trace
Utility to capture the RAW SOAP message to see whether the two request
have any difference. The soap Toolkit3 can be downloaded at the following
address:

http://www.microsoft.com/downloads/d...0DD-CEEC-4088-
9753-86F052EC8450&displaylang=en

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Drew Berkemeyer]

OK. I've looked into this and finally figured out exactly what is going on.

The content that is loaded from the HttpPostedFile via the InputStream
property is always NULL (Nothing, Zero) terminated. I've searched and
searched and searched to find documentation on this but cannot find it
anywhere. However, I can't find my keys most days either so that's not
saying much.

So, the long and the short of it is that I've modified my stream reader to
strip off the last character *AFTER* this is said and done. AFTER is very
important here. Remember what I said above, "the content ... is *always*
NULL terminated." So if you just read in ContentLength() -1 you still get
the terminating NULL byte. You have to strip it off after you've decoded the
stream.

In my case it looks like this:

Dim Buffer() As Byte
Dim nBuffSize As Integer = postedFile.ContentLength()
Buffer = New Byte(nBuffSize) {}
postedFile.InputStream.Read(Buffer, 0, nBuffSize)
Dim theEncoding As Encoding = Encoding.GetEncoding("windows-1252")
strReturn = theEncoding.GetString(Buffer)
' The HttpPostedFile.InputStream is always terminated with a zero char
' so just strip it off during input
strReturn = strReturn.Substring(0, strReturn.Length - 1)

So, that's the best I could do in figuring out how to solve this. If someone
else has the "proper" way of doing it I'd love to hear about.
--

Sincerely,
Drew Berkemeyer
Software Architect
http://www.berkemeyer.com/

"Drew Berkemeyer" <sp**@menow.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

This is *excellent* feedback. Thank you so much for your help.

I will install the SOAP toolkit.

Yesterday I installed Ethereal (http://www.ethreal.com/) and captured the
HTTP stream. I discovered in doing this that the <input type=file> content
apears to have a trailing zero that apparantlly is not showing up in the
String.Compare call and is not present in the text that is posted into the
Textbox control. Since I do not have conclusive evidence as to exactly
what is going on I won't post the results yet.

Instead, I'll install the SOAP toolkit and do just a little more research
and post my results here.

Thank you again for taking the time to help me out. It is really
appreciated.

Sincerely,
Drew Berkemeyer
http://www.berkemeyer.com/

"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:iW**************@cpmsftngxa10.phx.gbl...

Hi Drew,

From your description, the same webservice call with the two string
content
( which are proved as idential via String.Compare) will result different
behavior. Currently, I think we can do the following tests:

1. Try using the String.Equals( ) instead of the String.Compare (which
will
make use of the current culture info when do the comparation) to make
sure
that the two string are exactly idential. ( or save to the txt file via
the
same encoding to compare the file content).

2. Make sure whether the error occurs before the webservice request be
processed at the serverside or after the serverside processing( when the
client retrieve the response content). You may create another simple
webservice( or webmethod which take a string parameter ) and do the same
test on the given file or text.

3. If possible, you can also try using the MS SOAP tookit3 's Trace
Utility to capture the RAW SOAP message to see whether the two request
have any difference. The soap Toolkit3 can be downloaded at the following
address:

http://www.microsoft.com/downloads/d...0DD-CEEC-4088-
9753-86F052EC8450&displaylang=en

Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hi Drew,

Thanks for your response. Glad that you've got great progress on this
issue. As the NULL terminated char when using file upload to post the
content, I'm stilling wondering wheher the problem is concerned with the
file's content or the encoding you're using. Will the problem also occur
if you upload some other text files or have you tried using other
encodings? Based on my local test, I use the input file to upload a text
file and decoding it using utf-8 and call a webservice , but I didn't get
the error( no null terminated char ). Anyway, if you still have insterest
to do some further research, you may have a test on that. Hope helps.
Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Hi Drew,

Any further progress or ideas on this issue? If there is anything else we
can help, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Drew Berkemeyer]

Well... like I said in the post before... the resolution seems to be that
you have to strip off the trailing 0x00 that is at the end of the
InputStream when I file is loaded via <input type=file>. Maybe I'm missing
something and maybe this is always the case, but doesn't show up in 99.9% of
the cases, I really don't know. In my case is showed up because the extra
0x00 byte at the end of the content was causing the XML Parser to throw an
exception.

I would love to get feedback from somebody who has some significant
experience with uploading MIME content using the <input type=file> tag and
see what their impression off all this is. Anybody want to expound a bit?
I'm all ears.

--

Sincerely,
Drew Berkemeyer
Software Architect
http://www.berkemeyer.com/
"Steven Cheng[MSFT]" <v-******@online.microsoft.com> wrote in message
news:xc**************@cpmsftngxa10.phx.gbl...

Hi Drew,

Any further progress or ideas on this issue? If there is anything else we
can help, please feel free to post here. Thanks.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Steven Cheng[MSFT]]

Thanks for your followup Drew,

Currently I also haven't any further ideas. Maybe some other commutniry
members who has ever experienced this can add some additional values.

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)