feat(form): reject empty field name in add_field_strict and add_file_strict#54
Conversation
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Summary
multipartkit/form.add_field_strictandadd_file_strictpreviously accepted an empty (or whitespace-only)namesilently, producing a wire image withContent-Disposition: form-data; name="". RFC 7578 §4.2 requires thenameparameter to be the field name itself; an empty value is implementation-defined at the receiver (skip, overwrite siblings keyed on"", or reject the body). The strict variants now reject it with the newError(EmptyFieldName(value:))variant onFormError, while the non-strictadd_field/add_filekeep their existing silent-accept behaviour for backward compatibility.Changes
src/multipartkit/form.gleam: addEmptyFieldName(value:)variant toFormError;add_field_strictandadd_file_strictnowbool.guardonstring.trim(name) == ""ahead of the existing CR/LF/NUL check and returnError(EmptyFieldName(value: name)); doc-comments on all four builders updated to spell out the RFC 7578 §4.2 non-emptynamerequirement and the strict-variant escape hatch.test/regression_empty_field_name_test.gleam: new regression suite covering empty / whitespace-only / tab-onlynamerejection for both strict builders, emptyfilenamestill allowed byadd_file_strict, non-emptynamestill works, and a backward-compatibility pin that non-strictadd_field("", _)still silently accepts.CHANGELOG.md:## [Unreleased] / ### Addedentry for the new variant and the strict-builder behaviour.Design Decisions
Issue #51 listed three approaches (A: strict-Result reject, B: panic, C: docs-only). Approach A on the strict variants only — leaving non-strict behaviour intact — was chosen because the strict variants were introduced for exactly this kind of typed-error surfacing (#40, #41) and the non-strict variants have a documented silent-accept contract that callers may already rely on; a breaking change there would force every existing caller to migrate without a way to opt back into the old shape. The
string.trim(name) == ""predicate covers both the bare empty string and whitespace-only inputs in a single branch, matching the Issue's acceptance criteria (" "must also reject). The empty-name guard runs before the control-byte guard so that a caller passing""seesEmptyFieldNamerather than the (technically also true)NameContainsControlByteswith the same empty payload.filenameis intentionally left allowed-empty inadd_file_strictbecause RFC 7578 §4.2 only constrainsname.Closes #51