Issue 894688  has been merged into this issue.

This deserves some discussion. If we would ignore the port when matching URLs we have the risk to use the wrong browser for apps that use the same host but different ports. I think this is common enough case to keep in mind when deciding how to handle this. We could introduce a new setting to LBS that forces it to ignore ports or a new entry format e.g. host:*/path that would mean any port. In either case we need to make sure we don't break current users relying on the existing behavior.

To be clear, it is not just the port that is the issue. It is also the protocol. As detailed in 894688, Microsoft states when using Enterprise Mode schema v.2, "Make sure that you don't specify a protocol when adding your URLs."

https://docs.microsoft.com/en-us/internet-explorer/ie11-deploy-guide/enterprise-mode-schema-version-2-guidance

However, LBS does not redirect URLs that have a forward slash and no protocol specified. This causes a few issues for us:
1) When we need to define a more specific URL to be in Enterprise mode, as adding the protocol does allow LBS to redirect the URL, but the protocol breaks Enterprise Mode. The only way to get around this is to add the URL twice: once without the protocol and once with it.
2) This also prevents us from using any Microsoft tools (Enterprise Mode Site List Manager and Enterprise Mode Site List Portal) to manage the Enterprise Mode List, as they remove the protocol.

In our testing, the example in step 5 in this bug does not redirect.

Which version of LBS (the native host part from the MSI) do you have? This has been one of the recent additions to LBS to support entries that don't have the protocol. They can be specified either as "test.com/something" or "//test.com/something".

I don't remember if I use the 5.3 or 5.4 version...

I'll do some extra search on monday

Thank you. I will test on 5.4 to be sure.

Here are the results of my tests (see attached file)

I use the last version of Chrome and LBS (v70 and v5.4)
The issue occur when the target URL has a port and a forward slash AND the entry in the IE site list file doesn't have the port number

In this case, IE take into consideration the entry but not LBS.

Deleted: LBS.PNG 12.4 KB

	LBS.PNG 12.4 KB View Download

I go futher with my tests (my companie has about 2k entries in the IE site list file) and I found another issue in this case : 

I open the following URL in Chrome rmoa-stmcv1.sf.intra.mycompany.fr:444/wsostca 
And my IE site list file just have the following line : 
stmcv1.sf.intra.mycompany.fr

LBS open IE because it matches the URL (but it shouldn't because the domain are not exactly the same)

Do you want that I open another issue for this case ?

Is LBS an open source project ?
Can I help you to resolve it ?

Sorry for not replying to c#12 earlier. The issue there is indeed that the domain matcher is matching substrings as well so the rule cba.com will match dcba.com as well as d.cba.com. We did this on purpose to simplify rule creation but it seems to me we could be a bit more precise and require substrings to be strictly ending at domain name borders so that cba.com would still match d.cba.com but not dcba.com. This has not been explicitly defined so far so defining it like this sounds reasonable to me.

Nicolas wdyt?

As for the original request of port matching vs. not again since it is not defined I think it is fine to define that ports should be ignored by the matcher unless explicitly specified in the rule. E.g. abc.com would match abc.com:1234 but abc.com:80 would only allow abc.com:80 (or for that sake just abc.com but with the http protocol only.

Nicolas can you consider those two edge cases in the upcoming built in version of LBS?

Damien, as for whether you can help in the development of LBS, the answer is generally yes and you are very welcome to do so but since we are currently in the process of transitioning the logic of the extension to be an integral feature of the browser I think the right time to jump in and help will be once we are ready with this transition as at this point the overhead of potential large changes will be too much to make your onboard easier. In the mean time maybe taking a look at the articles about developing for Chromium at dev.chromium.org will be a good starting point unless you have already contributed to the project.

Sure, it seems like a good idea to let admins set a port explicitly, but ignore the port in the URL otherwise. Especially if that's what IE does with its SiteList.

This shouldn't be too hard to implement, I'll add it to my queue.