2017-06-26 IETF Review aes128gcm AES-GCM encryption with a 128-bit content encryption key br Brotli Compressed Data Format compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] Section 4.2.1 deflate "deflate" compressed data () inside the "zlib" data format () Section 4.2.2 exi W3C Efficient XML Interchange W3C Recommendation: Efficient XML Interchange (EXI) Format gzip GZIP file format Section 4.2.3 identity Reserved (synonym for "no encoding" in Accept-Encoding) Section 5.3.4 pack200-gzip Network Transfer Format for Java Archives JSR 200: Network Transfer Format for Java x-compress Deprecated (alias for compress) Section 4.2.1 x-gzip Deprecated (alias for gzip) Section 4.2.3 IETF Review chunked Transfer in a series of chunks Section 4.1 compress UNIX "compress" data format [Welch, T., "A Technique for High Performance Data Compression", IEEE Computer 17(6), June 1984.] Section 4.2.1 deflate "deflate" compressed data () inside the "zlib" data format () Section 4.2.2 gzip GZIP file format Section 4.2.3 identity (withdrawn in errata to ) Section 3.6 x-compress Deprecated (alias for compress) Section 4.2.1 x-gzip Deprecated (alias for gzip) Section 4.2.3 IETF Review by IP-address of incoming interface of a proxy Section 5.1 for IP-address of client making a request through a proxy Section 5.2 host Host header field of the incoming request Section 5.3 proto Application protocol used for incoming request Section 5.4 Specification Required James M Snell, Julian Reschke respond-async Indicates that the client prefers that the server respond asynchronously to a request. , 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. , 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. , 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. , 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 header field. Furthermore, this preference only applies when the Depth header field has a value of "1" or "infinity" (either implicitly or explicitly). , Section 4 IETF Review bytes a range of octets Section 2.1 none reserved as keyword, indicating no ranges are supported Section 2.3 Kumar Srinivasan mailto:Kumar.Srinivasan&Sun.COM 2006-10-27 John Rose mailto:John.Rose&Sun.COM 2006-10-27