Cherry Studio ai-sdk-provider 修复实录Content-Type 头泄漏导致 CherryIN 图像编辑 multipart 请求失败【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio导读本文以 Cherry Studio 仓库中 .changeset/cherryin-image-edit-content-type.md 记录的一次 patch 修复为主线深入剖析一个典型的 HTTP 请求头泄漏问题CherryIN provider 的 JSON 请求头 getter 硬编码Content-Type: application/json意外泄漏到OpenAICompatibleImageModel的/images/edits图片编辑请求导致服务端将 multipart/form-data 请求体当作 JSON 解析而报错invalid character - in numeric literal。读完本文你将理解 AI SDK 中postJsonToApi与postFormDataToApi两条请求通道的 Content-Type 处理差异掌握共享 headers getter模式下的头泄漏风险并能复现、定位与修复同类问题。背景CherryIN provider 的多协议端点设计Cherry Studio 将 CherryINopen.cherryin.net封装为 AI SDK 兼容的 Provider实现在 packages/ai-sdk-provider/src/cherryin-provider.ts。该 Provider 的独特之处在于一个 Provider 同时承载多种协议端点通过endpointType配置项openai/openai-response/anthropic/gemini/image-generation/jina-rerank/embedding以及模型 ID 前缀anthropic/、google/来路由到不同协议实现分别构造AnthropicMessagesLanguageModel、GoogleGenerativeAILanguageModel、OpenAIResponsesLanguageModel、OpenAICompletionLanguageModel、OpenAIEmbeddingModel、OpenAISpeechModel、OpenAITranscriptionModel等。该 Provider 的默认基础地址见 cherryin-provider.ts配置项默认值适用协议baseURLhttps://open.cherryin.net/v1OpenAI 兼容端点anthropicBaseURLhttps://open.cherryin.net/v1Anthropic Messages 端点geminiBaseURLhttps://open.cherryin.net/v1beta/modelsGemini 端点在图像模型的路由中cherryin-provider.tscreateImageModel会依据模型 ID 做三类分发google/imagen-*、google/gemini-*-image类模型走 Google 原生图像生成包含qwen且包含image的模型 ID如 Qwen 图像模型走OpenAICompatibleImageModel来自ai-sdk/openai-compatible其余模型走 OpenAI 原生的OpenAIImageModel。本次修复针对的正是第一类OpenAICompatibleImageModel的/images/edits图片编辑请求路径。问题现象invalid character - in numeric literal该 patch 记录的缺陷表现为CherryIN 的 image-edit图片编辑请求失败服务端返回类似invalid character - in numeric literal的解析错误。这个错误信息很有辨识度——它出自 Go 语言标准库的encoding/json包。当 Go 服务端尝试把一段二进制流按 JSON 解析时会在遇到第一个无法识别的字符时抛出形如invalid character x in numeric literal的错误。而 multipart/form-data 请求体的第一行正是------WebKitFormBoundaryxxxx这样的以连续短横线-开头的 boundary 分隔行恰好命中该报错模式。因此可以推断服务端收到的请求体是标准的 multipart 内容却被当成了 JSON 进行解析。根因分析JSON headers getter 的 Content-Type 泄漏问题的根因在 changeset 中描述得非常明确The JSON headers getter hard-codedContent-Type: application/json, which leaked intoOpenAICompatibleImageModels/images/editscall.在 CherryIN provider 内部所有模型工厂共享同一个 JSON 请求头生成器。修复前的实现大致等价于const createJsonHeadersGetter (options: CherryInProviderSettings) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, Content-Type: application/json, // 修复前硬编码 ...resolveConfiguredHeaders(options.headers) }) }这个 getter 被复用到几乎所有模型工厂的headers配置中包括createOpenAIChatModel、createResponsesModel、createCompletionModel、createEmbeddingModel、createSpeechModel以及createImageModelcherryin-provider.ts。问题在于OpenAICompatibleImageModel的图片编辑能力内部使用的是表单上传通道——AI SDK 的postFormDataToApi它会构造一个 multipart/form-data 请求体包含图片文件与prompt、model等字段并依赖fetch自动生成Content-Type: multipart/form-data; boundary...。由于 headers getter 中已显式携带Content-Type: application/json这个 JSON 头被原样带进了 multipart 请求fetch便不再自动附加 boundary 头导致服务端无法识别 body 的 multipart 边界只能按 JSON 去解析以--boundary开头的请求体从而报错。这是一个典型的共享配置被错误复用的 bugJSON 请求头是为postJsonToApi通道设计的却被无差别注入到了表单通道。机制解析JSON 与 multipart 两条请求通道的 Content-Type 差异要理解修复方案需要先厘清 AI SDK 两条请求通道对 Content-Type 的处理策略通道用途示例Content-Type 处理postJsonToApichat、completion、embedding、rerank 等 JSON API若 headers 未显式声明则默认填充application/jsonpostFormDataToApi/images/edits、/audio/transcriptions、/audio/speech等表单/文件上传 API依赖fetch自动设置multipart/form-data; boundary随机值对 JSON 通道而言headers 里带Content-Type: application/json是冗余但无害的因为postJsonToApi本来就会补默认值对表单通道而言headers 里绝不能出现Content-Type一旦显式指定fetch就不会再生成 boundary整个 multipart 请求立刻失效。这正是修复思路的立足点把硬编码的Content-Type: application/json从共享 getter 中移除让各通道各归其位——postJsonToApi仍会为 JSON 端点默认填充正确的头而postFormDataToApi也能恢复依赖fetch自动生成 multipart boundary 的正常行为。修复方案与当前实现changeset 给出的修复非常简单直接Removed the explicitContent-Type—postJsonToApistill defaults it for JSON endpoints.即在 JSON headers getter 中删除显式声明的Content-Type: application/json。仓库当前代码 cherryin-provider.ts 中的createJsonHeadersGetter与createAuthHeadersGetter已不再包含任何Content-Type字段const createJsonHeadersGetter (options: CherryInProviderSettings): (() Recordstring, HeaderValue) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, ...resolveConfiguredHeaders(options.headers) }) } const createAuthHeadersGetter (options: CherryInProviderSettings): (() Recordstring, HeaderValue) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, ...resolveConfiguredHeaders(options.headers) }) }两个 getter 现在只负责两件事注入Authorization: Bearer apiKeyapiKey 来自options.apiKey或CHERRYIN_API_KEY环境变量见 cherryin-provider.ts以及合并用户在 Provider 配置中自定义的headers。Content-Type的职责被完全交还给底层请求通道。修复后的行为JSON 端点/chat/completions、/responses、/embeddings、/rerank等postJsonToApi会在 header 未声明时自动补Content-Type: application/json行为与修复前一致表单端点/images/edits等不再携带任何显式Content-Typefetch自动生成multipart/form-data; boundary...multipart 请求体可被服务端正确解析。该变更作为cherrystudio/ai-sdk-provider的 patch 级发布记录于 .changeset/cherryin-image-edit-content-type.md版本变更历史可参考 packages/ai-sdk-provider/CHANGELOG.md。一类值得警惕的模式共享 headers getter 的复用边界这个 bug 的价值不止于一次修复更揭示了一个通用设计陷阱。在 cherryin-provider.ts 中getJsonHeaders/getAuthHeaders被多个模型工厂共享createAnthropicModel额外转换出x-api-key头L265-L281createGeminiModel额外转换出x-goog-api-key头L283-L298createOpenAIChatModel、createResponsesModel、createCompletionModel、createEmbeddingModel、createSpeechModel直接复用createImageModel直接复用问题所在。当某个 getter 面向最常用场景JSON API定制了头字段却同时被喂给形态迥异的上传通道时泄漏几乎是必然的。从本次修复可以沉淀出几条可操作的工程经验共享 headers getter 只放无争议的通用头如Authorization、用户自定义头不要把Content-Type这类与具体序列化格式强绑定的头放进去让底层请求通道自行决定 Content-TypeAI SDK 的postJsonToApi与postFormDataToApi都具备合理的默认行为显式覆盖前先确认通道是否支持排查JSON 解析错误类报错时先核对请求头与请求体格式是否匹配——multipart 请求带 JSON 头、JSON 请求带 multipart 头都是此类错误的典型来源回归测试应覆盖多通道修复后应同时验证 JSON 端点头仍正确与表单端点无多余 Content-Type两边的行为避免按下葫芦浮起瓢。小结CherryIN 图片编辑请求的失败根源不在请求体构造而在于一行被共享 getter 泄漏的Content-Type: application/json。修复方式虽小却准确切中了 AI SDK 双通道postJsonToApi与postFormDataToApi对 Content-Type 的不同依赖JSON 端点有默认值兜底multipart 端点则必须把该头的决定权留给fetch。这一案例为所有基于 AI SDK 构建多协议 Provider 的开发者提供了直接的参考当你的报错里出现invalid character - in numeric literal这类奇特的解析错误时不妨先检查请求头里是否混入了不该出现的 Content-Type。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Cherry Studio ai-sdk-provider 修复实录：Content-Type 头泄漏导致 CherryIN 图像编辑 multipart 请求失败
Cherry Studio ai-sdk-provider 修复实录Content-Type 头泄漏导致 CherryIN 图像编辑 multipart 请求失败【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio导读本文以 Cherry Studio 仓库中 .changeset/cherryin-image-edit-content-type.md 记录的一次 patch 修复为主线深入剖析一个典型的 HTTP 请求头泄漏问题CherryIN provider 的 JSON 请求头 getter 硬编码Content-Type: application/json意外泄漏到OpenAICompatibleImageModel的/images/edits图片编辑请求导致服务端将 multipart/form-data 请求体当作 JSON 解析而报错invalid character - in numeric literal。读完本文你将理解 AI SDK 中postJsonToApi与postFormDataToApi两条请求通道的 Content-Type 处理差异掌握共享 headers getter模式下的头泄漏风险并能复现、定位与修复同类问题。背景CherryIN provider 的多协议端点设计Cherry Studio 将 CherryINopen.cherryin.net封装为 AI SDK 兼容的 Provider实现在 packages/ai-sdk-provider/src/cherryin-provider.ts。该 Provider 的独特之处在于一个 Provider 同时承载多种协议端点通过endpointType配置项openai/openai-response/anthropic/gemini/image-generation/jina-rerank/embedding以及模型 ID 前缀anthropic/、google/来路由到不同协议实现分别构造AnthropicMessagesLanguageModel、GoogleGenerativeAILanguageModel、OpenAIResponsesLanguageModel、OpenAICompletionLanguageModel、OpenAIEmbeddingModel、OpenAISpeechModel、OpenAITranscriptionModel等。该 Provider 的默认基础地址见 cherryin-provider.ts配置项默认值适用协议baseURLhttps://open.cherryin.net/v1OpenAI 兼容端点anthropicBaseURLhttps://open.cherryin.net/v1Anthropic Messages 端点geminiBaseURLhttps://open.cherryin.net/v1beta/modelsGemini 端点在图像模型的路由中cherryin-provider.tscreateImageModel会依据模型 ID 做三类分发google/imagen-*、google/gemini-*-image类模型走 Google 原生图像生成包含qwen且包含image的模型 ID如 Qwen 图像模型走OpenAICompatibleImageModel来自ai-sdk/openai-compatible其余模型走 OpenAI 原生的OpenAIImageModel。本次修复针对的正是第一类OpenAICompatibleImageModel的/images/edits图片编辑请求路径。问题现象invalid character - in numeric literal该 patch 记录的缺陷表现为CherryIN 的 image-edit图片编辑请求失败服务端返回类似invalid character - in numeric literal的解析错误。这个错误信息很有辨识度——它出自 Go 语言标准库的encoding/json包。当 Go 服务端尝试把一段二进制流按 JSON 解析时会在遇到第一个无法识别的字符时抛出形如invalid character x in numeric literal的错误。而 multipart/form-data 请求体的第一行正是------WebKitFormBoundaryxxxx这样的以连续短横线-开头的 boundary 分隔行恰好命中该报错模式。因此可以推断服务端收到的请求体是标准的 multipart 内容却被当成了 JSON 进行解析。根因分析JSON headers getter 的 Content-Type 泄漏问题的根因在 changeset 中描述得非常明确The JSON headers getter hard-codedContent-Type: application/json, which leaked intoOpenAICompatibleImageModels/images/editscall.在 CherryIN provider 内部所有模型工厂共享同一个 JSON 请求头生成器。修复前的实现大致等价于const createJsonHeadersGetter (options: CherryInProviderSettings) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, Content-Type: application/json, // 修复前硬编码 ...resolveConfiguredHeaders(options.headers) }) }这个 getter 被复用到几乎所有模型工厂的headers配置中包括createOpenAIChatModel、createResponsesModel、createCompletionModel、createEmbeddingModel、createSpeechModel以及createImageModelcherryin-provider.ts。问题在于OpenAICompatibleImageModel的图片编辑能力内部使用的是表单上传通道——AI SDK 的postFormDataToApi它会构造一个 multipart/form-data 请求体包含图片文件与prompt、model等字段并依赖fetch自动生成Content-Type: multipart/form-data; boundary...。由于 headers getter 中已显式携带Content-Type: application/json这个 JSON 头被原样带进了 multipart 请求fetch便不再自动附加 boundary 头导致服务端无法识别 body 的 multipart 边界只能按 JSON 去解析以--boundary开头的请求体从而报错。这是一个典型的共享配置被错误复用的 bugJSON 请求头是为postJsonToApi通道设计的却被无差别注入到了表单通道。机制解析JSON 与 multipart 两条请求通道的 Content-Type 差异要理解修复方案需要先厘清 AI SDK 两条请求通道对 Content-Type 的处理策略通道用途示例Content-Type 处理postJsonToApichat、completion、embedding、rerank 等 JSON API若 headers 未显式声明则默认填充application/jsonpostFormDataToApi/images/edits、/audio/transcriptions、/audio/speech等表单/文件上传 API依赖fetch自动设置multipart/form-data; boundary随机值对 JSON 通道而言headers 里带Content-Type: application/json是冗余但无害的因为postJsonToApi本来就会补默认值对表单通道而言headers 里绝不能出现Content-Type一旦显式指定fetch就不会再生成 boundary整个 multipart 请求立刻失效。这正是修复思路的立足点把硬编码的Content-Type: application/json从共享 getter 中移除让各通道各归其位——postJsonToApi仍会为 JSON 端点默认填充正确的头而postFormDataToApi也能恢复依赖fetch自动生成 multipart boundary 的正常行为。修复方案与当前实现changeset 给出的修复非常简单直接Removed the explicitContent-Type—postJsonToApistill defaults it for JSON endpoints.即在 JSON headers getter 中删除显式声明的Content-Type: application/json。仓库当前代码 cherryin-provider.ts 中的createJsonHeadersGetter与createAuthHeadersGetter已不再包含任何Content-Type字段const createJsonHeadersGetter (options: CherryInProviderSettings): (() Recordstring, HeaderValue) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, ...resolveConfiguredHeaders(options.headers) }) } const createAuthHeadersGetter (options: CherryInProviderSettings): (() Recordstring, HeaderValue) { return () ({ Authorization: Bearer ${resolveApiKey(options)}, ...resolveConfiguredHeaders(options.headers) }) }两个 getter 现在只负责两件事注入Authorization: Bearer apiKeyapiKey 来自options.apiKey或CHERRYIN_API_KEY环境变量见 cherryin-provider.ts以及合并用户在 Provider 配置中自定义的headers。Content-Type的职责被完全交还给底层请求通道。修复后的行为JSON 端点/chat/completions、/responses、/embeddings、/rerank等postJsonToApi会在 header 未声明时自动补Content-Type: application/json行为与修复前一致表单端点/images/edits等不再携带任何显式Content-Typefetch自动生成multipart/form-data; boundary...multipart 请求体可被服务端正确解析。该变更作为cherrystudio/ai-sdk-provider的 patch 级发布记录于 .changeset/cherryin-image-edit-content-type.md版本变更历史可参考 packages/ai-sdk-provider/CHANGELOG.md。一类值得警惕的模式共享 headers getter 的复用边界这个 bug 的价值不止于一次修复更揭示了一个通用设计陷阱。在 cherryin-provider.ts 中getJsonHeaders/getAuthHeaders被多个模型工厂共享createAnthropicModel额外转换出x-api-key头L265-L281createGeminiModel额外转换出x-goog-api-key头L283-L298createOpenAIChatModel、createResponsesModel、createCompletionModel、createEmbeddingModel、createSpeechModel直接复用createImageModel直接复用问题所在。当某个 getter 面向最常用场景JSON API定制了头字段却同时被喂给形态迥异的上传通道时泄漏几乎是必然的。从本次修复可以沉淀出几条可操作的工程经验共享 headers getter 只放无争议的通用头如Authorization、用户自定义头不要把Content-Type这类与具体序列化格式强绑定的头放进去让底层请求通道自行决定 Content-TypeAI SDK 的postJsonToApi与postFormDataToApi都具备合理的默认行为显式覆盖前先确认通道是否支持排查JSON 解析错误类报错时先核对请求头与请求体格式是否匹配——multipart 请求带 JSON 头、JSON 请求带 multipart 头都是此类错误的典型来源回归测试应覆盖多通道修复后应同时验证 JSON 端点头仍正确与表单端点无多余 Content-Type两边的行为避免按下葫芦浮起瓢。小结CherryIN 图片编辑请求的失败根源不在请求体构造而在于一行被共享 getter 泄漏的Content-Type: application/json。修复方式虽小却准确切中了 AI SDK 双通道postJsonToApi与postFormDataToApi对 Content-Type 的不同依赖JSON 端点有默认值兜底multipart 端点则必须把该头的决定权留给fetch。这一案例为所有基于 AI SDK 构建多协议 Provider 的开发者提供了直接的参考当你的报错里出现invalid character - in numeric literal这类奇特的解析错误时不妨先检查请求头里是否混入了不该出现的 Content-Type。【免费下载链接】cherry-studio Cherry Studio 是一款支持多个 LLM 提供商的桌面客户端项目地址: https://gitcode.com/CherryHQ/cherry-studio创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考