-
Notifications
You must be signed in to change notification settings - Fork 9.1k
Share header with multiple response objects #369
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Unfortunately, no. The headers in the responses is actually a new feature in 2.0, and we hadn't thought of the option to allow a global definition for it. |
It's still an option we might consider in future versions. |
Isn't this handled in 3.0 You define your reusable headers at |
Yeah, but this is not about reusability (which makes it easier) - it's about declaring it only once for all. |
What happens when someone declares a Content-Type header for all responses and then adds a 204 response? |
@darrelmiller did we not just talk today about disallowing Content-Type headers? :) |
@webron Fine: content-length, Transfer-encoding, Range, ... how obscure do I need to get? :-) |
Obviously the example is bad. consider the following model:
Codes like 401, 403, 404, 406, 408 will repeat through all paths. If one could add this to a generic section and selectively overwrite it, it'd be great. Having 50 paths and adding that block over and over again ist just pain. |
Is this still not available in the schemas? This will be the great feature and I was also looking for this for a long time. |
let use this discussion to underline two common issues and possible enhancements regarding response headers:
is this planned for some future OAS spec? |
Can there not just be a simple header generically at the response level not specific to each of the status codes? For our case, this kind of header is 99% the same across our codebase.
It would be a pain to copy+paste this to each and every routine that supports HTTP JSON responses.
The text was updated successfully, but these errors were encountered: