#5 Modifications to CyberLink for Java

[Chad Wilson]

Hello all, I recently have been having various issues
with routers and the Cyberlink library and I tracked
down a few issues. Enclosed is a patch file with all
my changes to date.

The first is correct character encoding over the wire.
The source on SVN/CVS at sourceforge, had UTF-8 being
declared both in the HTTP header, as well as the XML
declaration. Unfortunately when data was send over the
wire via OutputStream, it was defaulting to the
platform character encoding. There was an attempt made
in Node.toString() to utilize UTF-8, but it did not
work. The problem was that String objects natively
store data in UTF-16, so what was happening was that
the node data was being converted to UTF-8, then
converted back to a string which was then stored as
UTF-16. When sent over the wire, the String would be
converted to the platform's default character encoding
(see
http://java.sun.com/j2se/1.5.0/docs/api/java/io/PrintStream.html#print\(java.lang.String)).

So what I did was make sure that the correct character
encoding was being used over the wire, as well as being
noted in both the XML and Content-Type declarations.
This required a few changes throughout the packages to
make certain that character encoding was being handled
correctly. I also created a setCharSet method inside
of XML.java. This allows the default character
encoding to be changed on the fly in case of router
incompatibility (Linksys does not play well with UTF-8,
but has no troubles with Latin-1). I consolidated the
character encoding dependent declarations inside of
XML.java and created public get methods accordingly.

Another minor change was to force US-ASCII as the
character encoding when dealing with header information
in HTTP packets. This conforms with the HTTP spec. I
also included the logic from RFC 3023
(http://www.ietf.org/rfc/rfc3023.txt) in
HTTPPacket.getCharSet(). There were also some minor
changes and additions to the build.xml file to include
some missing path entries. Finally, I included a
little cleanup at the end of the set method in
HTTPPacket. This covers a few fringe cases (such as
certain Netgear routers, MR814 and DG814 see
http://www.sbbi.net/forum/viewtopic.php?t=25&sid=9d2575e66e15eac3f346f4385e17dd39\)
where the null character is sent over the wire at the
end of the XML. This of course causes the parser to
throw an exception. The way I did it is a little
expensive since it goes from bytes to String to bytes,
but StringBuffer & StringBuilder do not handle
character encodings. If you can come up with a more
elegant approach please let me know so I can include it
in my build :)

There were two changes that I was unsure as to their
nature. The first was UPnP.java. I changed the XML
parser to be used from kXML2 to Xerces. I am curious
as to why that was neccesary, as previous versions of
the clink library have had no problems using any parser
given to them. The second was a changed to the
DEFAULT_CHUNK_SIZE inside HTTP.java. This created a
500KB buffer, which seems quite large for an HTTP
packet. I set it to 1KB instead.

Please let me know what you think, and if you need any
additional information. Cheers!

Chad A. Wilson

[Chad Wilson]

Patch

[Stefano Lenzi]

Logged In: YES
user_id=901512
Originator: NO

it seems to me that the patch has been applied for 1.7 but I'll check the code