[
https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15825589#comment-15825589
]
ASF GitHub Bot commented on TINKERPOP-1600:
-------------------------------------------
Github user vtslab commented on the issue:
https://github.com/apache/tinkerpop/pull/533
While this solves the issue for byte[] returned from Sasl, I can still
crash the driver by adding a byte[] as a vertex property and ask for the result:
gremlin> g.V(1).property('test1', 'test1' as byte[])
==>v[1]
gremlin> g.V(1).values('test1')
==>[116, 101, 115, 116, 49]
gremlin> g.V(1).values('test1').next().getClass()
==>class [B
OK, this is a pathological example, why configure serializeResultToString
if you want a byte[] returned... BTW, what is this serializeResultToString
meant for anyway?
> Consistent use of base 64 encoded bytes for SASL negotiation
> ------------------------------------------------------------
>
> Key: TINKERPOP-1600
> URL: https://issues.apache.org/jira/browse/TINKERPOP-1600
> Project: TinkerPop
> Issue Type: Improvement
> Components: driver, server
> Affects Versions: 3.2.3
> Reporter: stephen mallette
> Assignee: stephen mallette
> Fix For: 3.2.4
>
>
> Gremlin Server currently uses a mix of base 64 encoded bytes and byte arrays
> for SASL negotiation. This can cause problems for certain serializers (like
> toString serialization with gryo) as the byte array won't be respected. In an
> effort to easily support virtually any serializer a switch to using just base
> 64 string is probably best.
> This can be done in such a way as to be backward compatible. The base64 SASL
> value will be returned in the response message status attributes map in a key
> called "sasl". The original byte array will continue to be returned in the
> response message result. Eventually, we could phase out the byte array in the
> result - perhaps with 3.3.0.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
