What happens
OpenAPI 3.2 adds a cookie serialization style, valid at in: cookie. Compiling a document that
uses it produces an error diagnostic and the parameter's declared style never reaches the IR:
openapi: 3.2.0
info: {title: CookieStyle, version: "1.0.0"}
paths:
/c:
get:
operationId: c
parameters:
- {name: sess, in: cookie, style: cookie, schema: {type: object}}
responses:
"200": {description: ok}error openapi/validation/validation-allowed-values cookie-style.yaml#8:43:
parameter.style must be one of [`form`] for in=cookie
The rejection comes from the upstream parser: openapi/parameter.go enumerates
[]string{string(SerializationStyleForm)} as the allowed cookie styles, and there is no
SerializationStyleCookie constant in the package at all.
Why it matters
3.2 §"Style Values" lists the (in, style) pairs it permits and says "Combinations not represented
in this table are not permitted". cookie/cookie is in that table, so a valid 3.2 document is
refused. It is the only legal pair the conformance corpus cannot declare, which is why
paramStyleLegalPairs() in compilers/openapi/conformance_test.go lists nine pairs and not ten.
The latent second half
resolveStyleExplode in compilers/openapi/internal/operation/params.go derives the explode
default as:
explode := style == string(soa.SerializationStyleForm)
3.2 says the default is true "When style is form or cookie". So even once the parser
accepts the style, a cookie-styled parameter that omits explode would default to false where
the specification says true. Both halves want fixing together.
Fixing it
Needs the upstream parser to learn the style first. When it lands, add the tenth pair to
paramStyleLegalPairs() and the three parameters that pair generates to
testdata/conformance/openapi/param-style-matrix.yaml — the expectation is generated from that
table, so the pair and its fixture rows are the whole change on this side.
What happens
OpenAPI 3.2 adds a
cookieserialization style, valid atin: cookie. Compiling a document thatuses it produces an error diagnostic and the parameter's declared style never reaches the IR:
The rejection comes from the upstream parser:
openapi/parameter.goenumerates[]string{string(SerializationStyleForm)}as the allowed cookie styles, and there is noSerializationStyleCookieconstant in the package at all.Why it matters
3.2 §"Style Values" lists the
(in, style)pairs it permits and says "Combinations not representedin this table are not permitted".
cookie/cookieis in that table, so a valid 3.2 document isrefused. It is the only legal pair the conformance corpus cannot declare, which is why
paramStyleLegalPairs()incompilers/openapi/conformance_test.golists nine pairs and not ten.The latent second half
resolveStyleExplodeincompilers/openapi/internal/operation/params.goderives the explodedefault as:
3.2 says the default is
true"Whenstyleisformorcookie". So even once the parseraccepts the style, a
cookie-styled parameter that omitsexplodewould default tofalsewherethe specification says
true. Both halves want fixing together.Fixing it
Needs the upstream parser to learn the style first. When it lands, add the tenth pair to
paramStyleLegalPairs()and the three parameters that pair generates totestdata/conformance/openapi/param-style-matrix.yaml— the expectation is generated from thattable, so the pair and its fixture rows are the whole change on this side.