fixed how array fields are sent in multipart form POSTs

[ben5516]

This is a naive approach to properly supporting array fields in multipart encoded POST requests.

The issue I was having was that this code was not correctly sending timestamp_granularities to the server (see example):

response = client.audio.transcriptions.create(
          model:                    "whisper-1",
          file:                     File.open(mp3_filepath.to_s, "rb"),
          response_format:          :verbose_json,
          timestamp_granularities:  [ :word, :segment ],
          language:                 "en"
 )

The server is expecting an array field, where the key is timestamp_granularities[]. However, the url_encode sanitization pass encodes the square brackets and the server doesn't decode it. Sanitization should be less aggressive, and only escape LF, CR, ", and \ I believe.

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 9d94e79a2b

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

[chatgpt-codex-connector]

Escape multipart field names before writing Content-Disposition

Writing key directly into the quoted name parameter allows keys containing ", \, or CR/LF to break the Content-Disposition header syntax and potentially inject extra multipart headers/content when body keys are user-controlled. This line used to percent-encode keys, so the regression is introduced by this commit; even if [] should stay literal, the value still needs header-safe escaping (or CR/LF rejection) before interpolation.

Useful? React with 👍 / 👎.

[ben5516]

Yea, this was a naive implementation. A safer fix would just be to unencode square brackets after url_encoding everything.