Mike Burati wrote:
i can confirm it that this is UTF8 related problem with the service
and not with AXIS.
i have run the same test with XSUL SOAP stack using SDI and it failed
in my UTF8 decoder as well.
the byte sequence is incorrect: 0xE0 0x20 ("a`" " ") - E0 indicates that
it is start of two byte encoded sequence as high bit is set so following
bitmask is expected: 1110xxxx 10xxxxxx 10xxxxxx but 0x20 is not 10xxxxxx
so it is clearly incorrect UTF-8 (that explanation is not 100% guranteed
as i tend to forget such stuff ...)
Thanks, I was hoping it was the service as I didn't have time to debug
what was going on deep down in AXIS (and then crimson/xerces) today :-).
I had tried the service with SOAPScope and it didn't complain...
Now that you clarified that it does fail with a UTF-8 issue with another
(non-AXIS) toolkit, I double checked the simple SOAP envelope posting
class (debug tool) I had written a couple years ago and sure enough I
wasn't explicitly setting the encoding for the response stream, just for
the outgoing soap envelope. When I try to read the envelope using
UTF-8, it fails for me too even with that simple output/intput stream
URLConnection debugger. If I tell it to use ISO-8859-1 for the response
envelope, then it does decode that char correctly, so I'll assume the
service provider is incorrectly encoding via ISO-8859-1 despite it
claiming that it's encoded via UTF-8...
i think you are right - what we see is Latin-1 output incorrectly
described as UTF8 ...
Thanks again - that saved me some time - I would've started debugging
too low in the stack after running that first non-AXIS toolkit and
seeing it work ok... Your clarification that another toolkit failed
kept me from digging the hole deeper when the problem was right at the
surface :-)...
i am glad to hear that ;-)
alek
--
The best way to predict the future is to invent it - Alan Kay
