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": 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