Accept/Content-Type/Authorization Ignored #2777

Hi all,

I work at a company that requires Swagger/OpenAPI specs for every API, so we have about 1500+ specs right now; probably 85% are using Swagger 2. I'm going to start requiring everyone to use OpenAPI 3.x going forward, primarily because it's waaay past time we did this. I'm also trying to make it easier for specs to be downloaded and imported into Insomnia or Postman and not have duplicate params that will cause confusion.

I've got a couple of issues, however, that are holding me up.

1. We have more than a couple APIs that, for whatever reason, have required Accept or Content-Type header params. Is there a way to still have these using the OpenAPI 3.x rules/structure? Do we just flat-out tell teams not to add these header params?
2. For years we have told teams that key is a required query param (or x-api-key header), and Authorization is a required header param if auth is being used. I understand these move into the security/securityScheme sections. Has anyone run into issues with people being confused about the new location of these values? Like I said, previously these were easy to see in the param list in Swagger-UI, but going forward, they are behind the padlock icon, which is a bit different.

Sorry for the long note. I'm just hung up on #1, and worried about #2 (especially since we've made a big deal about "keys are for tracking, not security" and now they are in the security section). I'm curious if others have had to deal with this and what has worked for them.

Thanks!