-
Notifications
You must be signed in to change notification settings - Fork 344
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
CLI Option to Remove the 'sl-violations' Header in Responses #2315
Comments
We'd like some clarification on a couple things:
|
Thanks for the quick response @chohmann . I'll try and provide some context and answers to your questions.
Good question! We consume the violations based on log output that we can aggregate across our organization and monitor for compliance. This same log output is used to produce alerts on differences. We do not consume
We would like to hide this header from our external contract to customers so we can use our internal logs and alerts to improve consistency without exposing the header. In some cases as well, we are putting the proxy in place knowing there is a WIDE separation of compliance, and expect a lot of differences while our teams work towards compliance.
OK great this good to know there is maximum truncation already placed on it. This is sitting behind a custom API Gateway that we have for our internal developer platform. It must have a lower limit. I also see that there is a reference to the same request a year ago, with the ability to remove the header for similar reasons. In our case for both size issues of an upstream gateway but also for keeping the contract smaller/hidden would be ideal.
Sorry, this is my poor wording. What I mean by "not in error mode" is that when Hope that helps - looking forward to hearing your thoughts! |
@travisgosselin thank you for clarifying your use case! We never anticipated or planned for Prism to be used in a production environment, but can see some value in how you're using it in your production system.
This is a key insight into a need for Prism to have the ability to be completely transparent from the client perspective. In this mode Prism will still evaluate and log differences in contract, but the outgoing response remains unchanged from the upstream server. We prefer this approach over removing the sl-violations header, and gladly welcome PRs to introduce this. Here's some details on the approach we prefer:
We'd love to see a new structured log format as that would benefit all of Prism's modes, current and this proposed one. While we think this is a very interesting use case, we will likely not have capacity to introduce this ourselves in near future. We welcome PRs from you or other community members to introduce this proposed functionality. |
Thanks @chohmann your last response is helpful to understand the positioning of PRISM and your future roadmap plans. Some general thoughts inline below:
This is very good to know. In your documentation, you have a section for the
Excellent! I'm disappointed to hear it is not on your roadmap, but glad you are interested in accepting some PRs. As we introduce this into our production environment, will consider and prioritize accordingly if we can contribute this functionality to enable our production environment with this!
Great - glad that there is interest in a more machine-friendly output. We will advise in the future if we are able to contribute some effort here. Thanks again for considering and reviewing this :) |
User Story Description
As an API Producer creating an API and using the Prism Validation Proxy to log all traffic that doesn't correspond with my Open API specification, I want to be able to disable the "sl-violations" headers in the response so I do not have to communicate all the violations to the consumer.
Additionally on endpoints with many violations having a structured json object in the header does eventually overflow. This can cause runtime issues where some requests work and others fail on platforms that overflow the header length. This is especially true in a collection or search style endpoint where I may get a violation for EVERY object in the collection returned making a massive HEADER that is unsupported in some platforms by default. While not in error mode, the proxy should NEVER fail as a result of differences.
Acceptance Criteria
Sprint Ready Checklist
The text was updated successfully, but these errors were encountered: