Hypertext Transfer Protocol (HTTP) Parameters

Hypertext Transfer Protocol (HTTP) Parameters
Hypertext Transfer Protocol (HTTP) Parameters
2025-10-02
Available Formats
XML
HTML
Plain text
Registries Included Below
HTTP Content Coding Registry
HTTP Transfer Coding Registry
HTTP Forwarded Parameters
HTTP Preferences
HTTP Range Unit Registry
HTTP Content Coding Registry
Registration Procedure(s)
IETF Review
Reference
RFC9110, Section 16.6.1
Available Formats
CSV
Name
Description
Reference
Notes
aes128gcm
AES-GCM encryption with a 128-bit content encryption key
RFC8188
br
Brotli Compressed Data Format
RFC7932
compress
UNIX "compress" data format [Welch, T., "A Technique
for High Performance Data Compression", IEEE Computer 17(6), June 1984.]
RFC9110
Section 8.4.1.1
dcb
"Dictionary-Compressed Brotli" data format.
RFC9842
Section 4
dcz
"Dictionary-Compressed Zstandard" data format.
RFC9842
Section 5
deflate
"deflate" compressed data ([
RFC1951
])
inside the "zlib" data format ([
RFC1950
])
RFC9110
Section 8.4.1.2
exi
W3C Efficient XML Interchange
W3C Recommendation: Efficient XML
Interchange (EXI) Format
gzip
GZIP file format [
RFC1952
RFC9110
Section 8.4.1.3
identity
Reserved
RFC9110
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)
RFC9110
Section 8.4.1.1
x-gzip
Deprecated (alias for gzip)
RFC9110
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.
RFC9659
][
RFC8878
HTTP Transfer Coding Registry
Registration Procedure(s)
IETF Review
Reference
RFC9112, Section 7.3
Available Formats
CSV
Name
Description
Reference
Notes
chunked
Transfer in a series of chunks
RFC9112
Section 7.1
compress
UNIX "compress" data format [Welch, T., "A Technique
for High Performance Data Compression", IEEE Computer 17(6), June 1984.]
RFC9112
Section 7.2
deflate
"deflate" compressed data ([
RFC1951
])
inside the "zlib" data format ([
RFC1950
])
RFC9112
Section 7.2
gzip
GZIP file format [
RFC1952
RFC9112
Section 7.2
identity
(withdrawn in errata to [
RFC2616
])
RFC2616
Section 3.6
trailers
(reserved)
RFC9112
Section 12.3
x-compress
Deprecated (alias for compress)
RFC9112
Section 7.2
x-gzip
Deprecated (alias for gzip)
RFC9112
Section 7.2
HTTP Forwarded Parameters
Registration Procedure(s)
IETF Review
Reference
RFC7239
Available Formats
CSV
Name
Description
Reference
Notes
by
IP-address of incoming interface of a proxy
RFC7239
Section 5.1
for
IP-address of client making a request through a proxy
RFC7239
Section 5.2
host
Host header field of the incoming request
RFC7239
Section 5.3
proto
Application protocol used for incoming request
RFC7239
Section 5.4
HTTP Preferences
Registration Procedure(s)
Specification Required
Expert(s)
Julian Reschke
Reference
RFC7240
Note
Registration requests should be sent to the mailing list described in
RFC7240
]. If approved, designated experts should notify IANA within
two weeks. For assistance, please contact iana@iana.org.
Available Formats
CSV
Preference
Value
Description
Reference
respond-async
Indicates that the client prefers that the server respond asynchronously to a request.
RFC7240
], 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.
RFC7240
], 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.
RFC7240
], 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.
RFC7240
], 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 [
RFC4918
header field. Furthermore, this preference only applies when the
Depth header field has a value of "1" or "infinity" (either
implicitly or explicitly).
RFC8144
], Section 4
safe
Indicates that safe (i.e., unobjectionable) content
is preferred.
RFC8674
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
RFC9110, Section 16.5.1
Available Formats
CSV
Name
Description
Reference
Notes
bytes
a range of octets
RFC9110
Section 14.1.2
none
reserved as keyword to indicate range requests are not supported
RFC9110
Section 14.3
Contact Information
ID
Name
Contact URI
[Kumar_Srinivasan]
Kumar Srinivasan
mailto:Kumar.Srinivasan&Sun.COM
2006-10-27
[John_Rose]
John Rose
mailto:John.Rose&Sun.COM
2006-10-27