Re: String encoding problem (WSMethodInvocation)

FROM : Nick Toumpelis
DATE : Tue Jan 29 10:26:45 2008

It seems to me that the problem here lies with the actual encoding 
used in the invocation, rather than the designated character set. Both 
issues may be present though. I haven't used SOAP yet and it is very 
likely that the SOAP implementation has a different problem altogether.

As far as I can tell, in the case of XML-RPC, implementing a different 
serialization method for strings is the solution. I'm not sure whether 
this affects the encoding designation in the header in any way.

Thanks,

Nick

P.S. Apple has to respond to these, at some point... The issue 
submitted by Stéphane is more severe than the one I've encountered.


On 29 Ιαν 2008, at 12:10 ΠΜ, Nir Soffer wrote:

> On Jan 25, 2008, at 11:22, Nick Toumpelis wrote:
>

>> I assumed that something like this might be the problem, so I 
>> overode the serialization procedure with 
>> WSMethodInvocationAddSerializationOverride. And it works (more or 
>> less).
>>
>> It appears that there is an additional bug with the actual encoding 
>> itself.
>>
>> Nick
>>
>> On 25 Ιαν 2008, at 10:06 ΠΜ, Stéphane Corthésy wrote:
>>

>>> rdar://problems/4792516
>>>
>>> Sent on 19-Oct-2006
>>>
>>> WebServicesCore: SOAP messages miss charset information in HTTP 
>>> header
>>>
>>> Summary:
>>> HTTP header in HTTP requests generated by WebServicesCore, for 
>>> kWSSOAPBodyEncodingStyle, miss  a 'charset=utf-8' key-value in the 
>>> content-type header.
>>>
>>> Steps to Reproduce:
>>> 1) Using WebServicesCore, create a web invocation, with debug 
>>> information on.
>>> 2) Send the invocation, and wait for result.
>>> 3) When receiving results, look at the outgoing headers, in the 
>>> result dictionary.
>>>
>>> Expected Results:
>>> The header value for 'content-type' should contain the charset 
>>> used to encode the body, because body is encoded in UTF-8, and 
>>> without any information in the header, all receivers will decode 
>>> body using ISOLatin1 charset.
>>>
>>> Actual Results:
>>> If sent body contains non-ASCII characters, body is wrongly 
>>> decoded using ISOLatin1.
>>>
>>>
>>> Apple never replied to that bug report. Status is still set to 
>>> open, though it's 15 months old.

>
> According to this:
> http://www.rfc-editor.org/rfc/rfc3023.txt 3.1 Text/xml Registration
>
> If a charset is not specified, the receiver should use us-ascii, 
> which explain your issue.


Nick Toumpelis :: Software Developer :: BEng (Wales), MSc (Manchester)
Thessaloniki, Greece :: email:<email_removed> :: AIM:<email_removed>