bloomrpc Incorrect default template for bytes type

When using the bytes type, the default template that the editor creates is incorrect and does not correctly serialize.

With the example message,

message Policy {
  bytes etag = 2;
}

the editor creates the template:

{
  "etag": {
    "type": "Buffer",
    "data": [
      164,
      178,
      11,
      40
    ]
  }
}

When used in a request, this does not correctly serialize and results in an empty/omitted etag being sent.

If you change the request such as so:

{
  "etag": [ 1, 2, 3, 4 ]
}

or as so:

{
  "etag": "YWJjMTIzIT8kKiYoKSctPUB+"
}

then it is correctly serialized.

The latter example is a base64 encoded string. As specified in the Language Guide (proto3), the bytes type should be encoded as a base64 string in JSON.

As such, may I suggest changing the default template to use a base64 encoded string for the bytes type. :)

Jul 24 '19 04:07 shaneqld

@shaneqld Hi, Thanks for the very detailed issue, much appreciated!

This is interesting, I'll be trying this out and release a fix for the coming release!

Jul 24 '19 08:07 fenos

Hi guys,

I have the same problem as @shaneqld. Although, even if I change the request as @shaneqld commented, the parse still doesn't happen. If you need any help, just let me know.

Dec 09 '19 17:12 VictorMonte-zz

Hey guys, we have the same issue. Just to follow up on @shaneqld 's point, if you are going to support byte encoding to string, I would suggest encoding as hex instead of base64 in order to make it more readable and compatible with other things like bitcoin for example. Cheers!

Jul 11 '20 23:07 jadwahab

Hey guys, we have the same issue. Just to follow up on @shaneqld 's point, if you are going to support byte encoding to string, I would suggest encoding as hex instead of base64 in order to make it more readable and compatible with other things like bitcoin for example. Cheers!

JSON mapping should follow Proto3 Language Guide, which specifies base64 for the bytes type. I don’t think it would be wise to deviate from the standard.

Jul 11 '20 23:07 shaneqld

I still have the same issue in version "Version 1.4.1 (1.4.1.145)". Any update about it? Thank you

Jul 21 '20 08:07 ptadros

Still an issue in Version 1.5.2

Dec 22 '20 11:12 antonhagser

It seems according to the comments on https://github.com/uw-labs/bloomrpc/issues/29 that it is intended to correctly serialize, but it doesn't work. I also cannot read the sent value on a Go server.

I'd like to additionally request that when fixing the issue so that the Buffer type serializes correctly, that you support input formatting in the same way as metadata - https://github.com/uw-labs/bloomrpc/pull/123

The reason for this is here: https://stackoverflow.com/questions/66378163/grpc-test-client-gui-that-supports-representing-a-bytes-type-as-a-hex-string I want to be able to put a hex string "6000e9720C683f1b8e638a49" and have that be interpreted as a byte array instead of having to manually convert and enter [96,0,233,114,12,104,63,27,142,99,138,73]. I believe that the formatting logic that already exists for the metadata Buffer would enable this. I think I should be able to enter it as: "elementname": { "type": "Buffer", "data": "binary:6000e9720C683f1b8e638a49" }