[
https://issues.apache.org/jira/browse/DERBY-728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12661713#action_12661713
]
Kathey Marsden commented on DERBY-728:
--------------------------------------
I have been talking with the local DRDA experts and found out that they are
working on a new DRDA ACR for a UNICODEMGR which I think can help us with this
issue. The short summary is this:
EXCSAT and ACCSEC are always sent EBCDIC. As part of the MGRLVL exchange,
client sends UNICODEMGR 1208 which means that it is requesting all additional
DDM parameters will be exchanged in code page 1208. The server responds with
UNICODEMGR 1208 if it can accommodate the request. Otherwise it responds with
UNICODEMGR 0 and all DDM parameters will continue to be exchanged in EBCDIC.
One problem with this approach is that ACCSEC currently has an RDBNAM parameter
which we treat as required (the spec lists it as optional) and that has to be
sent EBCDIC. So, my proposal is that we use the UNICODEMGR and we send RDBNAM
on ACCSEC *only if* the EBCDIC conversion can be done. If the conversion
can't be done, we send no RDBNAM on ACCSEC. Then we change the server to use
the RDBNAM sent with the unicode SECCHK instead of the one sent on ACCSEC.
(Currently we just verify that the SECCHK RDBNAM is the same as the one that
was sent on ACCSEC.)
For an old client working with a new server, there will be no regression and
the error message on sending a database name with international characters will
be the same as currently listed in
DERBY-728.
For a new client working with a old server, this will mean that all the cases
that currently pass will still pass, but if a nonconvertible database name is
sent (e,g, one with Chinese
characters) , the server will send back a SYNTAXRM and the
server console will show:
= 2110; Error Code Value = e. Plaintext connection attempt
from an SSL enabled client?
org.apache.derby.impl.drda.DRDAProtocolException: Execution
failed because of a Distributed Protocol Error: DRDA_Proto_
SYNTAXRM; CODPNT arg = 2110; Error Code Value = e. Plaintext
connection attempt from an SSL enabled client?
at
org.apache.derby.impl.drda.DRDAConnThread.throwSyntaxrm(DRDAConn
Thread.java:513)
at
org.apache.derby.impl.drda.DRDAConnThread.missingCodePoint(DRDAC
onnThread.java:543)
at
org.apache.derby.impl.drda.DRDAConnThread.parseACCSEC(DRDAConnTh
read.java:1948)
at
org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDACo
nnThread.java:943)
at
org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.jav
a:290)
The client could intercept the SYNTAXRM and knowing it was unable to convert
the RDBNAM to EBCDIC could throw the same message it does now. The only
regression would be that users attempting to send an invalid database name
would now see the server side protocol error occur. I think it is an
acceptable regression, since it won't cause any working cases to fail even
with mixed revision server/client and it will enable us to move forward and
have internationalized database name, user and password.
I prototyped the change and it all seemed to work ok. I'll attach the
prototype patch.
I would like to implement as much as possible of this for 10.5, but since
approval of the ACR by opengroup won't happen by the time we release 10.5, I
propose to make the implementation dependent on a client system property
derby.drda.unicodemgr=true. This would be false by default but could be switch
to true in a maintenance release once opengroup approval occurs. Currently the
hope is to have the ACR available publicly by the end of January. Then I would
need Rick's help to try to push it through opengroup since he is our opengroup
rep. I don't know how long that takes.
> Unable to create databases whose name containg Chinese characters through the
> client driver
> -------------------------------------------------------------------------------------------
>
> Key: DERBY-728
> URL: https://issues.apache.org/jira/browse/DERBY-728
> Project: Derby
> Issue Type: Bug
> Components: Network Client
> Affects Versions: 10.1.2.1
> Environment: Debian unstable, LInux 2.6.14.2, libc 2.3.5-6
> Reporter: Andrei Badea
> Attachments: derby-728-startingpoint.diff
>
>
> Trying to create a database with the following URL (note the Chinese
> character in the database name):
> jdbc:derby://localhost:1527/\u4e10;create=true
> throws the following exception:
> -----%<-----
> Exception in thread "main" org.apache.derby.client.am.SqlException: Unicode
> string can't convert to Ebcdic string
> at
> org.apache.derby.client.net.EbcdicCcsidManager.convertFromUCS2(Unknown Source)
> at
> org.apache.derby.client.net.Request.writeScalarPaddedString(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.buildRDBNAM(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.buildACCSEC(Unknown Source)
> at
> org.apache.derby.client.net.NetConnectionRequest.writeAccessSecurity(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.writeServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowServerAttributesAndKeyExchange(Unknown
> Source)
> at
> org.apache.derby.client.net.NetConnection.flowUSRIDONLconnect(Unknown Source)
> at org.apache.derby.client.net.NetConnection.flowConnect(Unknown
> Source)
> at org.apache.derby.client.net.NetConnection.<init>(Unknown Source)
> at org.apache.derby.jdbc.ClientDriver.connect(Unknown Source)
> at java.sql.DriverManager.getConnection(DriverManager.java:525)
> at java.sql.DriverManager.getConnection(DriverManager.java:193)
> at jdbctest.Main.main(Main.java:33)
> -----%<-----
> It's possible, however, to create databases using the embedded driver, using
> an URL like:
> jdbc:derby:\u4e10;create=true
> Tested with both 10.1.1.0 and 10.1.2.1 with the same result.
> Complete code to reproduce the bug:
> -----%<-----
> public static void main(String[] args) throws Exception {
> Class.forName("org.apache.derby.jdbc.ClientDriver");
> Connection conn =
> DriverManager.getConnection("jdbc:derby://localhost:1527/\u4e10;create=true");
> }
> -----%<-----
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
