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 |
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) |
Up to any 10 HTTP REQUEST HEADER and their values value | Example SDK Params:
...
fwdHeaderKeys: "authorization", fwdHeaderMapLookup: { "authorization": | 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 |
Last updated