[
https://issues.apache.org/jira/browse/TINKERPOP-1600?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15827941#comment-15827941
]
ASF GitHub Bot commented on TINKERPOP-1600:
-------------------------------------------
Github user spmallette commented on the issue:
https://github.com/apache/tinkerpop/pull/533
@vtslab i just pushed a fixup commit - i had a sorta dumb mistake on this
pr. i knew that having your work would uncover this - it's good that you had
#534 ready. I merged your changes locally onto this branch and the tests now
pass without any additional changes on your end.
I'm going to get this merged to tp32/master now. At that point you can
rebase (hopefully the last time) and I can put some focus on full review of
your PR.
> 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)
