ws-soap-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Mitchell <kevin.mitch...@xmls.com>
Subject RE: Problem with base64 encoded parameter value?
Date Tue, 07 Nov 2000 21:03:49 GMT
 

-----Original Message-----
From: David Boreham [mailto:david_list@boreham.org]
Sent: Tuesday, November 07, 2000 12:34 PM
To: soap-dev@xml.apache.org
Subject: Re: Problem with base64 encoded parameter value?



If you need it 100% clean, I see these options
 
 - pass a reference and have your server go get the data.
 

Unattractive.

 
 - base64 encoding
 

Workable for now. I'm slightly perplexed by the client behavior---it chooses
whether to encode or not depending on the payload, and that in turn causes
the
server to try to execute different proxy object methods (the String/byte[]
thing).
Seems rather strange to me. I'd prefer a single mechanism to get my data
over the channel. Perhaps I should base64 encode in my application. 
That would be quite easy for me to do.
 
What I really need is the non-existent XML document transport protocol :)

 
The way in which the data is encoded is based on the registered serializers.
By default, Apache SOAP registers a base64 serializer for byte[] for the
SOAP encoding style. String objects are serialized simply by writing the
contents, again for the SOAP encoding style. Deserialization happens in the
reverse.
 
You could  write a custom serializer to serialize/deserialize Strings as
base64 if you want. But this would apply to all Strings sent between client
and server. You could also do as you suggested and base64 encode the string
first :-)

 
CDATA is not really an option, b/c a) the CRLF/CR => LF conversion gets
applied to the CDATA contents by the XML processor and b) it will not handle
string that are XML documents containing CDATA sections (then you have
embedded CDATA)
 

OK, thanks.
 
 


Mime
View raw message