fix(apiform): strip path components from upload filenames - #120
fix(apiform): strip path components from upload filenames#120sylvesterkaczmarek wants to merge 2 commits into
Conversation
Signed-off-by: Sylvester Kaczmarek <16242628+sylvesterkaczmarek@users.noreply.github.com>
ff7e2ed to
8095fae
Compare
|
@codex review |
Codex Review SummaryThis comment shows the latest Codex review activity on this pull request.
ℹ️ About Codex in GitHubYour team has set up Codex to review pull requests in this repo. Reviews are triggered when you
Codex reacts with 👀 while any review is running, comments if it has suggestions, and reacts with 👍 once all reviews finish with no findings. |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 8095fae62c
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| } | ||
|
|
||
| func multipartBaseName(name string) string { | ||
| return path.Base(strings.ReplaceAll(name, `\`, "/")) |
There was a problem hiding this comment.
When Name() comes from a real POSIX file whose basename contains a backslash, this unconditional replacement treats a legal filename character as a directory separator. For example, /tmp/invoice\2026.pdf previously produced filename="invoice\\2026.pdf" but now produces filename="2026.pdf", changing the filename observed by the API; only interpret backslashes as separators for recognizably Windows paths or according to the reader's native path semantics.
AGENTS.md reference: AGENTS.md:L38-L43
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Fixed in 47daacf. Windows-style paths are now normalized only when they are recognizably Windows paths; legal backslashes in POSIX basenames are preserved. Added the /tmp/invoice\\2026.pdf regression. Focused apiform test passes.
|
Security review completed. No security issues were found in this pull request. Reviewed commit: Only the user who started this review can view the report in Codex. ℹ️ About Codex security reviews in GitHubThis is an experimental Codex feature. Security reviews are triggered when:
Once complete, Codex will leave suggestions, or a comment if no findings are found. |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 47daacf87e
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if len(name) < 2 || name[1] != ':' { | ||
| return false |
There was a problem hiding this comment.
On Windows, a reader such as an *os.File opened with a relative path like reports\report.pdf retains that relative name, but this predicate returns false because it has neither a drive prefix nor a UNC prefix. path.Base then treats the backslash as an ordinary character, so the multipart header still sends filename="reports\\report.pdf"; single-backslash rooted paths have the same problem. Account for native Windows path semantics so these common paths are reduced to report.pdf.
AGENTS.md reference: AGENTS.md:L38-L43
Useful? React with 👍 / 👎.
2 participants
Summary
Ensure multipart uploads send only the basename of reader-provided file paths, regardless of whether the path uses POSIX or Windows separators.
Problem
internal/apiform.encodeReaderderives filenames from readers exposingName()withpath.Base, which only treats/as a separator. A Windows-style name such asC:\dir\report.pdfcan therefore remain unchanged when processed on a non-Windows host or supplied by a cross-platform/custom reader, placing directory components in the multipartfilename=parameter instead of justreport.pdf.Fix
Normalize backslash separators before taking the path basename. POSIX paths keep their existing behavior, while Windows-style paths reduce to the same basename representation.
The change is limited to the
Name()fallback. Readers that explicitly implementFilename()retain control of the filename they provide.Regression coverage
Added table-driven multipart tests covering POSIX and Windows-style paths. Both must produce
filename="report.pdf", and the serialized body must not contain directory components.Validation
The branch is based directly on current upstream
main(a7719136b8ed401b0c51a05553a5e4f720150307) and contains one DCO-signed commit touching only the multipart encoder plus focused regression coverage. Full repository test execution is left to CI.Risk
Low. Only the fallback filename derived from a reader's
Name()changes, and only by removing directory components. File contents, content type handling, explicitFilename()implementations, field names, and non-file multipart fields are unchanged.