Reordering of ingress rules (#2409) breaks existing functionality

[jschmidt1-godaddy]

Describe the bug
A concise description of what the bug is.
PR #2409 removes the ability to use an ImplementationSpecific path type to route a longer URL with a wildcard to a different destination than a Prefix path type with a shorter URL.

Steps to reproduce

Here is an example of the relevant portion of the ingress config:

spec:
  ingressClassName: alb
  rules:
    - host: {{ .Values.ingressHostname }}
      http:
        paths:
          - path: /v1/resources/*/serviceOne
            pathType: ImplementationSpecific
            backend:
              service:
                name: serviceOne
                port: 
                  number: 8000
          - path: /v1/resources
            pathType: Prefix
            backend:
              service:
                name: serviceTwo
                port: 
                  number: 8000

After v2.4.3, all requests are routed to serviceTwo, even if the ImplementationSpecific path is longer than the Prefix path. This violates Kubernetes ingress documentation.

Expected outcome
A concise description of what you expected to happen.
Prior to v2.4.3, requests with the suffix /serviceOne were routed to serviceOne, and requests without the /serviceOne suffix were routed to serviceTwo.

In order to achieve the expected behavior for multiple matches (the aim of the original PR), it seems that the length of the path should be considered before reordering based on path type (even if the type is ImplementationSpecific).

Environment

• AWS Load Balancer controller version 2.4.3
• Kubernetes version 1.21
• Using EKS (yes/no), if so version? yes, 1.21

Additional Context:
I've tried workarounds to this problem via actions/conditions annotations, but am running into the problem that the wildcard matching done by the listener includes the /serviceOne as part of wildcard matching, so all requests are sent to serviceOne.

[kishorj]

@jschmidt1-godaddy, the ingress spec does not have any ordering requirements for the ImplementationSpecific paths. The recent controller follows the path/rule order from the spec for the ImplementationSpecific paths for backwards compatibility. In case ImplementationSpecific path is mixed with Prefix or Exact, the Prefix/Exact paths get higher precedence. Ordering the ImplementationSpecific paths by length will not be backwards compatible with existing behavior.

In your case, would you be able to make both path types ImplementationSpecific using appropriate wildcards for Prefix type?

[kishorj]

@jschmidt1-godaddy, I'm closing the issue. If you have further concerns, feel free to reopen or file a new issue.