Hypertext Transfer Protocol (HTTP) Parameters

Last Updated

  • 2025-10-02

Available Formats


HTTP Content Coding Registry

Registration Procedure(s)

  • IETF Review

Reference

Available Formats

Name Description Reference Notes
aes128gcm AES-GCM encryption with a 128-bit content encryption key RFC 8188
br Brotli Compressed Data Format RFC 7932
compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] RFC 9110 Section 8.4.1.1
dcb "Dictionary-Compressed Brotli" data format. RFC 9842 Section 4
dcz "Dictionary-Compressed Zstandard" data format. RFC 9842 Section 5
deflate "deflate" compressed data (RFC 1951) inside the "zlib" data format (RFC 1950) RFC 9110 Section 8.4.1.2
exi W3C Efficient XML Interchange W3C Recommendation: Efficient XML Interchange (EXI) Format
gzip GZIP file format RFC 1952 RFC 9110 Section 8.4.1.3
identity Reserved RFC 9110 Section 12.5.3
pack200-gzip Network Transfer Format for Java Archives JSR 200: Network Transfer Format for Java; Kumar Srinivasan; John Rose
x-compress Deprecated (alias for compress) RFC 9110 Section 8.4.1.1
x-gzip Deprecated (alias for gzip) RFC 9110 Section 8.4.1.3
zstd A stream of bytes compressed using the Zstandard protocol with a Window_Size of not more than 8 MB. RFC 9659; RFC 8878

HTTP Transfer Coding Registry

Registration Procedure(s)

  • IETF Review

Reference

Available Formats

Name Description Reference Notes
chunked Transfer in a series of chunks RFC 9112 Section 7.1
compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] RFC 9112 Section 7.2
deflate "deflate" compressed data (RFC 1951) inside the "zlib" data format (RFC 1950) RFC 9112 Section 7.2
gzip GZIP file format RFC 1952 RFC 9112 Section 7.2
identity (withdrawn in errata to RFC 2616) RFC 2616 Section 3.6
trailers (reserved) RFC 9112 Section 12.3
x-compress Deprecated (alias for compress) RFC 9112 Section 7.2
x-gzip Deprecated (alias for gzip) RFC 9112 Section 7.2

HTTP Forwarded Parameters

Registration Procedure(s)

  • IETF Review

Reference

Available Formats

Name Description Reference Notes
by IP-address of incoming interface of a proxy RFC 7239 Section 5.1
for IP-address of client making a request through a proxy RFC 7239 Section 5.2
host Host header field of the incoming request RFC 7239 Section 5.3
proto Application protocol used for incoming request RFC 7239 Section 5.4

HTTP Preferences

Registration Procedure(s)

  • Specification Required

Expert(s)

  • Julian Reschke

Reference

Note

Registration requests should be sent to the mailing list described in RFC 7240. If approved, designated experts should notify IANA within two weeks. For assistance, please contact iana@iana.org.

Available Formats

Preference Value Description Reference
respond-async Indicates that the client prefers that the server respond asynchronously to a request. RFC 7240, Section 4.1
return One of either "minimal" or "representation" When the value is "minimal", it indicates that the client prefers that the server return a minimal response to a request. When the value is "representation", it indicates that the client prefers that the server include a representation of the current state of the resource in response to a request. RFC 7240, Section 4.2
wait Indicates an upper bound to the length of time the client expects it will take the server to process the request once it has been received. RFC 7240, Section 4.3
handling One of either "strict" or "lenient" When value is "strict", it indicates that the client wishes the server to apply strict validation and error handling to the processing of a request. When the value is "lenient", it indicates that the client wishes the server to apply lenient validation and error handling to the processing of the request. RFC 7240, Section 4.4
depth-noroot The "depth-noroot" preference indicates that the client wishes for the server to exclude the target (root) resource from processing by the HTTP method and only apply the HTTP method to the target resource's subordinate resources. This preference is only intended to be used with HTTP methods whose definitions explicitly provide support for the Depth RFC 4918 header field. Furthermore, this preference only applies when the Depth header field has a value of "1" or "infinity" (either implicitly or explicitly). RFC 8144, Section 4
safe Indicates that safe (i.e., unobjectionable) content is preferred. RFC 8674
odata.allow-entityreferences Indicates that the service is allowed to return references in place of resources that have previously been returned, with at least the properties requested, in the same response. OData Version 4.01 Part 1: Protocol
odata.callback Requests that the service invoke the specified URL to signal some service state, such as the completion of an asynchronous result or availability of new or modified information. The service state that triggers the change is dependent upon the request. OData Version 4.01 Part 1: Protocol
odata.continue-on-error Requests that the service attempt to continue processing a request that encounters non-fatal errors, for example in a multi-part request. The response SHOULD indicate what portions of the request were and were not able to be successfully handled. OData Version 4.01 Part 1: Protocol
odata.include-annotations Comma-separated list of terms to include or, when prefixed with a minus sign (-), exclude from the response. Terms MUST be namespace-qualified and MAY specify just a namespace to include or exclude all terms within that namespace. The special value "*" matches all annotations. Specifies the set of annotations the client requests to be included, where applicable, or excluded in the response. OData Version 4.01 Part 1: Protocol
odata.maxpagesize A positive integer that represents the maximum number of items each collection in a response SHOULD contain. Requests that each collection within the response contain no more than the number of items specified as the positive integer value of this preference. OData Version 4.01 Part 1: Protocol
omit-values One of nulls - properties containing null values may be omitted from the response defaults - properties containing the property default value may be omitted from the response. Specifies whether a server can omit properties with a null value or properties set to their default value from a response. OData Version 4.01 Part 1: Protocol
odata.track-changes Requests that the service initiate change tracking on the result of this request, according to the underlying protocol. OData Version 4.01 Part 1: Protocol

HTTP Range Unit Registry

Registration Procedure(s)

  • IETF Review

Reference

Available Formats

Name Description Reference Notes
bytes a range of octets RFC 9110 Section 14.1.2
none reserved as keyword to indicate range requests are not supported RFC 9110 Section 14.3

Contact Information

Name Contact URI Last Updated
Kumar Srinivasan Kumar.Srinivasan&Sun.COM 2006-10-27
John Rose John.Rose&Sun.COM 2006-10-27