karlvr/openapi-generator-plus

Response headers aren't supported

Opened this issue · 5 comments

We need to create a wrapper model object in order to represent this type of response, which will require special handling in server implementations.

Is this why OpenAPI YAML source:

      responses:
        '200':
          description: User access grant
          headers:
            Access-Control-Allow-Headers:
              schema:
                type: string
              example: Content-Type, Authorization, Accept, X-Requested-With
            Access-Control-Allow-Methods:
              schema:
                type: string
              example: GET, POST, PUT, LOGIN, DELETE
            Access-Control-Allow-Origin:
              schema:
                type: string
              example: '*'

ends up being generated (by @openapi-generator-plus/typescript-express-passport-server-generator) as:

						res.status(200)
						res.header('accessControlAllowHeaders', `${response.headers['accessControlAllowHeaders']}`)
						res.header('accessControlAllowMethods', `${response.headers['accessControlAllowMethods']}`)
						res.header('accessControlAllowOrigin', `${response.headers['accessControlAllowOrigin']}`)

and:

export interface PostUsersAccessGrant200Response {
	status: 200
	body: Api.PostUsersAccessGrant200Response
	headers: {
		'accessControlAllowHeaders': string
		'accessControlAllowMethods': string
		'accessControlAllowOrigin': string
	}
}

?

Specifically, I'm wondering where the case conversion of the headers is happening? Is it because the headers need a different template (or other handling) to take the baseName instead of the paramName like in https://github.com/OpenAPITools/openapi-generator/pull/8861/files ?

is it this?

name: state.generator.toIdentifier(name),

$ curl -i http://localhost:3000/status/services
HTTP/1.1 200 OK
X-Powered-By: Express
accessControlAllowHeaders: value1
accessControlAllowMethods: value2
accessControlAllowOrigin: value3
Content-Type: application/json; charset=utf-8
Content-Length: 70
ETag: W/"46-FbvcYiC0h2piZWMRXV/MH2R0Wdw"
Date: Sun, 12 Mar 2023 23:23:41 GMT
Connection: keep-alive
Keep-Alive: timeout=5

{"Message":"Status found","Status":200,"Result":"all up and running."}%

I thought maybe the response header identifiers/names/whatever as camelCase would get converted back to the original Kebab-Title-Case (or whatever the response headers map keys are), but the generated server is definitely mangling the response header keys into camelCase, which appears (looking over the unit tests) to be due to the state.generator.toIdentifier(name) used in the assignment of the name value, as show in the previous comment.

karlvr commented

@stevegoossens sorry I missed these. It looks like this is the issue that was resolved in karlvr/openapi-generator-plus-express-passport#8 and your PR, which is wonderful. I think the express server might be the only server that supports the response headers!

no need to apologise at all, I love what you've made and it only took a tiny change to fix the headers and then I also realised custom templates is a feature that I can use to adapt an existing generator to a use case