Local reply modification

The HTTP connection manager supports modification of local reply which is response returned by Envoy itself.

Features:

• Local reply content modification.

• Local reply format modification.

Local reply content modification

The local response content returned by Envoy can be customized. A list of mappers can be specified. Each mapper must have a filter. It may have following rewrite rules; a status_code rule to rewrite response code, a headers_to_add rule to add/override/append response HTTP headers, a body rule to rewrite the local reply body and a body_format_override to specify the response body format. Envoy checks each mapper according to the specified order until the first one is matched. If a mapper is matched, all its rewrite rules will apply.

Example of a LocalReplyConfig

mappers:
- filter:
    status_code_filter:
      comparison:
        op: EQ
        value:
          default_value: 400
          runtime_key: key_b
  headers_to_add:
    - header:
        key: "foo"
        value: "bar"
      append: false
  status_code: 401
  body:
    inline_string: "not allowed"

In above example, if the status_code is 400, it will be rewritten to 401, the response body will be rewritten to as “not allowed”.

Local reply format modification

The response body content type can be customized. If not specified, the content type is plain/text. There are two body_format fields; one is the body_format field in the LocalReplyConfig message and the other body_format_override field in the mapper. The latter is only used when its mapper is matched. The former is used if there is no any matched mappers, or the matched mapper doesn’t have the body_format specified.

Local reply format can be specified as SubstitutionFormatString. It supports text_format and json_format.

Optionally, content-type can be modified further via content_type field. If not specified, default content-type is text/plain for text_format and application/json for json_format.

Example of a LocalReplyConfig with body_format field.

mappers:
- filter:
    status_code_filter:
      comparison:
        op: EQ
        value:
          default_value: 400
          runtime_key: key_b
  status_code: 401
  body_format_override:
    text_format: "<h1>%LOCAL_REPLY_BODY% %REQ(:path)%</h1>"
    content_type: "text/html; charset=UTF-8"
- filter:
    status_code_filter:
      comparison:
        op: EQ
        value:
          default_value: 500
          runtime_key: key_b
  status_code: 501
body_format:
  text_format: "%LOCAL_REPLY_BODY% %RESPONSE_CODE%"

In above example, there is a body_format_override inside the first mapper with a filter matching status_code == 400. It generates the response body in plain text format by concatenating %LOCAL_REPLY_BODY% with the :path request header. It is only used when the first mapper is matched. There is a body_format at the bottom of the config and at the same level as field mappers. It is used when non of the mappers is matched or the matched mapper doesn’t have its own body_format_override specified.