Content-Type from Auth service is overwritten in error response

[Nagarajan Selvaraj]

Content-Type from Auth service is overwritten in error response

To Reproduce
Setup AuthService

---
apiVersion: getambassador.io/v3alpha1
kind: AuthService
metadata:
  name: authentication
spec:
  ambassador_id: ["--apiVersion-v3alpha1-only--default"]
  auth_service: "mockserver.default:8080"
  path_prefix: "/ambassador"
  proto: http
  timeout_ms: 5000
  status_on_error:
    code: 500
  failure_mode_allow: false
  allowed_authorization_headers:
  - "x-test"

The mockserver is configured to authenticate the requests and for invalid requests it'll send the response body like below with 403 status code and Content-Type set as application/json

{
  "result" : "Forbidden"
}

When we call the API through emissary, it overrides the Content-Type as text/plain from application/json

HTTP/1.1 403 Forbidden
Content-Type: text/plain
... <other headers>
{"result":"Forbidden"}

Expected behavior
The auth failure response should retain original Content-Type

HTTP/1.1 403 Forbidden
Content-Type: application/json
... <other headers>
{"result":"Forbidden"}

Versions (please complete the following information):

• Ambassador: 3.9.1
• Kubernetes environment AWS EKS
• Version 1.27

[cindymullins-dw]

text/plain is the default. You can set the content_type for custom error responses on either a Module or a Mapping. I'm not sure if that spec is available on the AuthService but it might be something to try.

[Fardin Khanjani]

In order to send any header from the server behind AuthService back to the clients, the headers need to be added to allowed_authorization_headers:

 allowed_authorization_headers:
    - X-Blocked
    - Content-Type

This conflicts with the Emissary's documentation:

The entire HTTP response from the ExtAuth service--including the status code, the headers, and the body--is handed back to the client verbatim.