{
    "api_version": "1",
    "kind": "dse_post",
    "self": "https://update.dsesecurity.com/api/v1/posts/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
    "item": {
        "id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
        "slug": "interpret-content-disposition-separately-from-media-type-and-filename-safety",
        "url": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
        "alternate_urls": {
            "markdown": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety.md",
            "json": "https://update.dsesecurity.com/api/v1/posts/interpret-content-disposition-separately-from-media-type-and-filename-safety/"
        },
        "title": "Interpret Content-Disposition separately from media type and filename safety",
        "summary": "Use RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to review this narrow operational decision without extending the source beyond its stated scope.",
        "format": {
            "slug": "playbook",
            "name": "Playbook"
        },
        "priority": {
            "slug": "advisory",
            "name": "Advisory"
        },
        "featured": false,
        "image": {
            "theme": "network-infrastructure",
            "label": "Networks & infrastructure",
            "alt": "Resilient network core with engineered blue and gold data paths.",
            "card_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-card.webp?v=1.8.20",
            "hero_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-hero.webp?v=1.8.20",
            "social_url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
            "width": 2400,
            "height": 1350
        },
        "topics": [
            {
                "slug": "cybersecurity",
                "name": "Cybersecurity",
                "url": "https://update.dsesecurity.com/topic/cybersecurity/"
            },
            {
                "slug": "networks-infrastructure",
                "name": "Networks & Infrastructure",
                "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
            }
        ],
        "author": {
            "name": "DSE Security Editorial Team",
            "url": "https://update.dsesecurity.com/#editorial-team",
            "type": "Organization"
        },
        "publisher": {
            "name": "Detection Systems & Engineering",
            "url": "https://dsesecurity.com/"
        },
        "published_at": "2026-08-27T12:17:01+00:00",
        "modified_at": "2026-08-27T12:36:15+00:00",
        "reviewed_on": "2026-08-26",
        "reading_minutes": 3,
        "word_count": 602,
        "potentially_affected": "Teams, systems, services, or facilities within the stated scope of RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field",
        "dse_recommendation": "Compare the observed state with the cited official source, document applicability and exceptions, and test any approved change with rollback safeguards.",
        "primary_source": {
            "name": "RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field",
            "url": "https://www.rfc-editor.org/rfc/rfc2183.html",
            "published_on": null,
            "authority": "www.rfc-editor.org"
        },
        "publishing_principles": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
        "usage_info": "https://update.dsesecurity.com/usage/",
        "copyright_notice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
        "content_html": "<p>Keep this document to one review outcome: Interpret Content-Disposition separately from media type and filename safety. Only the official source and traced locations below supply facts. Confirm applicability before acting.</p>\n<h2>Source fact:</h2>\n<p>The official <a href=\"https://www.rfc-editor.org/rfc/rfc2183.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a> from RFC Editor supports the following bounded statements:</p>\n<ul>\n<li>Content-Disposition says whether a MIME body part is intended for automatic inline presentation or for user-initiated attachment handling; it does not define the media format. The research record locates this support at <strong>Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type)</strong>.</li>\n<li>A filename parameter is only a suggestion: the receiver checks local syntax and safety, avoids overwrites, and ignores any directory path in the supplied value. The research record locates this support at <strong>Section 2.3 (The Filename Parameter)</strong>.</li>\n<li>A receiver ignores unknown disposition parameters and treats an unknown disposition type as attachment rather than displaying it inline. The research record locates this support at <strong>Section 2.8 (Future Extensions and Unrecognized Disposition Types)</strong>.</li>\n</ul>\n<p>Keep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source&#8217;s stated conditions.</p>\n<h2>What the source does not establish</h2>\n<p>This RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.</p>\n<h2>Applicability questions</h2>\n<ul>\n<li>For source statement 1 at <strong>Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 2 at <strong>Section 2.3 (The Filename Parameter)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>For source statement 3 at <strong>Section 2.8 (Future Extensions and Unrecognized Disposition Types)</strong>, which observable configuration, record, or test can confirm applicability here?</li>\n<li>Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?</li>\n<li>Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?</li>\n<li>Who owns the decision, and which observation requires stopping, escalation, or rollback?</li>\n</ul>\n<h2>DSE recommendation:</h2>\n<p>DSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.</p>\n<p>If the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention.</p>\n<h2>Verification and evidence</h2>\n<p>Keep the source locations <strong>Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type)</strong>; <strong>Section 2.3 (The Filename Parameter)</strong>; <strong>Section 2.8 (Future Extensions and Unrecognized Disposition Types)</strong> adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.</p>\n<p>Close the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today&#8217;s observation is not a continuing guarantee.</p>\n<h2>Official references</h2>\n<ul>\n<li><a href=\"https://www.rfc-editor.org/rfc/rfc2183.html\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field</a> — RFC Editor</li>\n</ul>",
        "content_text": "Keep this document to one review outcome: Interpret Content-Disposition separately from media type and filename safety. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field from RFC Editor supports the following bounded statements:\n\nContent-Disposition says whether a MIME body part is intended for automatic inline presentation or for user-initiated attachment handling; it does not define the media format. The research record locates this support at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type).\nA filename parameter is only a suggestion: the receiver checks local syntax and safety, avoids overwrites, and ignores any directory path in the supplied value. The research record locates this support at Section 2.3 (The Filename Parameter).\nA receiver ignores unknown disposition parameters and treats an unknown disposition type as attachment rather than displaying it inline. The research record locates this support at Section 2.8 (Future Extensions and Unrecognized Disposition Types).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 2.3 (The Filename Parameter), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 2.8 (Future Extensions and Unrecognized Disposition Types), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nIf the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention.\nVerification and evidence\nKeep the source locations Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type); Section 2.3 (The Filename Parameter); Section 2.8 (Future Extensions and Unrecognized Disposition Types) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field — RFC Editor",
        "content_markdown": "Keep this document to one review outcome: Interpret Content-Disposition separately from media type and filename safety. Only the official source and traced locations below supply facts. Confirm applicability before acting.\n\n## Source fact:\n\nThe official [RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field](https://www.rfc-editor.org/rfc/rfc2183.html) from RFC Editor supports the following bounded statements:\n\n- Content-Disposition says whether a MIME body part is intended for automatic inline presentation or for user-initiated attachment handling; it does not define the media format. The research record locates this support at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type).\n\n- A filename parameter is only a suggestion: the receiver checks local syntax and safety, avoids overwrites, and ignores any directory path in the supplied value. The research record locates this support at Section 2.3 (The Filename Parameter).\n\n- A receiver ignores unknown disposition parameters and treats an unknown disposition type as attachment rather than displaying it inline. The research record locates this support at Section 2.8 (Future Extensions and Unrecognized Disposition Types).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\n\n## What the source does not establish\n\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\n\n## Applicability questions\n\n- For source statement 1 at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 2 at Section 2.3 (The Filename Parameter), which observable configuration, record, or test can confirm applicability here?\n\n- For source statement 3 at Section 2.8 (Future Extensions and Unrecognized Disposition Types), which observable configuration, record, or test can confirm applicability here?\n\n- Within sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\n\n- Could authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\n\n- Who owns the decision, and which observation requires stopping, escalation, or rollback?\n\n## DSE recommendation:\n\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\n\nIf the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention.\n\n## Verification and evidence\n\nKeep the source locations Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type); Section 2.3 (The Filename Parameter); Section 2.8 (Future Extensions and Unrecognized Disposition Types) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\n\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\n\n## Official references\n\n- [RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field](https://www.rfc-editor.org/rfc/rfc2183.html) — RFC Editor"
    },
    "json_ld": {
        "@context": "https://schema.org",
        "@graph": [
            {
                "@type": "Organization",
                "@id": "https://dsesecurity.com/#organization",
                "name": "Detection Systems & Engineering",
                "alternateName": "DSE Security",
                "url": "https://dsesecurity.com/",
                "logo": {
                    "@type": "ImageObject",
                    "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20"
                }
            },
            {
                "@type": "Organization",
                "@id": "https://update.dsesecurity.com/#editorial-team",
                "name": "DSE Security Editorial Team",
                "url": "https://update.dsesecurity.com/",
                "parentOrganization": {
                    "@id": "https://dsesecurity.com/#organization"
                }
            },
            {
                "@type": "WebSite",
                "@id": "https://update.dsesecurity.com/#website",
                "name": "DSE Updates",
                "alternateName": "DSE Security Knowledge Hub",
                "url": "https://update.dsesecurity.com/",
                "inLanguage": "en-US",
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "potentialAction": {
                    "@type": "SearchAction",
                    "target": {
                        "@type": "EntryPoint",
                        "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}"
                    },
                    "query-input": "required name=search_term_string"
                }
            },
            {
                "@type": "WebPage",
                "@id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
                "url": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
                "isPartOf": {
                    "@id": "https://update.dsesecurity.com/#website"
                },
                "lastReviewed": "2026-08-26"
            },
            {
                "@type": "BreadcrumbList",
                "@id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/#breadcrumbs",
                "itemListElement": [
                    {
                        "@type": "ListItem",
                        "position": 1,
                        "name": "DSE Updates",
                        "item": "https://update.dsesecurity.com/"
                    },
                    {
                        "@type": "ListItem",
                        "position": 2,
                        "name": "Interpret Content-Disposition separately from media type and filename safety",
                        "item": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/"
                    }
                ]
            },
            {
                "@type": [
                    "Article",
                    "TechArticle"
                ],
                "@id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/#article",
                "identifier": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
                "url": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/",
                "headline": "Interpret Content-Disposition separately from media type and filename safety",
                "description": "Use RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to review this narrow operational…",
                "abstract": "Use RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field to review this narrow operational decision without extending the source beyond its stated scope.",
                "articleBody": "Keep this document to one review outcome: Interpret Content-Disposition separately from media type and filename safety. Only the official source and traced locations below supply facts. Confirm applicability before acting.\nSource fact:\nThe official RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field from RFC Editor supports the following bounded statements:\n\nContent-Disposition says whether a MIME body part is intended for automatic inline presentation or for user-initiated attachment handling; it does not define the media format. The research record locates this support at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type).\nA filename parameter is only a suggestion: the receiver checks local syntax and safety, avoids overwrites, and ignores any directory path in the supplied value. The research record locates this support at Section 2.3 (The Filename Parameter).\nA receiver ignores unknown disposition parameters and treats an unknown disposition type as attachment rather than displaying it inline. The research record locates this support at Section 2.8 (Future Extensions and Unrecognized Disposition Types).\n\nKeep the evidence boundary at these traced claims. They support a review of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling; they do not support conclusions outside the source’s stated conditions.\nWhat the source does not establish\nThis RFC evidence supports only the named mail-protocol decision; it does not prove provider support, deliverability, or compliance for a particular flow. The citation is not a substitute for observed state, authorization, compliance evidence, or dependency health. Examine authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers before translating the source into an operational decision.\nApplicability questions\n\nFor source statement 1 at Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type), which observable configuration, record, or test can confirm applicability here?\nFor source statement 2 at Section 2.3 (The Filename Parameter), which observable configuration, record, or test can confirm applicability here?\nFor source statement 3 at Section 2.8 (Future Extensions and Unrecognized Disposition Types), which observable configuration, record, or test can confirm applicability here?\nWithin sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, which versions, roles, and configuration states define the review population?\nCould authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers invalidate the test, hide a failure, or change applicability?\nWho owns the decision, and which observation requires stopping, escalation, or rollback?\n\nDSE recommendation:\nDSE recommends using the cited source as the evidence anchor for this decision. Anchor the review in the cited section and keep observation separate from interpretation. Record the source location, examined part of sending domains, receiving domains, message agents, headers, authentication results, policy records, and failure handling, observed and expected states, owner, and reason for deviation.\nIf the review warrants change, use a bounded implementation with prerequisites, test population, monitoring, abort criteria, and a rehearsed reversal. Sequence checks for authoritative DNS, certificates, time, gateways, identity stores, reputation services, and third-party mail providers and sanitize protected material before retention.\nVerification and evidence\nKeep the source locations Sections 2.1 (The Inline Disposition Type) and 2.2 (The Attachment Disposition Type); Section 2.3 (The Filename Parameter); Section 2.8 (Future Extensions and Unrecognized Disposition Types) adjacent to the sanitized artifacts used for comparison. Prefer sanitized messages, DNS records, SMTP transcripts, authentication results, policy evaluation, and delivery or rejection logs, with enough identity and timing data for an independent recheck.\nClose the review only when the evidence, exception handling, resulting action, and after-state are linked. Schedule a new review after material technical, organizational, incident, or source changes; today’s observation is not a continuing guarantee.\nOfficial references\n\nRFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field — RFC Editor",
                "datePublished": "2026-08-27T12:17:01+00:00",
                "dateModified": "2026-08-27T12:36:15+00:00",
                "mainEntityOfPage": {
                    "@id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/"
                },
                "inLanguage": "en-US",
                "isAccessibleForFree": true,
                "author": {
                    "@type": "Organization",
                    "name": "DSE Security Editorial Team",
                    "url": "https://update.dsesecurity.com/#editorial-team"
                },
                "publisher": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "image": {
                    "@type": "ImageObject",
                    "@id": "https://update.dsesecurity.com/updates/interpret-content-disposition-separately-from-media-type-and-filename-safety/#primaryimage",
                    "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20",
                    "width": 1200,
                    "height": 630,
                    "caption": "Interpret Content-Disposition separately from media type and filename safety"
                },
                "articleSection": [
                    "Cybersecurity",
                    "Networks & Infrastructure"
                ],
                "keywords": [
                    "Cybersecurity",
                    "Networks & Infrastructure",
                    "Playbook",
                    "Advisory priority"
                ],
                "genre": "Playbook",
                "about": [
                    {
                        "@type": "Thing",
                        "name": "Cybersecurity",
                        "url": "https://update.dsesecurity.com/topic/cybersecurity/"
                    },
                    {
                        "@type": "Thing",
                        "name": "Networks & Infrastructure",
                        "url": "https://update.dsesecurity.com/topic/networks-infrastructure/"
                    }
                ],
                "wordCount": 602,
                "timeRequired": "PT3M",
                "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/",
                "usageInfo": "https://update.dsesecurity.com/usage/",
                "copyrightHolder": {
                    "@id": "https://dsesecurity.com/#organization"
                },
                "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.",
                "citation": {
                    "@type": "CreativeWork",
                    "name": "RFC 2183 — Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field",
                    "url": "https://www.rfc-editor.org/rfc/rfc2183.html"
                }
            }
        ]
    }
}