-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
api-breaker plugin returns default response body #6949
Conversation
apisix/plugins/api-breaker.lua
Outdated
break_response_body = { | ||
type = "string" | ||
}, | ||
break_response_content_type = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Apache APISIX has a few plugins that define the response body but without setting the content type.
I'm thinking about that, if we need to keep the behaviors consistence?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If the body is json, and the content-type is text/html, some APP clients may report error, and the terminal user would be affected.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This problem cannot be solved even if we provide this field. People have to know how to configure it.
For these kinds of returning body, I think we may need a unified way to handle the Content-Type
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This problem cannot be solved even if we provide this field. People have to know how to configure it.
For these kinds of returning body, I think we may need a unified way to handle the
Content-Type
.
A unified way is good, but it's not that easy. Modern API returns application/json, but some legacy API returns application/soap+xml like SOAP.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the API owner should be responsible to configure route on the apigageway correctly , it's part of the developing work, and only the API owner knows what the correct Content-Type should be. If there's no way to config the Content-Type correctly, when break state is open, the client APP used this API may crash because of the unexpected Content-Type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, i'll browse all the plugins which should be with a content-type field and submit an issue with a checklist.
It is not a good idea, as this check won't fix the non-open-source plugins.
One solution is to guess:
- according to the response body:
apisix/apisix/control/router.lua
Line 81 in cc88a8d
if type(body) == "table" and ngx.header["Content-Type"] == nil then - according to the Accept header or the ext part of the uri
Another solution is to configure it in the route
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for this plugin, I would suggest adding a field to add any response headers instead of just content-type.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for this plugin, I would suggest adding a field to add any response headers instead of just content-type.
Is there any other plugin with such a field? I'm not sure of which field is suitable for representing any response headers. @spacewander
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As for this plugin, I would suggest adding a field to add any response headers instead of just content-type.
Can we use the headers
field to represent any response headers? I found the echo
plugin and also the response-rewrite
plugin using this attribute. @spacewander
Name | Type | Requirement | Default | Valid | Description |
---|---|---|---|---|---|
headers | array | optional | New headers for response. Using an array so multiple response headers with the same name can be used |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. And we should use an array so multiple response headers with the same name can be used.
Hi @qihaiyan , can we add a test cases to cover |
Co-authored-by: tzssangglass <tzssangglass@gmail.com>
Sure, i'll add the test cases tomorrow. |
Can you help to check why the chaos-test failed? @tzssangglass |
The chaos test is not so stable. I have rerun it. |
|
Co-authored-by: Alex Zhang <tokers@apache.org>
Co-authored-by: Alex Zhang <tokers@apache.org>
This PR‘s status is
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, let's address #6949 (comment)
Co-authored-by: 罗泽轩 <spacewanderlzx@gmail.com>
Co-authored-by: qihaiyan <qihaiyan@hisense.com> Co-authored-by: tzssangglass <tzssangglass@gmail.com> Co-authored-by: Alex Zhang <tokers@apache.org> Co-authored-by: 罗泽轩 <spacewanderlzx@gmail.com>
Co-authored-by: qihaiyan <qihaiyan@hisense.com> Co-authored-by: tzssangglass <tzssangglass@gmail.com> Co-authored-by: Alex Zhang <tokers@apache.org> Co-authored-by: 罗泽轩 <spacewanderlzx@gmail.com>
Description
When upstream is in the unhealthy state, the api-breaker returns unhealthy.http_statuses only, without a response body.
In order to be more compatible to the client, return a default response body is useful.
Fixes #6923
Checklist