You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix(runtime): honour allowReserved on path parameters (#112)
* fix(runtime): honour allowReserved on path parameters
OAS 3.2 lists allowReserved under the path-parameter branch of the Parameter
Object (styles-for-path in schemas/oas-3.2.json), so honouring it there is
conformant rather than an extension: reserved characters go on the wire as-is.
It matters for documents whose path parameters are themselves slash-delimited
paths (OPA data documents, proxied object paths). Until now _path_parameter
ignored the flag, so every '/' became %2F and the server saw a single segment;
the planner already recorded allow_reserved on the descriptor, so no
regeneration is needed.
Version caveat: 3.0 tolerates the field on a path parameter and 3.2 blesses it,
but 3.1 scopes it to query parameters under unevaluatedProperties:false, so a
3.1 document declaring it fails to load at all, even with strict = false.
Thread allow_reserved through _path_scalar/_path_array/_path_object and the
parameter-content branch, keep percent-encoding everything else, and cover it
with unit and HTTP integration tests. Document the behaviour and the 0.2.x
escape_path_params migration path. Bump to 1.1.1.
* docs(allowReserved): document the version caveat and the server gap
The src/runtime.jl comment introduced with the path-parameter allowReserved fix
framed the behaviour as a pragmatic deviation from the spec. It is not: OAS 3.2
lists allowReserved under the path-parameter branch of the Parameter Object
(styles-for-path in schemas/oas-3.2.json). Rewrite the comment to cite the
schema file rather than assert a deviation.
The real constraint is a version caveat, verified against all three bundled
schemas by generating a client and a server from a document declaring
allowReserved on a path parameter, under the default strict = true:
3.0 -> accepted (generic Parameter property; PathParameter does not forbid it)
3.1 -> rejected; scoped to styles-for-query under unevaluatedProperties:false,
so the document fails to load at all, even with strict = false
3.2 -> accepted, explicitly
That matters most for the MIGRATION.md row, which targets people coming off
0.2.x escape_path_params = false and who are likely to hold a 3.1 spec; they
would hit a load error rather than the feature. Add the caveat there and in
docs/src/clients.md.
Also record in docs/src/servers.md that generated servers cannot yet route such
a value: they register the path template as written and HTTP.Router matches
{name} against a single segment, so a request carrying an unescaped '/' 404s
before reaching the handler. Client and server generated from one document
therefore cannot talk to each other for that parameter. Tracked in #113.
Comment and docs only; no behaviour change.
|`pre_request_hook`, `get_return_type`|`request_headers` / `request_options` keywords; typed responses come from the document |
47
47
| Chunk readers (`LineChunkReader`, …) for streaming |`stream_to::Channel` keyword; framing follows the response media type, customizable with `codec!`|
48
48
|`httplib = Downloads` or `HTTP` backends | HTTP.jl only |
49
+
|`Client(url; escape_path_params = false)`| Declare `allowReserved: true` on the path parameter in the document; the generated client then leaves reserved characters such as `/` unescaped for that parameter. Requires a 3.0 or 3.2 document — 3.1 scopes `allowReserved` to query parameters and rejects it on a path parameter at load time |
49
50
| Constructor/`setproperty!` validation, `val_format` overloads | Full JSON Schema validation at encode/decode time; disable per client with `validate_requests` / `validate_responses`|
0 commit comments