bug: redirect http to https but port not change

[tangzhenhuang]

Current Behavior

Recently, I upgraded apisix with the latest code, and found that there was an error in converting http to https. When redirecting, I always bring a port 80. It should be caused by this change：https://github.com/apache/apisix/pull/6686/files#r867816800

Maybe set $var_x_forwarded_port $server_port; in ngx_tpl.lua conflicts with local ret_port = tonumber(ctx.var["var_x_forwarded_port"]) in redirect.lua

Expected Behavior

port changed from 80 to 443

Error Logs

No response

Steps to Reproduce

add redirect and set http_to_https to true

Environment

• APISIX version (run apisix version): master
• Operating system (run uname -a):
• OpenResty / Nginx version (run openresty -V or nginx -V):
• etcd version, if relevant (run curl http://127.0.0.1:9090/v1/server_info):
• APISIX Dashboard version, if relevant:
• Plugin runner version, for issues related to plugin runners:
• LuaRocks version, for installation issues (run luarocks --version):

[kwanhur]

Yep, it's a big problem :-(

[tzssangglass]

as: https://github.com/apache/apisix/pull/6686/files#r868034475

Can we set a default value for this case?
If there is no X-Forwarded-Port in clinet reuqest headers, then the redirect plugin use 443 as the default https port?

[tokers]

as: https://github.com/apache/apisix/pull/6686/files#r868034475

Can we set a default value for this case? If there is no X-Forwarded-Port in clinet reuqest headers, then the redirect plugin use 443 as the default https port?

@tzssangglass What if the client doesn't carry X-Forwarded-For header and APISIX listening on non-443 ports for HTTPS (say 9443)?

[tzssangglass]

What if the client doesn't carry X-Forwarded-For header and APISIX listening on non-443 ports for HTTPS (say 9443)?

In this case the user needs to make the request headers carry X-Forwarded-Port, which is also in line with the docs that describes:

When enabling http_to_https, the port in the redirect URL will be the value of header X-Forwarded-Port or the port of the server.

Just an idea.

[tokers]

That's not so generic. APISIX should have a generic solution. Such as using the HTTPS port (we can know it from config.yaml even if XFF header missing.

[tzssangglass]

we can know it from config.yaml even if XFF header missin

I agree with this way

[kwanhur]

That's not so generic. APISIX should have a generic solution. Such as using the HTTPS port (we can know it from config.yaml even if XFF header missing.

It means place one initial variable in config.yaml and then fetch the custom value from XFF?

[tokers]

That's not so generic. APISIX should have a generic solution. Such as using the HTTPS port (we can know it from config.yaml even if XFF header missing.

It means place one initial variable in config.yaml and then fetch the custom value from XFF?

Yes. But we can have a custom logic that just get the HTTPS port from the config.yaml.

if X-Forwarded-Port exists then
    using X-Forwarded-Port
else
    using HTTPS port from config.yaml
end

[kwanhur]

If the https redirect port from config.yaml, seems update it has to restart apisix manually? like changing 443 to 8443.

Why not from plugin's attribute? It can be updated automatically.

[jwrookie]

After discussion, we adopted the following solution

When enabling http_to_https, the ports in the redirect URL will pick a value in the following order (in descending order of priority)

• Read plugin_attr.redirect.https_port from the configuration file (conf/config.yaml).
• If apisix.ssl is enabled, read apisix.ssl.listen_port first, and if it does not exist, read apisix.ssl.listen and select a port randomly from it.
• Use 443 as the default https port.