Don't allow explode: true for cookie parameters

[ahx]

This changes the 3.1 schema to not allow explode: true for cookie parameters. Supporting explode: true for cookie parameters with array values would end up in a header like Cookie: ids=1; ids=2 [UPDATE: I don't know], right? I was asking myself if that would be allowed and could not find an explicit "yes" in the spec. I assume it should not be supported.

The description of the 3.0 version on the Swagger site implies that explode: true is not supported for cookie parameters: https://swagger.io/docs/specification/serialization/#cookie

[jdesrosiers]

This doesn't look right to me. The official documentation says this about the explode field.

When style is form, the default value is true.

... and this about the style field.

Default values (based on value of in): [...] for cookie - form.

So, if in is "cookie", then style is "form". If style is form then the default value for explode is true. Not only does this seem to be allowed, it appears to be the default behavior. It's been awhile since I've worked with cookies, but as I recall this is the normal syntax for cookies so I don't see why it wouldn't be allowed.

[ahx]

@jdesrosiers Thanks for pointing out the default behaviour (style: form, explode: true). This does not fit with this change request. But how do we encode arrays in Cookies? The example says color=blue&color=black&color=brown, but that is only applicable to query parameters, right?

[hkosova]

@ahx

But how do we encode arrays in Cookies?

The exploded form of param = [3, 4, 5] as a cookie would be:

Cookie: param=3&param=4&param=5

which is not the normal syntax for cookies.

The current OpenAPI cookie serialization options don't make much sense, and this is discussed here:

• [oas3] Default 'explode' for cookie parameters?
• rfc6570 template clarification requested for the parameter styles, cookie use case unclear

It's not enough to just drop the explode option for cookies. We need to come up with proper cookie serialization behavior that makes sense and results in valid cookie syntax.

[ahx]

Closing this, because what I got from reading through the discussion is that nobody can make sense of the current spec, even if explode: true would not be allowed.

With the current spec there is no way to implement a cookie parser which is compliant.