You are viewing a plain text version of this content. The canonical link for it is here.
Posted to xmlrpc-dev@ws.apache.org by Andrew Evers <an...@redwood.com> on 2003/03/10 17:45:17 UTC

[Bug 17665] - XML-RPC client doesn't handle the enconding specified by the XmlRpc.setEncoding() method

I've just had a look at this myself, since I refactored some of the classes 
involved recently. The proposed solution will work OK in a closed 
system where you already know the encoding sent back by the server. 
It may well break if you force the encoding to be something non-UTF 
when it is really UTF, or vice versa.

There are four encodings involved:
1. The client write encoding 
    This is governed by XmlRpcClientResponseProcessor.getEncoding(), 
    which is usually XmlRpc.getEncoding().
2. The server read encoding (governed by XmlRpc.parse()).
    There is no explicit read encoding - we allow the XML parser to
    detect it.
3. The server write encoding
    This is governed by XmlRpcRequestProcessor.getEncoding(),
    which is usually XmlRpc.getEncoding().
4. The client read encoding (governed by XmlRpc.parse()).
    There is no explicit read encoding - we allow the XML parser to
    detect it.

In the case of a system that only uses our packages, this means that
setting the encoding on the client or the server will only set the encoding
for writing. The read encoding is left to the XML parser to decide. This
is desirable behaviour. The problem is that MinML doesn't seem to do 
this (although I am open to corrections).

I think we should add a method setEncoding(String enc, boolean force) to 
XmlRpc allow the encoding to be forced and modify parse(InputStream)
accordingly. The current setEncoding(enc) becomes setEncoding(enc, false). 
This would effect parts 2 and 4, and have the same effect as the proposed
solution with no autodetection issues.

This preserves the current encoding neutrality, while allowing the encoding
to be forced if need be.

I think for version 2.0 it the server should write the response using the 
encoding of the request, at least for encodings that maintain the lower 
7 bits of ASCII. This would allow the client to specify the encoding.

Andrew.



Re: [Bug 17665] - XML-RPC client doesn't handle the enconding specified by the XmlRpc.setEncoding() method

Posted by John Wilson <tu...@wilson.co.uk>.
----- Original Message -----
From: "Andrew Evers" <an...@redwood.com>
To: <xm...@ws.apache.org>
Sent: Monday, March 10, 2003 4:45 PM
Subject: [Bug 17665] - XML-RPC client doesn't handle the enconding specified
by the XmlRpc.setEncoding() method


[snip]

> In the case of a system that only uses our packages, this means that
> setting the encoding on the client or the server will only set the
encoding
> for writing. The read encoding is left to the XML parser to decide. This
> is desirable behaviour. The problem is that MinML doesn't seem to do
> this (although I am open to corrections).

MinML does not to autodetect of encoding nor does it take notice of the
encoding part of the XML declaration (if present).

I am in process of fixing both these issues. The next release of MinML will
support both auto detection and the encoding part of the XML declaration .

John Wilson
The Wilson Partnership
http://www.wilson.co.uk