Responses API rejects base64 `input_image` data URIs longer than ~65,520 chars with `invalid_payload` / “is not a valid absolute URI”

快速结论：调用 Responses API 并以 base64 data URI 形式传入 input_image 时，如果单个 image_url 字符串超过约 65,520 个字符，服务端会返回 invalid_payload / “is not a valid absolute URI”。优先确认单张图片的 data URI 长度；若你通过 Azure AI Projects（Foundry）的 get_openai_client() 调用，可先尝试改用官方 AsyncOpenAI 客户端直连。

适用环境：openai-python SDK、Azure AI Projects（AIProjectClient.get_openai_client()）、openai-node（评论确认同样出现）；Python 环境中使用了 azure-ai-projects、PIL、pydantic。Issue 未给出具体 Python / openai 版本号，因此不补充版本信息。

最快修复方案：如果请求是通过 project_client.get_openai_client() 发出的，替换为直接实例化 from openai import AsyncOpenAI 的客户端并重试——评论中确认此方式可绕过该问题。若不方便更换客户端，则只能压缩单张图片的 base64 编码长度，使其低于约 65,520 字符。

注意事项：该长度限制按单个 image_url 字符串计算，不按请求总大小计算；把大图拆成多次请求无法绕过。直接 AsyncOpenAI 可绕过可能是 Foundry 代理侧的临时故障，不代表服务端 URI 长度上限已取消。缩减图片分辨率或 JPEG 质量是有效的规避手段，但 Issue 中没有给出精确的“建议最大值”。

问题场景

用户使用 OpenAI Python SDK 的 client.responses.parse 接口，在 input_image 的 image_url 中传入 base64 data URI（例如 data:image/jpeg;base64,...）时触发。发送小图可以成功，但单张图片的 data URI 字符串一旦超过约 65,520 个字符，HTTP 400 报错立即出现。该问题在 Azure AI Projects 通过 get_openai_client() 获取客户端时被复现，openai-node 用户也报告了相同现象。

报错原文

Error code: 400 - {'error': {'code': 'invalid_payload', 'message': "'data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/2wBDAAgGBgcHBgUICAcHCQkICgwUDQwLC...' is not a valid absolute URI"}}

原因分析

可能原因有两个层面：

1. 服务端在验证 image_url 时使用了带有长度上限的 URI 解析器。实测拒绝边界位于 63,975 到 65,883 字符之间，恰好覆盖 System.Uri 在 .NET 中的最大长度 0xFFF0（65,520）。因此很可能是服务端将 data URI 当作普通 URI 解析，超过该长度后直接判定为“不是合法的绝对 URI”，而不是提示“过长”。

2. Issue 评论区进一步缩小了范围：通过 Azure AI Projects（Foundry）的 get_openai_client() 调用会稳定触发该错误，而直接使用 AsyncOpenAI 则正常。因此该问题也可能由 Foundry 代理层引入，而非 openai-python SDK 本身。

环境排查

确认调用客户端来源：是 project_client.get_openai_client() 还是直接 from openai import AsyncOpenAI。
确认单个 image_url 的字符长度：检查 len("data:image/jpeg;base64," + b64_string) 是否超过约 65,520。
确认图片均为 JPEG 格式、尺寸为 1024×1448（复现环境），并注意编码后大小随图像噪声/压缩率变化。
检查是否使用了 Azure AI Projects / Foundry 的 endpoint，而非 OpenAI 官方 endpoint。