fix(client): keep form-style CSV separators literal in query strings - #107
Merged
Conversation
The OAS form style (RFC6570 form-style expansion) serializes a non-exploded array as ?color=blue,black,brown — the separator comma stays literal while the items are percent-encoded (Style Examples table, OAS 3.0.4/3.1.1/3.2.0). The client escaped the fully joined query value instead, turning separators into %2C, which spec-compliant servers (including OpenAPI.jl 1.0 generated servers) read as a single item containing commas and reject. Build the query string by percent-encoding each comma-separated segment individually: form-style CSV separators stay literal, spaceDelimited and pipeDelimited separators become %20/%7C as the specification requires, and a comma in a scalar value stays literal, which is valid per RFC3986 and percent-decodes identically. Existing 0.2 servers are unaffected: they percent-decode before splitting, so literal separators decode the same way. Verified against the full test suite with live servers (3080 tests) and live against an OpenAPI.jl 1.0 generated server, where multi-value CSV query parameters from this client previously failed with 400.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The OAS
formstyle (RFC6570 form-style expansion) serializes a non-exploded array as?color=blue,black,brown— the separator comma stays literal while the items are percent-encoded (Style Examples table, identical in OAS 3.0.4/3.1.1/3.2.0). This client escaped the fully joined query value instead, producingstatus=pending%2Csold, which spec-compliant servers — including OpenAPI.jl 1.x generated servers, which split on literal commas so that escaped commas inside items survive — read as a single item containing commas and reject.The query string is now built by percent-encoding each comma-separated segment individually:
status=pending,sold),spaceDelimited/pipeDelimitedseparators become%20/%7C, as the specification requires for those styles,Existing 0.2 servers are unaffected: they percent-decode before splitting, so literal separators decode the same way. The fix is in the runtime, so existing generated clients pick it up without regeneration.
Note for reviewers: the fix deliberately lives at query assembly (
query_stringindo_request), not inset_param— generated code also routes header parameters throughset_paramwithout passinglocation, so escaping there would corrupt header values.Validation: full test suite with live servers passes (3080 tests); new unit testset in
test/param_deserialize.jlcovering CSV separators, per-item encoding,%20/%7Cdelimiters, scalars, and key escaping. Verified live against an OpenAPI.jl 1.x generated petstore server, where multi-value CSV query parameters from this client previously failed with 400 (GET /pet/findByStatus?status=pending,sold).Suggest tagging v0.2.9 after merge. Part of the pre-1.0 interop work tracked in #104.