@kwanhur IMHO specify a port is really hacky, what if users say we need to customize the host in the Location, instead of the one passed from the client? Do we need to add another ret_host field?

Why not extend the uri field, let it also be effective in the http_to_https mode, so that we can custom the Location.

From plugin redirect docs, rule 1

Only one of http_to_https, uri or regex_uri can be specified.

1. Under uri mode, it had supported to specify redirect port or host, like test case 15-16.

   • specify redirect port just update plugin's uri like(the other field is also the same solution)

 "plugins": {
        "redirect": {
        "uri": "https://$host:9443$request_uri",
        "ret_code": 301
     }
}

2. Under http_to_https mode, extend uri field, it seems to break the rule 1 and bring a big change.

To extend the other field, what about new attribute location?

• If empty, its default value https://$host$request_uri.
• If not empty, it goes to the same with uri.

Under http_to_https mode, extend uri field, it seems to break the rule 1 and bring a big change.

It's a big change but not broken? Let's hear more voices from the community :)

I have verified that this change is backward compatible (If not, please discuss on the APISIX mailing list first)

Looks like a breaking change here, discussion in mail list first in needed.

@kwanhur Any updates?

@kwanhur Any updates?

Not yet. I'm not agree with reusing uri under http_to_https mode. It breaks the original design and had supported to specify redirect port under uri mode.

Hopefully hear other voices.

Indeed it's not a broken change, URI is an identifier for a resource, not a component of a URL (e.g., the path). Could you explain the details about the broken change?

Oh, by the way, maybe we should talk about this on the mailing list.

test case 21 shows the incompatibility

Thanks, that really change the rule, but on the other hand, even if we remove this limitation, all configurations set before can still be applied successfully in the new version. @spacewander What do you think?

We also need to take some compatibility points on admin-api dashboard ingress etc when removing the limitation.

We also need to take some compatibility points on admin-api dashboard ingress etc when removing the limitation.

All of them are on the caller's side, could you give a specific example of the incompatibility?

Thanks, that really change the rule, but on the other hand, even if we remove this limitation, all configurations set before can still be applied successfully in the new version. @spacewander What do you think?

I can't catch up with the point. The new field is optional and it is not a break change?

@kwanhur Another way is that we can check the X-Forwarded-Port in this plugin.

@kwanhur Another way is that we can check the X-Forwarded-Port in this plugin.

Ok, I'll move on at X-Forwarded-Port.

Have a glance at x-forwarded-port definition, it's default value $server_port which default is 9443, using it means that the default redirect server port will be $server_port, not now the well-known port 443.

Using it means need to update the existed test cases, please note that.

Just like the test log here, many cases failed with inconsistent port, X-Forwarded-Port from $server_port in t/APISIX.pm is 1984 but the original expected well-known 443.

How about updating these test cases' expected redirect server port? @tokers

Just like the test log here, many cases failed with inconsistent port, X-Forwarded-Port from $server_port in t/APISIX.pm is 1984 but the original expected well-known 443.

How about updating these test cases' expected redirect server port? @tokers

I think so, if the downstream really carries the X-Forwarded-Port.

Three scenarios will force x-forwarded-port value into well-known port 443:

1. non-number
2. less than and zero
3. greater than 65535

Workflow failed on t/plugin/api-breaker.t, not the plugin redirect.
The administrator, please trigger it to rerun the cases, thanks.