Some custom response return codes in AuthPolicy do not work

[averevki]

When I set custom response return codes in AuthPolicy, I'm not sure why, but it can't send the response back now. Curl shows Unsupported HTTP/1 subversion in response as there is a wrong HTTP protocol version used. httpcore.RemoteProtocolError: illegal status line: bytearray(b'HTTP/1.1 0 Unknown') this is from the python library.

Seems like the issue remains only when specifying code that doesn't have any purpose by the standard (e.g. code 431 works, but 430 does not)

AuthPolicy:

spec:
  rules:
    authentication:
      default:
        credentials:
          authorizationHeader:
            prefix: Bearer
        jwt:
          issuerUrl: 'http://1.2.3.4:8080/realms/realm-averevki--hbxe'
          ttl: 0
        metrics: false
        priority: 0
    authorization:
      Whitelist:
        metrics: false
        patternMatching:
          patterns:
            - operator: eq
              selector: context.request.http.path
              value: /allow
        priority: 0
    response:
      unauthenticated:
        code: 333
      unauthorized:
        code: 444
  targetRef:
    group: gateway.networking.k8s.io
    kind: HTTPRoute
    name: route-averevki--lhhk

Gateway

spec:
  gatewayClassName: istio
  listeners:
    - allowedRoutes:
        namespaces:
          from: Same
      hostname: '*.apps.kua.redhat.com'
      name: api
      port: 80
      protocol: HTTP

HTTPRoute

spec:
  hostnames:
    - hostname-averevki--zwt-kuadrant.apps.kua.redhat.com
  parentRefs:
    - group: gateway.networking.k8s.io
      kind: Gateway
      name: gw-averevki--st7
  rules:
    - backendRefs:
        - group: ''
          kind: Service
          name: httpbin-averevki--v8n
          namespace: kuadrant
          port: 8080
          weight: 1
      matches:
        - path:
            type: PathPrefix
            value: /

[Boomatang]

What is your expected behavior? Should the user be allowed to send custom status codes that out of spec as a response? Or is the issue we allow a user to define status codes that are out of spec?

[averevki]

What is your expected behavior? Should the user be allowed to send custom status codes that out of spec as a response? Or is the issue we allow a user to define status codes that are out of spec?

I expect it to return 333 and 444 instead of the error. I'm not sure what range should be there. I'd limit the values you can put there so it won't provoke unexpected behavior if you leave it as it is implemented now. But I like the option to define any code for the response better (from 100 to 600)

I know it worked before, and now it is an unexpected change. So I guess it became a bug

[guicassolato]

I was re-reading the spec and 2 things come to mind:

1. Envoy specify a closed set of supported HTTP codes and behaviour is not clear for codes described as "Unasigned". Authorino narrows the list even further by accepting only code within the 300-599 range.
2. There's now another layer in between Authorino and the setting of the response code, the wasm-shim. Somebody should look at that end too.