Since the 2.2.0 update, the `HostRouteSelector::ev...

# ktor

[Jens Suhr]

Since the 2.2.0 update, the HostRouteSelector::evaluate function uses context.call.request.origin.serverPort to determine if a request matches the port routing filter. I’m not sure why it doesn’t call localPort instead, as that’s (as far as I understand) the port where the request is actually received.

We use a ktor application with CIO in k8s behind mapped ports and an ingress, so the port in the Host headers is something completely different from what we specify in our routing. Before 2.2, it worked - probably by accident - because CIO used the local information first.
Is there a way to make this work with 2.2? Doesn’t seem like an unusual use case, but I’m probably missing something simple here.

[Aleksei Tirman [JB]]

You can write your own route’s selector based on the HostRouteSelector where call.request.origin.localPort will be checked.

[Jens Suhr]

OK, that’s an option, thank you.
Does the built-in port filter just not support this use case?

[Aleksei Tirman [JB]]

It uses the serverPort property, as you said, which refers to the port from the Host header if it’s present.

[Jens Suhr]

OK, then I’ll try using a custom routing filter as you suggested. Thanks!

[Jens Suhr]

But in my opinion this is a bit confusing because inside ktor you do not have influence on how the ports are mapped on the outside. A metrics port might be used as it is defined or it might be mapped to a different port in a k8s service. There may be many ‘public’ ports like for example one for the administration view and one for the customer facing frontend which are both mapped to https 443 via an ingress (using different hosts).
So the only thing you can reliably filter for in a port(xxx) {} filter is the port that the connector is bound to, which is the localPort.
Then again, I might be missing something obvious here and just doing it wrong 😅

[Jens Suhr]

Oh, I was really missing something! There is a localPort filter that does exactly what I’m looking for