Package org.apache.juneau.http.header

Class TE

java.lang.Object
org.apache.juneau.http.header.BasicHeader
org.apache.juneau.http.header.BasicStringRangesHeader
org.apache.juneau.http.header.TE
All Implemented Interfaces:
Serializable, Cloneable, Header, NameValuePair
@Header("TE") public class TE extends BasicStringRangesHeader
Represents a parsed TE HTTP request header.

The transfer encodings the user agent is willing to accept: the same values as for the response header field Transfer-Encoding can be used, plus the "trailers" value (related to the "chunked" transfer method) to notify the server it expects to receive additional fields in the trailer after the last, zero-sized, chunk.

Example

TE: trailers, deflate

RFC2616 Specification
The TE request-header field indicates what extension transfer-codings it is willing to accept in the response and whether or not it is willing to accept trailer fields in a chunked transfer-coding. Its value may consist of the keyword "trailers" and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in section 3.6).

TE = "TE" ":" #( t-codings ) t-codings = "trailers" | ( transfer-extension [ accept-params ] )

The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding, as defined in section 3.6.1. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.

Examples of its use are:

TE: deflate TE: TE: trailers, deflate;q=0.5

The TE header field only applies to the immediate connection. Therefore, the keyword MUST be supplied within a Connection header field (section 14.10) whenever TE is present in an HTTP/1.1 message.

A server tests whether a transfer-coding is acceptable, according to a TE field, using these rules:

  1. The "chunked" transfer-coding is always acceptable. If the keyword "trailers" is listed, the client indicates that it is willing to accept trailer fields in the chunked response on behalf of itself and any downstream clients. The implication is that, if given, the client is stating that either all downstream clients are willing to accept trailer fields in the forwarded response, or that it will attempt to buffer the response on behalf of downstream recipients. Note: HTTP/1.1 does not define any means to limit the size of a chunked response such that a client can be assured of buffering the entire response.
  2. If the transfer-coding being tested is one of the transfer-codings listed in the TE field, then it is acceptable unless it is accompanied by a qvalue of 0. (As defined in section 3.9, a qvalue of 0 means "not acceptable.")
  3. If multiple transfer-codings are acceptable, then the acceptable transfer-coding with the highest non-zero qvalue is preferred. The "chunked" transfer-coding always has a qvalue of 1.

If the TE field-value is empty or if no TE field is present, the only transfer-coding is "chunked". A message with no transfer-coding is always acceptable.

See Also:

  • Constructor Details

  • Method Details

    • of

      public static TE of(String value)
      Static creator.
      Parameters:
      value - The header value.
      Must be parsable by StringRanges.of(String).
      Can be null.
      Returns:
      A new header bean, or null if the value is null.

    • of

      public static TE of(StringRanges value)
      Static creator.
      Parameters:
      value - The header value.
      Can be null.
      Returns:
      A new header bean, or null if the value is null.

    • of

      public static TE of(Supplier<StringRanges> value)
      Static creator with delayed value.

      Header value is re-evaluated on each call to BasicStringRangesHeader.getValue().

      Parameters:
      value - The supplier of the header value.
      Can be null.
      Returns:
      A new header bean, or null if the value is null.