Protocol options¶

core.HttpProtocolOptions¶

{
  "idle_timeout": "{...}",
  "max_connection_duration": "{...}",
  "max_headers_count": "{...}",
  "headers_with_underscores_action": "..."
}

idle_timeout: (Duration) The idle timeout for connections. The idle timeout is defined as the period in which there are no active requests. If not set, there is no idle timeout. When the idle timeout is reached the connection will be closed. If the connection is an HTTP/2 downstream connection a drain sequence will occur prior to closing the connection, see drain_timeout. Note that request based timeouts mean that HTTP/2 PINGs will not keep the connection alive. If not specified, this defaults to 1 hour. To disable idle timeouts explicitly set this to 0.

Warning

Disabling this timeout has a highly likelihood of yielding connection leaks due to lost TCP FIN packets, etc.

max_connection_duration: (Duration) The maximum duration of a connection. The duration is defined as a period since a connection was established. If not set, there is no max duration. When max_connection_duration is reached the connection will be closed. Drain sequence will occur prior to closing the connection if if’s applicable. See drain_timeout. Note: not implemented for upstream connections.

max_headers_count: (UInt32Value) The maximum number of headers. If unconfigured, the default maximum number of request headers allowed is 100. Requests that exceed this limit will receive a 431 response for HTTP/1.x and cause a stream reset for HTTP/2.

headers_with_underscores_action: (core.HttpProtocolOptions.HeadersWithUnderscoresAction) Action to take when a client request with a header name containing underscore characters is received. If this setting is not specified, the value defaults to ALLOW. Note: upstream responses are not affected by this setting.

Enum core.HttpProtocolOptions.HeadersWithUnderscoresAction¶

[core.HttpProtocolOptions.HeadersWithUnderscoresAction proto]

Action to take when Envoy receives client request with header names containing underscore characters. Underscore character is allowed in header names by the RFC-7230 and this behavior is implemented as a security measure due to systems that treat ‘_’ and ‘-‘ as interchangeable. Envoy by default allows client request headers with underscore characters.

ALLOW: (DEFAULT) ⁣Allow headers with underscores. This is the default behavior.

REJECT_REQUEST: ⁣Reject client request. HTTP/1 requests are rejected with the 400 status. HTTP/2 requests end with the stream reset. The “httpN.requests_rejected_with_underscores_in_headers” counter is incremented for each rejected request.

DROP_HEADER: ⁣Drop the header with name containing underscores. The header is dropped before the filter chain is invoked and as such filters will not see dropped headers. The “httpN.dropped_headers_with_underscores” is incremented for each dropped header.

core.Http1ProtocolOptions¶

[core.Http1ProtocolOptions proto]

{
  "allow_absolute_url": "{...}",
  "accept_http_10": "...",
  "default_host_for_http_10": "...",
  "header_key_format": "{...}"
}

allow_absolute_url: (BoolValue) Handle HTTP requests with absolute URLs in the requests. These requests are generally sent by clients to forward/explicit proxies. This allows clients to configure envoy as their HTTP proxy. In Unix, for example, this is typically done by setting the http_proxy environment variable.

accept_http_10: (bool) Handle incoming HTTP/1.0 and HTTP 0.9 requests. This is off by default, and not fully standards compliant. There is support for pre-HTTP/1.1 style connect logic, dechunking, and handling lack of client host iff default_host_for_http_10 is configured.

default_host_for_http_10: (string) A default host for HTTP/1.0 requests. This is highly suggested if accept_http_10 is true as Envoy does not otherwise support HTTP/1.0 without a Host header. This is a no-op if accept_http_10 is not true.

header_key_format: (core.Http1ProtocolOptions.HeaderKeyFormat) Describes how the keys for response headers should be formatted. By default, all header keys are lower cased.

core.Http1ProtocolOptions.HeaderKeyFormat¶

[core.Http1ProtocolOptions.HeaderKeyFormat proto]

{
  "proper_case_words": "{...}"
}

proper_case_words: (core.Http1ProtocolOptions.HeaderKeyFormat.ProperCaseWords, REQUIRED) Formats the header by proper casing words: the first character and any character following a special character will be capitalized if it’s an alpha character. For example, “content-type” becomes “Content-Type”, and “foo$b#$are” becomes “Foo$B#$Are”. Note that while this results in most headers following conventional casing, certain headers are not covered. For example, the “TE” header will be formatted as “Te”.

core.Http1ProtocolOptions.HeaderKeyFormat.ProperCaseWords¶

[core.Http1ProtocolOptions.HeaderKeyFormat.ProperCaseWords proto]

{}

core.Http2ProtocolOptions¶

[core.Http2ProtocolOptions proto]

{
  "hpack_table_size": "{...}",
  "max_concurrent_streams": "{...}",
  "initial_stream_window_size": "{...}",
  "initial_connection_window_size": "{...}",
  "allow_connect": "...",
  "max_outbound_frames": "{...}",
  "max_outbound_control_frames": "{...}",
  "max_consecutive_inbound_frames_with_empty_payload": "{...}",
  "max_inbound_priority_frames_per_stream": "{...}",
  "max_inbound_window_update_frames_per_data_frame_sent": "{...}",
  "stream_error_on_invalid_http_messaging": "..."
}

hpack_table_size: (UInt32Value) Maximum table size (in octets) that the encoder is permitted to use for the dynamic HPACK table. Valid values range from 0 to 4294967295 (2^32 - 1) and defaults to 4096. 0 effectively disables header compression.

max_concurrent_streams: (UInt32Value) Maximum concurrent streams allowed for peer on one HTTP/2 connection. Valid values range from 1 to 2147483647 (2^31 - 1) and defaults to 2147483647.

initial_stream_window_size

(UInt32Value) Initial stream-level flow-control window size. Valid values range from 65535 (2^16 - 1, HTTP/2 default) to 2147483647 (2^31 - 1, HTTP/2 maximum) and defaults to 268435456 (256 * 1024 * 1024).

NOTE: 65535 is the initial window size from HTTP/2 spec. We only support increasing the default window size now, so it’s also the minimum.

This field also acts as a soft limit on the number of bytes Envoy will buffer per-stream in the HTTP/2 codec buffers. Once the buffer reaches this pointer, watermark callbacks will fire to stop the flow of data to the codec buffers.

initial_connection_window_size: (UInt32Value) Similar to initial_stream_window_size, but for connection-level flow-control window. Currently, this has the same minimum/maximum/default as initial_stream_window_size.

allow_connect: (bool) Allows proxying Websocket and other upgrades over H2 connect.

max_outbound_frames: (UInt32Value) Limit the number of pending outbound downstream frames of all types (frames that are waiting to be written into the socket). Exceeding this limit triggers flood mitigation and connection is terminated. The http2.outbound_flood stat tracks the number of terminated connections due to flood mitigation. The default limit is 10000.

max_outbound_control_frames: (UInt32Value) Limit the number of pending outbound downstream frames of types PING, SETTINGS and RST_STREAM, preventing high memory utilization when receiving continuous stream of these frames. Exceeding this limit triggers flood mitigation and connection is terminated. The http2.outbound_control_flood stat tracks the number of terminated connections due to flood mitigation. The default limit is 1000.

max_consecutive_inbound_frames_with_empty_payload: (UInt32Value) Limit the number of consecutive inbound frames of types HEADERS, CONTINUATION and DATA with an empty payload and no end stream flag. Those frames have no legitimate use and are abusive, but might be a result of a broken HTTP/2 implementation. The http2.inbound_empty_frames_flood` stat tracks the number of connections terminated due to flood mitigation. Setting this to 0 will terminate connection upon receiving first frame with an empty payload and no end stream flag. The default limit is 1.

max_inbound_priority_frames_per_stream

(UInt32Value) Limit the number of inbound PRIORITY frames allowed per each opened stream. If the number of PRIORITY frames received over the lifetime of connection exceeds the value calculated using this formula:

max_inbound_priority_frames_per_stream * (1 + inbound_streams)

the connection is terminated. The http2.inbound_priority_frames_flood stat tracks the number of connections terminated due to flood mitigation. The default limit is 100.

max_inbound_window_update_frames_per_data_frame_sent

(UInt32Value) Limit the number of inbound WINDOW_UPDATE frames allowed per DATA frame sent. If the number of WINDOW_UPDATE frames received over the lifetime of connection exceeds the value calculated using this formula:

1 + 2 * (inbound_streams +
         max_inbound_window_update_frames_per_data_frame_sent * outbound_data_frames)

the connection is terminated. The http2.inbound_priority_frames_flood stat tracks the number of connections terminated due to flood mitigation. The default limit is 10. Setting this to 1 should be enough to support HTTP/2 implementations with basic flow control, but more complex implementations that try to estimate available bandwidth require at least 2.

stream_error_on_invalid_http_messaging

(bool) Allows invalid HTTP messaging and headers. When this option is disabled (default), then the whole HTTP/2 connection is terminated upon receiving invalid HEADERS frame. However, when this option is enabled, only the offending stream is terminated.

See RFC7540, sec. 8.1 for details.