Skip to content
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

bug: response-rewrite does not take effect in apisix-openresty #5370

Closed
arabot777 opened this issue Oct 29, 2021 · 4 comments · Fixed by #5403
Closed

bug: response-rewrite does not take effect in apisix-openresty #5370

arabot777 opened this issue Oct 29, 2021 · 4 comments · Fixed by #5403

Comments

@arabot777
Copy link
Contributor

Issue description

The response-rewrite sample was configured according to the official document, but the returned content was found not to be modified as expected when the curl xxxxx.
After many tests, the plugin took effect after changing apisix-openresty back to openresty.

Environment

  • apisix version (cmd: apisix version): 2.10.0/2.10.1

  • OS (cmd: uname -a):Linux localhost.localdomain 3.10.0-957.10.1.el7.x86_64 2019 x86_64 x86_64 x86_64 GNU/Linux

  • OpenResty / Nginx version (cmd: nginx -V or openresty -V):
    apisix-openresty:openresty/1.19.3.2
    openresty:openresty/1.19.3.1 (or 1.19.19.1)

  • etcd version, if have (cmd: run curl http://127.0.0.1:9090/v1/server_info to get the info from server-info API): 3.4.0

  • apisix-dashboard version, if have:

  • the plugin runner version, if the issue is about a plugin runner (cmd: depended on the kind of runner):

  • luarocks version, if the issue is about installation (cmd: luarocks --version):
    /bin/luarocks 2.3.0

Steps to reproduce

  1. route config yaml
uri: /*
name: cachalot-console
methods:
  - GET
  - POST
  - PUT
  - DELETE
  - PATCH
  - HEAD
  - OPTIONS
  - CONNECT
  - TRACE
host: cachalot-console-admin.stage.yunshanmeicai.com
plugins:
  client-control:
    disable: true
    max_body_size: 10485760
  response-rewrite:
    body: '{"code":"ok","message":"new json body"}'
    body_base64: false
    disable: false
    headers:
      X-Server-balancer_addr: $balancer_ip:$balancer_port
      X-Server-id: '3'
      X-Server-status: 'on'
    vars:
      - - status
        - '=='
        - '200'
upstream_id: '6'
status: 1

  1. curl cachalot-console-admin.stage.yunshanmeicai.com/health -i

Actual result

HTTP/1.1 200
Content-Type: text/plain;charset=UTF-8
Content-Length: 2
Connection: keep-alive
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Date: Fri, 29 Oct 2021 09:40:24 GMT
Server: APISIX

OK%

This result return is under apisix-openresty

Error log

no error log

Expected result

HTTP/1.1 200
Content-Type: text/plain;charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-XSS-Protection: 1; mode=block
X-Frame-Options: DENY
X-Content-Type-Options: nosniff
Date: Fri, 29 Oct 2021 09:23:01 GMT
Server: APISIX
X-Server-balancer-addr: 10.2.3.138:8089
X-Server-id: 3
X-Server-status: on

{"code":"ok","message":"new json body"}%

This result return is effective under openresty

@tzssangglass
Copy link
Member

here is my config:

{
    "plugins": {
        "response-rewrite": {
            "headers": {
                "X-Server-id": 3,
                "X-Server-status": "on",
                "X-Server-balancer_addr": "$balancer_ip:$balancer_port"
            }
        }
    },
    "upstream": {
        "nodes": {
            "httpbin.org:80": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}

I remove vars as your config, and this is my result:

curl -i 127.0.0.1:9080/get
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 300
Connection: keep-alive
Date: Fri, 29 Oct 2021 10:20:56 GMT
Access-Control-Allow-Origin: *
Access-Control-Allow-Credentials: true
Server: APISIX/2.10.1
X-Server-balancer-addr: 198.18.1.159:80
X-Server-id: 3
X-Server-status: on

{
  "args": {},
  "headers": {
    "Accept": "*/*",
    "Host": "127.0.0.1",
    "User-Agent": "curl/7.64.1",
    "X-Amzn-Trace-Id": "Root=1-617bcb08-2d3f0fd4294f31de7cd37f99",
    "X-Forwarded-Host": "127.0.0.1"
  },
  "origin": "127.0.0.1, 180.118.190.54",
  "url": "http://127.0.0.1/get"
}

you can see the response-rewrite plugin workes well. I think response-rewrite is not working because vars is incorrect.

the correct configuration should be

{
    "plugins": {
        "response-rewrite": {
            "headers": {
                "X-Server-id": 3,
                "X-Server-status": "on",
                "X-Server-balancer_addr": "$balancer_ip:$balancer_port"
            },
            "vars": [
                [
                    "status",
                    "==",
                    200
                ]
            ]
        }
    },
    "upstream": {
        "nodes": {
            "httpbin.org:80": 1
        },
        "type": "roundrobin"
    },
    "uri": "/*"
}

200 is number type, not string type.

There is an error in the example in this document: https://github.com/apache/apisix/blob/master/docs/en/latest/plugins/response-rewrite.md#how-to-enable, would you like to submit a PR to fix it?

just change [ "status","==","200" ] to [ "status","==",200 ].

@arabot777
Copy link
Contributor Author

Understood. I modify "200" to 200, response-rewrite is working!
Later , I use "200" testing in openresty not 200, it is working also. I think openresty can ignore attribute types, but apisix-openresty cannot.
You can test and verify it, and then the display will prompt people about the difference or ensure that it is consistent with openresty.

@tzssangglass
Copy link
Member

This has nothing to do with openresty, the vars matching uses the lua-resty-expr library.

@arabot777
Copy link
Contributor Author

Okay, the problem is solved by clarifying the attribute type.
I will sumbit a PR to fix the example description.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants