ProtocolType may not work as expected because of the case

[spacewander]

What happened:

Provide a configuration like:

apiVersion: gateway.networking.k8s.io/v1
kind: Gateway
metadata:
  name: default
spec:
  gatewayClassName: istio
  listeners:
  - name: tcp
    port: 10001
    protocol: tcp
    allowedRoutes:
      kinds:
      - kind: TCPRoute

The result is that this resource is accepted (because "tcp" is valid protocol name), but doesn't treat it as TCP protocol (because it is not equal to TCPProtocolType constant).

What you expected to happen:

Either this resource is rejected (because the TCP protocol name is "TCP", no "tcp"), or handle it as TCP protocol.

How to reproduce it (as minimally and precisely as possible):

Anything else we need to know?:

IMHO, we can either require the ProtocolType to be treated as case-insensitive, or require all Core protocols to be uppercase.

[gauravkghildiyal]

we can either require the ProtocolType to be treated as case-insensitive,

Sounds reasonable. This could be documented, though would eventually be implementation dependent

or require all Core protocols to be uppercase.

At this point, given Gateway resource is v1, a validation enforcing such a change would be treated as a breaking change and hence would not be feasible.

[spacewander]

we can either require the ProtocolType to be treated as case-insensitive

I would vote for this too.

I have just checked Kong Ingress controller, istio and our company's internal implementation, only a few places need to be adjusted (some ==, != and switch with the ProtocolType constant).

@shaneutt @robscott
I am pleased to invite you to share your expert opinion on this issue.

[youngnick]

@gauravkghildiyal raises a good point here, we should have made this case-specific at the beginning, but now the only way to fix this is to mandate that the values must be treated case-insensitively.

Thanks for raising this @spacewander.

[shaneutt]

/triage needs-information