XFire

xsd:base64Binary .NET interop problem

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 1.1-RC1
  • Fix Version/s: 1.1
  • Component/s: None
  • Labels:
    None
  • Number of attachments :
    3

Description

.NET encodes base64 according to specs: line feed after 76 bytes.

When we upload the contents of a file as a base64Binary byte[] with a .NET client to our XFire web service, the size and contents of the byte array that the method on the service receives do not match. It seems XFire has problems decoding base64Binary data that has a fixed line length of 76 characters. Testing with other clients that sent the data as one line (chunked or not chunked) did work.

According to the XML Schema Datatypes spec (chapter 3.2.16) the line-length of 76 is not mandatory and must not be enforced. This suggests that a line-length of 76 characters is allowed, however.

Attached is the request done by the .Net client (including HTTP headers and SOAP Envelope). Using a base64 decoding tool you can convert the data to a .gif file.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Matthijs Wensveen added a comment -

Erm, actually the first attachment just works. It seems the service only has trouble decoding the file when the size is larger than a certain (unknown) size.

Show
Matthijs Wensveen added a comment - Erm, actually the first attachment just works. It seems the service only has trouble decoding the file when the size is larger than a certain (unknown) size.
Hide
Permalink
Dan Diephouse added a comment -

Someone else commented on issues with base64Binary stuff as well. I think what you highlight could be an issue. We will get this figured out before we do our 1.1.

Show
Dan Diephouse added a comment - Someone else commented on issues with base64Binary stuff as well. I think what you highlight could be an issue. We will get this figured out before we do our 1.1.
Hide
Permalink
Dan Diephouse added a comment -

I can't reproduce this at all. I just tired a 2.5MB file with .NET. Do you per chance have the stax-1.1.2-dev jar on your classpath (stax-api is ok, this is a different one).

Show
Dan Diephouse added a comment - I can't reproduce this at all. I just tired a 2.5MB file with .NET. Do you per chance have the stax-1.1.2-dev jar on your classpath (stax-api is ok, this is a different one).
Hide
Permalink
Wouter added a comment -

nope

stax-api 1.0.jar
stax-utils-snapshot-20040917.jar
xfire-all-1.1-beta-1.jar

Show
Wouter added a comment - nope stax-api 1.0.jar stax-utils-snapshot-20040917.jar xfire-all-1.1-beta-1.jar
Hide
Permalink
Matthijs Wensveen added a comment -

Included in the zip are 2 java files that implement a webservice that takes a byte[], the length of the byte[] and a crc32 number as parameters.
Also included is a zipped Visual Studio .Net 2003 project that sends those values to the service. The service then checks the length and crc against its own calculated length and crc.

The checks begin to fail consistently with byte[] greater than 757 bytes. The reported length is longer then the length of the received byte[].

As previously stated, I'm pretty sure .Net sends correct base64Binary data, as I could convert jpegs back from captured soap envelopes (try the attached envelope.dat files to see this for yourself).

Show
Matthijs Wensveen added a comment - Included in the zip are 2 java files that implement a webservice that takes a byte[], the length of the byte[] and a crc32 number as parameters. Also included is a zipped Visual Studio .Net 2003 project that sends those values to the service. The service then checks the length and crc against its own calculated length and crc. The checks begin to fail consistently with byte[] greater than 757 bytes. The reported length is longer then the length of the received byte[]. As previously stated, I'm pretty sure .Net sends correct base64Binary data, as I could convert jpegs back from captured soap envelopes (try the attached envelope.dat files to see this for yourself).
Hide
Permalink
Dan Diephouse added a comment -

Thanks a lot for the test case. I'm able to reproduce this now! Yay! I think part of the problem was I was testing with .NET 2.0 instead of 1.1. I'll see if I can get this fixed today.

Show
Dan Diephouse added a comment - Thanks a lot for the test case. I'm able to reproduce this now! Yay! I think part of the problem was I was testing with .NET 2.0 instead of 1.1. I'll see if I can get this fixed today.
Hide
Permalink
Dan Diephouse added a comment -

This is fixed now in SVN and will be in our next release. Thanks Wouter.

Show
Dan Diephouse added a comment - This is fixed now in SVN and will be in our next release. Thanks Wouter.
Hide
Permalink
Matthijs Wensveen added a comment -

Thanks for fixing this. Wierd that the example from http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamReader.html#getTextCharacters(int,%20char[],%20int,%20int) that was literally in the source does not work.... I'm not sure why it wouldn't work, but I haven't really looked into it. Anyway, thanks again for fixing this.

Show
Matthijs Wensveen added a comment - Thanks for fixing this. Wierd that the example from http://java.sun.com/webservices/docs/1.5/api/javax/xml/stream/XMLStreamReader.html#getTextCharacters(int,%20char[],%20int,%20int) that was literally in the source does not work.... I'm not sure why it wouldn't work, but I haven't really looked into it. Anyway, thanks again for fixing this.

People

Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.