Skip to content

Python: [Feature]: Single shared data-URI parser and media-type sniffer used by all packages #8913

Description

Description

Problem

Data-URI parsing and media-type detection are implemented several times, and each copy has been fixed separately:

Proposal

  1. Add one internal helper in core, e.g. parse_data_uri(uri) -> DataUri(media_type, params, is_base64, data). It follows RFC 2397: default media type text/plain;charset=US-ASCII, arbitrary key=value params, base64 only when the last param is base64, percent-decoding for non-base64, and a clear ValueError / ContentError on malformed input.
  2. Add one sniffer with strict signatures: BMP DIB-header check, SVG requiring an <svg root, the MPEG frame-sync mask, WebP/WAV RIFF subtype, and b64decode(validate=True).
  3. Replace the ad-hoc data: handling found in about 15 modules (A2A, hosting-A2A, AG-UI, Gemini, OpenAI Responses/Chat Completions, core MCP, hosting-MCP, DevUI, Foundry hosting, Content Understanding, skills) with the shared helper.
  4. Add a shared table-driven test corpus (valid and invalid URIs, magic-byte samples) run once in core.

Expected behavior

Every package accepts and rejects exactly the same data URIs and reports the same media type.

Code Sample

from agent_framework._types import parse_data_uri

u = parse_data_uri("data:text/plain;charset=utf-8,hello%20world")
u.media_type   # "text/plain"
u.params       # {"charset": "utf-8"}
u.data         # b"hello world"

Language/SDK

Python

Activity

  1. added
    pythonUsage: [Issues, PRs], Target: Python
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Sep 30, 2026
  2. added
    agentsUsage: [Issues, PRs], Target: Single agent
    mcpUsage: [Issues, PRs], Target: MCP
    skillsUsage: [Issues, PRs], Target: skills related features
    on Sep 30, 2026
  3. removed
    triageUsage: [Issues], Target: All issues that still need to be triaged
    on Sep 30, 2026
  4. eavanvalkenburg commented on Oct 27, 2026

    @eavanvalkenburg
    Member

    Thanks for laying out the repeated parsing problems. We will consider shared internal data-URI parsing infrastructure in core MAF, reusing the existing parser and media-type detector rather than adding parallel helpers. That does not commit us to identical input acceptance across providers: each integration still needs to enforce its own supported formats and transport contract. The immediate core fixes from #8918 are already on main; the broader consolidation should be planned alongside the scoped percent-encoding work in #9653 / #9664. This is consideration of the direction, not a commitment to implementation or timing.

  5. eavanvalkenburg commented on Oct 27, 2026

    @eavanvalkenburg
    Member

    /plan Scope this to the smallest safe consolidation of existing internal data-URI parsing primitives, not a second media sniffer or a promise that every provider accepts identical input. Inventory current core _parse_data_uri / Content accessors / detect_media_type_from_base64 and the actual duplicate parsing consumers; separate common RFC 2397 syntax, parameters/default media type, percent encoding, base64 validation and byte extraction from integration-specific format/transport restrictions. Identify which reported parsing/sniffing defects #8918 and subsequent merged fixes already address. Coordinate with the current #9653 planning and #9664 implementation/review so percent-encoded base64, lazy validation versus actual transport decoding, and provider parity are handled once rather than duplicated. Preserve raw/encoded payload behavior, media-type overrides, malformed-input errors, logging without payload disclosure, and adapter-specific JSON/object or provider constraints. Propose a bounded migration sequence with explicit dependency/API/compatibility costs; prefer reusing existing helpers without adding public API unless demonstrated necessary. Include shared valid/invalid URI corpus and focused adapter regressions, not only core tests. Existing assignment is preserved; this planning request does not mark the issue implementation-ready or authorize an all-packages refactor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Labels

agentsUsage: [Issues, PRs], Target: Single agentmcpUsage: [Issues, PRs], Target: MCPpythonUsage: [Issues, PRs], Target: PythonskillsUsage: [Issues, PRs], Target: skills related features

Projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions