[oas3] Default 'explode' for cookie parameters?
See original GitHub issueAccording to the spec, “When style
is form
, the default value [for explode] is true. For all other styles, the default value is false.” However, according to this documentation, in the “Cookie Parameters” section, there are "*"s indicating the default serialization, and it is style: form, explode: false.
So which is it? Do cookies use explode by default or not?
Issue Analytics
- State:
- Created 5 years ago
- Comments:16 (14 by maintainers)
Top Results From Across the Web
Parameter Serialization - Swagger
Cookie parameters always use the form style. An optional explode keyword controls the array and object serialization. Given the cookie named id ,...
Read more >OpenAPI Specification v3.0.3 | Introduction, Definitions, & More
Default values (based on value of in ): for query - form ; for path - simple ; for header - simple ;...
Read more >OpenAPI - how to describe query parameters? - Stack Overflow
The below approach should help parameters: - in: query name: fields style: deepObject allowReserved: true schema: type: object properties: ...
Read more >OpenAPI Specification
Default values (based on value of in ): for query - form ; for path - simple ; for header - simple ;...
Read more >OpenAPI Compatibility Chart - ReadMe Documentation
We support the explode parameter for multipart/form-data media types. See the style support list for more details. allowReserved ⛔. Responses Object.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
Yeah, by “a form encoded string”, I really meant “a RFC 6570 form-style query expansion”. 😃
Although, now that I go back an read RFC 6570, in order to be complaint the correct example would actually be:
Because the cookie-value needs to start with a “?” to meet RFC 6570.
If we’re using the encoding as described on swagger.io, then yes, and explode is true, the parameter name disappears and it becomes:
I mean, first when I run this through a cookie parser I get
{x: '7&y=hello'}
, and there’s no parser in the world that’s going to make sense of that. 😛But I think, by the letter of the spec, this is wrong. The spec doesn’t say the cookie header is encoded as form data. The spec says if the parameter location is “cookie”, this is “used to pass a specific cookie value to the API”. So if I have:
So to encode this, I take my object
{x:7, y: 'hello'}
, I form encode it to getx=7&y=hello
, then I put this in the value of cookie named “myParam”, and I get a cookie header:Similarly, for:
I encode my parameter using form to get “myParam=7”, then I put this in a cookie named “myParam”, and I get:
So maybe the best thing to do here is to release an OAS 3.1.0 which adds “simple” to the list of allowed cookie styles, update the docs on swagger.io to show the above as the “form” encoding for cookies (because that’s literally what the spec says) and then add some “simple” examples, too.
This leaves the default for cookies as
{style: 'form', explode: 'true'}
, which is a bit weird because probably no one wants that, but it works.