Invalid URL with Derby Client when connecting to Network Server causes protocol exception.

• Key: DERBY-374
• Type: Bug
• Status: Closed
• Resolution: Fixed
• Priority: Major
• Assignee: Deepa Remesh
• Reporter: A B
• Component/s: Network Client
• Affects Version/s: 10.1.1.0, 10.2.1.6
• Fix Version/s: 10.1.2.1, 10.2.1.6

Description

If using the Derby Client to connect to the Derby Network Server, there are some cases where an invalid URL will cause a protocol exception instead of throwing a proper error. The two cases I've found are as follow:

1) Use of a colon to separate attributes:

When connecting to the server with JCC, a colon is required to demarcate the Derby attributes from the JCC attributes. For the Derby Client, however, the colon is not a valid part of the URL, so use of it should return an error. However, the result is a protocol exception:

ij> connect 'jdbc:derby://localhost:1528/sample:user=someUsr;password=somePwd';
agentThread[DRDAConnThread_9,5,main]
ERROR (no SQLState): A communication error has been detected. Communication protocol being used: Reply.fill(). Communication API being used: InputStream.read(). Location where the error was detected:
insufficient data. Communication function detecting the error: *. Protocol specific error codes(s) TCP/IP SOCKETS

2) Use of double-quotes to specify a full path to a database.

The use of double-quotes around a database path is required when connecting to the server with JCC, but should be optional when using the Derby Client. However, attempts to use the double-quotes doesn't work--on the contrary, it throws a protocol exception:

ij> connect 'jdbc:derby://localhost:1528/"C:/myDBs/sample"';
agentThread[DRDAConnThread_11,5,main]
ERROR (no SQLState): A communication error has been detected. Communication protocol being used: Reply.fill(). Communication API being used: InputStream.read(). Location where the error was detected:
insufficient data. Communication function detecting the error: *. Protocol specific error codes(s) TCP/IP SOCKETS

Without quotes, the above example will work as expected.

I'm not sure if the problem is with the Derby client or the Network Server (more investigation required).

Comments

[Andrew McIntyre]

Moving to 10.2.

[Deepa Remesh]

The patch fixes the first case 1) Use of a colon to separate attributes. ClientDriver.java now checks for ":" in the database name and attributes part of URL. A ":" is accepted if the database name is specified as an absolute path on Windows (C:/myDBs/sample). In all other cases, it will give "Invalid database url syntax".

I think case 2) Use of double-quotes to specify a full path to a database is not valid. This is not supported by Derby embedded driver.

Ran derbyall with Sun JDK 1.4.2. No failures.

If case 2 is invalid, wouldn't it be more appropriate for the code to catch it and print a reasonale error message than to throw a protocol exception?

If you use double-quotes in embedded Derby you get a reasonable error:

ij> connect 'jdbc:derby:"C:/myDBs/sample"';
ERROR 08001: No suitable driver

It seems like we should either throw a similar error for the client or else throw the same "Invalid database url syntax" error that we throw in case 1. I think either would be better than the protocol exception since the protocol exception doesn't give any indication as to what went wrong...

[Deepa Remesh]

Submitting patch derby-374-patch2.diff. Added additional check to look for double quotes in the database name and attributes part of URL and throw "Invalid database url syntax".

[Deepa Remesh]

Resubmitting the patch as derby-374-patch3.diff with changes to master file. The previous patch was using backslash as path separator in the master file. As pointed out by Knut, this would fail in non-windows environments.

[Deepa Remesh]

Attaching a patch derby-374-patch.diff for network server and client to handle invalid URLs. This patch does the following:

1. Network server used to give NPE when InternalDriver returns null connection for certain malformed URLs. With this patch, network server checks for null connections returned by InternalDriver and returns RDBAFLRM and SQLCARD with null SQLException. I spoke to Kathey about how to pass null SQLCARDs.
2. The client parses the SQLCARD and if finds null SQLException, it sets connectionNull variable in NetConnection to true.
3. ClientDriver connect method, which calls the constructor of NetConnection, gets back an object with connectionNull set to true. And it inturn returns null connection.
4. Added tests to checkDriver.java for more Client URLs.

Army, This patch handles the URLs you mentioned. Does this look okay to you?

[A B]

I applied the patch to my local codeline and the resultant behavior looks good to me. If you can confirm that you've run the nightlies with this latest patch and everything ran as expected, then I give a +1 to commit. Thanks for following through with this, Deepa.

[Deepa Remesh]

Army, Thanks for reviewing the patch. I have run derbyall with this patch using Sun jdk 1.4.2. No failures.

[Kathey Marsden]

I committed this change to the trunk. Thanks too for cleaning up the ACCRDB failure code in Network Server.

Date: Fri Sep 30 21:30:43 2005
New Revision: 292917

URL: http://svn.apache.org/viewcvs?rev=292917&view=rev

[Kathey Marsden]

I was thinking with this change that it would be good to check the problem url using the

1) 10.1 client with the 10.2 server
2) 10.2 client with the 10.1 server.

Just to make sure it doesn't introduce a hang or anything worse than the protcol error we were getting before.
Deepa, would you mind checking that out?

[Deepa Remesh]

In my local codeline, I merged this patch to 10.1 and ran derbyall on WinXP with Sun jdk1.4.2. No failures. The merge command I used is:
svn merge -r 292916:292917 https://svn.apache.org/repos/asf/db/derby/code/trunk

Please merge this to 10.1 branch.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Results of the url test suggested by Kathey (copying to JIRA entry from the mailing list for reference):
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I tried all the Client URLs added in the test jdbcapi/checkDriver.java.

With 10.1 server and 10.2 client : behaviour same as before this patch. (protocol error)
With 10.2 server and 10.1 client: Instead of protocol error, client throws a SQLException with null message. ij displays:
ERROR : DERBY SQL error: SQLCODE: -1, SQLSTATE: , SQLERRMC: null
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

[Kathey Marsden]

Committed this to 10.1

Date: Thu Oct 6 15:28:44 2005
New Revision: 306942

URL: http://svn.apache.org/viewcvs?rev=306942&view=rev

[Deepa Remesh]

The attached patch "derby374_test_changes.diff" removes client URLs, which behave differently on Windows and non-Windows systems, from the test
jdbcapi/checkDriver.java.

svn status output:
M java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\checkDriver.java
M java\testing\org\apache\derbyTesting\functionTests\master\DerbyNetClient\checkDriver.out

I ran the test checkDriver.java with DerbyNetClient framework on Windows. I don't have access to any non-windows machine. I would appreciate if someone can run this test on a non-windows machine to confirm. The patch for DERBY-374 was merged to 10.1 branch also. So please commit this test change to trunk as well as 10.1 branch.

The test for DERBY-374 has to cover a case where the embedded driver returns a null connection to network server. This is still being covered by the test. For the removed client urls, I am thinking of some way they can be added back to the test.

[Kathey Marsden]

Checked test change into trunk:
Disable some tests which are failing on unix until a cross platform solution
can be found

Date: Fri Oct 7 18:31:35 2005
New Revision: 307231

URL: http://svn.apache.org/viewcvs?rev=307231&view=rev

and 10.1

Date: Fri Oct 7 18:40:13 2005
New Revision: 307232

URL: http://svn.apache.org/viewcvs?rev=307232&view=rev

[Deepa Remesh]

Checked that the changes are in trunk (10.2) and 10.1 branch. svn revisions are:
10.2 - 292917, 307231
10.1 - 306942, 307232

Also created a sub-task for adding the removed URLs back to the test (DERBY-617).

[A B]

Fix for this has been in 10.1 and 10.2 since last October, so I'm marking it as closed. Thanks Deepa!