goog.net.WebChannel.Options

Enable the blocking RPC semantics for the handshake:

1. the completion of handshake is blocked by the server-side application logic for handling the handshake (HTTP) request; 2) the client application will inspect the handshake (HTTP) response headers as generated by the server application (v.s. by only the webchannel runtime). This option defaults to false.

Inform the server about the client profile to enable customized configs that are optimized for certain clients or environments. Currently this information is sent via X-WebChannel-Client-Profile header.

Whether a special header should be added to each message so that the server can dispatch webchannel messages without knowing the URL path prefix. Defaults to false.

The maximum number of in-flight HTTP requests allowed when SPDY is enabled. Currently we only detect SPDY in Chrome. This parameter defaults to 10. When SPDY is not enabled, this parameter will have no effect.

Whether to enable automatic detection of buffering proxies. In the presence of any buffering proxy, webchannel will use long-polling to send messages from the server to the client. This option defaults to false. Currently when fastHandshake is enabled, this option will be ignored. Compared to "forceLongPolling", this option may introduce up to 2-RTT extra latency for delivering messages generated immediately after the handshake.

Whether to disable logging redact. By default, redact is enabled to remove any message payload or user-provided info from closure logs.

Opt-in to enable Chrome origin trials from the WebChannel client. See https://github.com/GoogleChrome/OriginTrials

Origin trial history:

• fetch upload (11/2020 - 07/2021) https://developers.chrome.com/origintrials/#/view_trial/3524066708417413121

Participating in the origin trials will help Chrome to release new Web platform features sooner, which will in turn help improve WebChannel performance.

Origin trials are not expected to interfere with WebChannel wire messages and should not introduce any noticeable overhead.

This is enabled by default with any on-going origin-trial.

Whether to encode Options.initMessageHeaders in the HTTP request body. This option defaults to false. If true, Options.httpHeadersOverwriteParam will be ignored.

This option should not be set if Options.fastHandshake is set (which uses GET for handshake).

Web-only feature.

Enable true 0-RTT message delivery, including leveraging QUIC 0-RTT (which requires GET to be used). This option defaults to false. Note it is allowed to send messages before Open event is received, after a channel has been opened. In order to enable 0-RTT, messages will be encoded as part of URL and therefore there needs be a size limit for those initial messages that are sent immediately as part of the GET handshake request. With sendRawJson=true, this limit is currently set to 4K chars and data beyond this limit will be buffered till the handshake (1-RTT) finishes. With sendRawJson=false, it's up to the application to limit the amount of data that is sent as part of the handshake.

Whether to force long-polling from client to server. This defaults to false. Long-polling may be necessary when a (MITM) proxy is buffering data sent by the server.

The URL parameter name to allow custom HTTP headers to be overwritten as a URL param to bypass CORS preflight.

The URL parameter name that contains the session id (for sticky routing of HTTP requests). When this param is specified, a server that supports this option will respond with an opaque session id as part of the initial handshake (via the X-HTTP-Session-Id header); and all the subsequent requests will contain the httpSessionIdParam. This option will take precedence over any duplicated parameter specified with messageUrlParams, whose value will be ignored.

Transport-metadata support.

Similar to messageHeaders, but any custom HTTP headers will be sent only once when the channel is opened as part of the handshake request. Typical usage is to send an auth header to the server, which only checks the auth header at the time during the handshake when the channel is opened.

The internal channel parameter name to allow experimental channel configurations. Supported options include fastfail, baseRetryDelayMs, retryDelaySeedMs, forwardChannelMaxRetries and forwardChannelRequestTimeoutMs. Note that these options are subject to change.

This option informs the server the desired maximum timeout interval (in Milliseconds) to complete a long-polling GET response, e.g. to accommodate the timeout enforced by a proxy. The WebChannel server may adjust the specified timeout or may ignore this client-configured timeout.

Sent as initMessageHeaders via X-WebChannel-Content-Type, to inform the server the MIME type of WebChannel messages.

Transport-metadata support.

Custom HTTP headers to be added to every message sent to the server. This object is mutable, and custom headers may be changed, removed, or added during the runtime after a channel has been opened.

Custom headers may trigger CORS preflight. See other related options.

Transport-metadata support.

Custom url query parameters to be added to every message sent to the server. This object is mutable, and custom parameters may be changed, removed or added during the runtime after a channel has been opened.

TODO: initMessageUrlParams TODO: closeMessageUrlParams (custom url query params to be added to the channel-close message. Custom headers are not supported due to the use of SendBeacon)

Client-side thresholds that decide when to refresh an underlying HTTP request, to limit memory consumption due to XHR buffering or compression context. The client-side thresholds should be significantly smaller than the server-side thresholds. This allows the client to eliminate any latency introduced by request refreshing, i.e. an RTT window during which messages may be buffered on the server-side. Supported params include totalBytesReceived, totalDurationMs.

Whether to bypass v8 encoding of client-sent messages. This defaults to false now due to legacy servers. New applications should always configure this option to true.

Setting this to true to allow the use of sub-domains (as configured by the server) to send XHRs with the CORS withCredentials bit set to true.

This is an experimental feature to use WHATWG Fetch/streams (when supported) for the backchannel. If a custom 'xmlHttpFactory' is speficied, this option will not be effective. This option defaults to false now and will eventually be turned on by default.

Allows the caller to override the factory used to create XMLHttpRequest objects. This is introduced to disable CORS on firefox OS.