Ingress-nginx: custom-error-pages example image fails to return the correct Content-Type header in its response

Created on 25 Apr 2019 · 3Comments · Source: kubernetes/ingress-nginx

This refers to the example provided in custom-error-pages.

The code should return a default content-type header text/html, but when it fails to decode the Accept header, it simply mirrors whatever came from the request into the response. Please refer to lines 108 and 114 from the original source code.

The general behavior for most browsers is to include several mime types in the Accept header. When it's unable to decode it, this default backend simply copies the contents of Accept into the response's Content-Type. This results in browsers not being able to decode the Content-Type in the response.

Examples:

Firefox sends Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 and when it receives the same string back from the server, it fails to recognize the content as a simple text/html.

A worse scenario now appears in Google Chrome, starting with version 73. It now sends this type of header Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3, which includes a new Google Chrome feature called Signed HTTP Exchanges. Upon receiving a signed exchange response header, the browser will try to validate a signature that should be included in the response content.

Users are faced with the error message: ERR_INVALID_SIGNED_EXCHANGE.