Skip to content

Latest commit

 

History

History
30 lines (18 loc) · 9.43 KB

data-marshal-transit-flags-and-headers.md

File metadata and controls

30 lines (18 loc) · 9.43 KB
Raw

Data Marshal Transit Flags and Headers

Accepted Flags

The Data Marshal Node network can respond to various flags that are injected via "query string params" and/or "response headers" that are attached to the Data Streams by their creators to trigger some custom behavior. These accepted flags are as follows:

\

Flag How to use Example What it does
dmf-nestedstream=1

[URL QueryString]

Append this to your Data Stream URL

ipns://k51qzi5uqu5dkgpkqwl7gf60fu4clninr3fsge2i7x67kz0xfz5in5pu61epti?dmf-nestedstream=1

Once the Data Marshal sees this flag, it will treat the Data Stream content as a "Nested Stream."

See guide-3-using-nested-streams-to-access-nested-data-assets-from-a-primary-data-stream.md

dmf-dnslink=1
&
dmf-http=1

[URL QueryString]

Append both these to your Data Stream URL

 http://mydoamin.x/myfile.json?dmf-dnslink=1 &dmf-http=1 As we support the DNS Link standard for IPFS based Data Streams, most of the IPFS DNS Link gatways are still not HTTPS compatible. So here, the Data Stream creator uses thes query string params to inform the Data Marshal node to allow for "http" only in this scenario
dmf-allow-http403=1

[URL QueryString]

Append this to your Data Stream URL

https://api.itheumcloud-stg.com/datadexapi/bespoke/dynamicSecureDataStreamDemo?dmf-allow-http403=1 A flag to inform the Data Marshal (and also the minting UI in the Data DEX for Data NFT-FT) that this is a Data Stream that has some authentication system (e.g. MultiversX Native Auth) and therefore returns a 403 (forbidden HTTP code) instead of a usual 200 OK. This is useful to inform the Data Marshal that 403 is actually OK during an uptime check as it is what the Data Creator wanted.
x-amz-meta-marshal-deep-fetch=1

[Server Response Header]

Your Data Stream origin server can send this as response header

 Send as regular HTTP response header The same behavioir as the above "dmf-nestedstream=1" param, but is triggered by a server response header instead in he event you want to do this

Injected Headers

The Data Marshal Node network also injects some extra headers into each stream before it forwards it to the Data Stream origin server, which can then be used as needed. These injected headers are as follows:

Header Possible Values / Samples What it does
itm-marshal-fwd-chainid

ED = MultiversX Devnet

E1 = MultiversX Mainnet

 Provides the chain ID of the caller (usually via the data-nft-sdk init config)
itm-marshal-fwd-tokenid


The NFT token ID of any supported SFT or NFT collection.

e.g.
DATANFTFT-e0b917-ca (e.g. SFT)

DNFTPHNAUT-f3f22a-02 (e.g. NFT)

 After validating the ownership of this Data NFT via the caller's authentication proofs, it forwards this value to the Data Stream origin server which can then use this to personalize the data stream response for the user. See example guide data-nft-ph-plug-in-hybrid.md
Up to any 10 HTTP REQUEST HEADER and their values value

Example SDK Params:
...
fwdHeaderKeys: "authorization", fwdHeaderMapLookup: { "authorization": Bearer ${nativeAuthToken}, }
...

When you "unlock" a Data NFT via the data-nft-sdk, you can ask it to forward up to 10 HTTP Request Headers and set their values and all these values are forwared by the Data Marshal onto the Data Stream Origin Server.

For example, to send over any client side "Authrization" Bearer token values, you can use the Data NFT SDK to forward them.

See a code sample here