V3.0.* : sending JSON via REST returns "java.lang.IllegalArgumentException: Input byte array has incorrect ending byte at 20"

Sending JSON requests or batches via REST-API works fine in OrientDB v2 versions, but not anymore in v3:

the servers replies:

{
  "errors": [
    {
      "reason": 505,
      "code": 505,
      "content": "java.lang.IllegalArgumentException: Input byte array has incorrect ending byte at 20"
    }
  ]
}

If I enter this URL “http://10.101.22.126:2480/listDatabases” in my browser, then I get the expected result (database: “cdrarch”):

{"@type":"d","@version":0,"databases":["cdrarch"]}

using “tcpdump”, these are the network packet contents of what gets exchanged with the server:

a) the “tcpdump” captured packet with the request to the v3.0.24 server:

GET /listDatabases HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: application/json
Accept-Encoding: gzip,deflate
Authorization: Basic ...(encoded password)
Host: 10.101.22.126:2480
User-Agent: REST::Client/273
Content-Length: 0
Charset: UTF-8

b) the error-reply from the v3.0.24 server:

HTTP/1.1 505 Error on executing of GET for the resource: /listDatabases
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Date: Sun Nov 03 15:42:54 MET 2019
Content-Type: application/json; charset=utf-8
Server: OrientDB Server v.3.0.24 - Veloce (build 9920dff342aee1351c89e749d3f0a94ce466355b, branch 3.0.x)
Connection: close
Content-Length: 185
{
  "errors": [
    {
      "reason": 505,
      "code": 505,
      "content": "java.lang.IllegalArgumentException: Input byte array has incorrect ending byte at 20"
    }
  ]
}

c) “tcpdump” captured packet of exactly the same request to a v2.2.37 server (different IP addr) :

GET /listDatabases HTTP/1.1
TE: deflate,gzip;q=0.3
Connection: TE, close
Accept: application/json
Accept-Encoding: gzip,deflate
Authorization: Basic ...(encoded password)
Host: 10.100.22.126:2480
User-Agent: REST::Client/273
Content-Length: 0
Charset: UTF-8

d) and the (correct) answer from that v2.2.37 server :

HTTP/1.1 200 OK
Date: Tue, 12 Nov 2019 15:21:53 UTC
Content-Type: application/json; charset=utf-8
Server: OrientDB Server v.2.2.37-SNAPSHOT (build b041441a53b1666cb52872a14878750b54b7784b, branch branches/2-2-x.15993v/workspace/core)
Connection: close
ETag: 0
Content-Length: 50

{"@type":"d","@version":0,"databases":["cdrarch"]}

e) the “tcpdump” packets captured when raising the identical same URL from my browser on Windows-PC, shows the following request content :

GET /listDatabases HTTP/1.1
Connection: keep-alive
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate
Host: 10.101.22.126:2480
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0
Accept-Language: en-GB,en;q=0.5
DNT: 1
Cookie: OSESSIONID=OS1572508643268-3115553657295271176
Upgrade-Insecure-Requests: 1
If-None-Match: 0

From my browser, other parts in the HTTP request are set, like a difference in the “Accept” attribute, and -obviously- the “User-Agent”.

So you can see that, absent from any programming language specifics, the network packet containing the HTTP/GET to the two servers is identical, but the v3.0.24 server is failing to process this request correctly.

-> the documentation does not contain any hints
-> has anybody any experience what specific HTTP headers the v3 server REST API would need/expect?
-> is the “User-Agent” maybe not understood by the v3 server ?

thx all for any replies !
Rob

I found the cause (see bug report “https://github.com/orientechnologies/orientdb/issues/9053”) :

The BASE64 encoding of authentication credentials (“username:password”) produces a string with a trailing space/blank character at the end.
The OrientDB v3 server is not stripping any such unexpected trailing space from the encoded string and fails to accept the REST request, whereas the OrientDB v2 version servers are doing that stripping and accept correctly the REST request.

So,

  1. I will strip away myself any unexpected trailing space from this encoded credentials that go in the HTTP headers, but
  2. OrientDB v3 would be a lot more robust if it would ‘cleanup’ the received input parameters (such as HTTP headers)
1 Like