Allow to use raw binary data as NeoFS response

[fyrchik]

Summary or problem description Currently for every oracle request Filter is executed https://github.com/neo-project/neo-modules/blob/master/src/OracleService/OracleService.cs#L249 . It expects UTF-8 string as data. NeoFS data can be binary (like gethash). This is currently mitigated by converting to base64 and adds some overhead.

Do you have any solution you want to propose? Use raw returned bytes for data returned from NeoFS. If filter is used for binary data we may fail, but again usually it is not and when I use e.g. GetHash I expect to receive raw hash, not it's base64 encoding.

Where in the software does this update applies to?

• Plugins

[erikzhang]

https://github.com/neo-project/neo-modules/blob/603ecec356d4ec675023501cb59c24d1e4ded73b/src/OracleService/OracleService/config.json#L7

We only support JSON as the oracle response.

[erikzhang]

I think we need a way to get the content-type of NeoFS objects.

[realloc]

NeoFS object doesn't have content-type as a separate header field, but it can be set as an Attribute. Attributes are optional, hence we can define Content-Type as a well-known attribute in specification and check it if it was set.

[erikzhang]

Attributes are optional, hence we can define Content-Type as a well-known attribute in specification and check it if it was set.

Can Content-Type be mandatory?

[realloc]

Can Content-Type be mandatory?

No. Object content is treated as blob, we can't verify if it's correct, hence we can't make this mandatory.

Attributes are optional by design and moving content type to a header field will require us to make some verification mechanism, which is impractical to introduce, will be faulty and breaks current design.

Objects without content-type set to "application/json" will not be accessible through Oracles, so having a well-known attribute set by user should satisfy current Oracle design and requirements. Setting this attribute, if possible, should be responsibility of a client software anyways.

[roman-khimov]

It's a little strange for me that we're only allowing JSON (NeoFS could easily store serialized stack items, for example), but if that's the case we need to settle on returned results for various commands (which also affects neo-project/docs#1199 and #554):

• no command: I'd expect it to return object's payload as is, if we care about it being JSON we can check for it, but it shouldn't be wrapped in any way
• range: this is less useful for JSONs, but we probably want to have the same behavior as for "no command" case
• header: it's JSON, so we return it as is
• hash: this is the only thing that can't be JSON originally and it really needs to be wrapped, we just need to settle on how exactly to wrap it ({"hash": "base64-value"}, for example)

[erikzhang]

hash: this is the only thing that can't be JSON originally and it really needs to be wrapped

What is the format of hash? What is its length?

[roman-khimov]

It's an SHA256 hash, so it's just raw 32 bytes.

[erikzhang]

Then we can return it as a string, just like a hash of a block.

"0xd42561e3d30e15be6400b6df2f328e02d2bf6354c41dce433bc57687c82144bf"