From eb8181bb06396637c4d2269a3af0c5333e91fb61 Mon Sep 17 00:00:00 2001 From: dret Date: Fri, 13 Oct 2017 18:30:11 +0200 Subject: [PATCH] adding link tool tips for #46 (maybe that's all it takes) this took much longer than it should have. MD is horrible. in this case, escaping '<' in link tool tips seems to be necessary in jekyll, even though it is not necessary in atom. it would be good to have a proper function for MD output that handles all necessary escaping. --- concepts/http-authentication-scheme.md | 20 +- concepts/http-cache-directive.md | 30 +- concepts/http-content-coding.md | 20 +- concepts/http-forwarded-parameter.md | 8 +- concepts/http-header.md | 382 +++++++++--------- concepts/http-method.md | 78 ++-- concepts/http-preference.md | 8 +- concepts/http-range-unit.md | 6 +- concepts/http-status-code.md | 124 +++--- concepts/http-transfer-coding.md | 14 +- concepts/http-warn-code.md | 14 +- concepts/jwt-claim.md | 16 +- concepts/jwt-confirmation-method.md | 8 +- concepts/link-relation.md | 192 ++++----- concepts/media-type.md | 204 +++++----- concepts/oauth-access-token-type.md | 4 +- ...th-authorization-endpoint-response-type.md | 4 +- concepts/oauth-client-metadata.md | 40 +- concepts/oauth-extension-error.md | 8 +- concepts/oauth-parameter.md | 53 +-- concepts/oauth-token-endpoint-auth-method.md | 6 +- .../oauth-token-introspection-response.md | 24 +- concepts/oauth-token-type-hint.md | 4 +- concepts/oauth-uri.md | 10 +- concepts/pkce-code-challenge-method.md | 4 +- concepts/profile-uri.md | 2 +- concepts/structured-syntax-suffix.md | 20 +- concepts/uri-scheme.md | 62 +-- concepts/urn-namespace.md | 24 +- concepts/well-known-uri.md | 42 +- concepts/xml-ns.md | 4 +- concepts/xml-schema.md | 2 +- xml2jekyll.xsl | 6 +- 33 files changed, 721 insertions(+), 722 deletions(-) diff --git a/concepts/http-authentication-scheme.md b/concepts/http-authentication-scheme.md index c26e16f1..da52e3b4 100644 --- a/concepts/http-authentication-scheme.md +++ b/concepts/http-authentication-scheme.md @@ -10,16 +10,16 @@ The following 10 HTTP Authentication Scheme values were found in [all available HTTP Authentication Scheme | Specification -------: | :------- -[`Basic`](/concepts/http-authentication-scheme/Basic) | [**RFC 7617**: The 'Basic' HTTP Authentication Scheme](/specs/IETF/RFC/7617 "This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/password pairs, encoded using Base64.") -[`Bearer`](/concepts/http-authentication-scheme/Bearer) | [**RFC 6750**: The OAuth 2.0 Authorization Framework: Bearer Token Usage](/specs/IETF/RFC/6750 "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.") -[`Digest`](/concepts/http-authentication-scheme/Digest) | [**RFC 7616**: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 "The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.") -[`HOBA`](/concepts/http-authentication-scheme/HOBA) | [**RFC 7486**: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 "HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.") -[`Mutual`](/concepts/http-authentication-scheme/Mutual) | [**RFC 8120**: Mutual Authentication Protocol for HTTP](/specs/IETF/RFC/8120 "This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.") -[`Negotiate`](/concepts/http-authentication-scheme/Negotiate) | [**RFC 4559**: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows](/specs/IETF/RFC/4559 "This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.") -[`OAuth`](/concepts/http-authentication-scheme/OAuth) | [**RFC 5849**: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 "OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.") -[`SCRAM-SHA-1`](/concepts/http-authentication-scheme/SCRAM-SHA-1) | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.") -[`SCRAM-SHA-256`](/concepts/http-authentication-scheme/SCRAM-SHA-256) | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.") -[`vapid`](/concepts/http-authentication-scheme/vapid) | [**Internet Draft ietf-webpush-vapid**: Voluntary Application Server Identification (VAPID) for Web Push](/specs/IETF/I-D/ietf-webpush-vapid "An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server.") +[`Basic`](/concepts/http-authentication-scheme/Basic "The Basic authentication scheme is based on the model that the client needs to authenticate itself with a user-id and a password for each protection space ("realm"). The realm value is a free-form string that can only be compared for equality with other realms on that server.") | [**RFC 7617**: The 'Basic' HTTP Authentication Scheme](/specs/IETF/RFC/7617 "This document defines the "Basic" Hypertext Transfer Protocol (HTTP) authentication scheme, which transmits credentials as user-id/password pairs, encoded using Base64.") +[`Bearer`](/concepts/http-authentication-scheme/Bearer "All challenges defined by this specification MUST use the auth-scheme value "Bearer". This scheme MUST be followed by one or more auth-param values.") | [**RFC 6750**: The OAuth 2.0 Authorization Framework: Bearer Token Usage](/specs/IETF/RFC/6750 "This specification describes how to use bearer tokens in HTTP requests to access OAuth 2.0 protected resources. Any party in possession of a bearer token (a "bearer") can use it to get access to the associated resources (without demonstrating possession of a cryptographic key). To prevent misuse, bearer tokens need to be protected from disclosure in storage and in transport.") +[`Digest`](/concepts/http-authentication-scheme/Digest "The Digest scheme is based on a simple challenge-response paradigm. The Digest scheme challenges using a nonce value and might indicate that username hashing is supported. A valid response contains an unkeyed digest of the username, the password, the given nonce value, the HTTP method, and the requested URI.") | [**RFC 7616**: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 "The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.") +[`HOBA`](/concepts/http-authentication-scheme/HOBA "An HTTP server that supports HOBA authentication includes the "HOBA" auth-scheme value in a WWW-Authenticate header field when it wants the client to authenticate with HOBA.") | [**RFC 7486**: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 "HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.") +[`Mutual`](/concepts/http-authentication-scheme/Mutual "The scheme provides true mutual authentication between an HTTP client and an HTTP server, using just a simple password as a credential.") | [**RFC 8120**: Mutual Authentication Protocol for HTTP](/specs/IETF/RFC/8120 "This document specifies an authentication scheme for the Hypertext Transfer Protocol (HTTP) that is referred to as either the Mutual authentication scheme or the Mutual authentication protocol. This scheme provides true mutual authentication between an HTTP client and an HTTP server using password-based authentication. Unlike the Basic and Digest authentication schemes, the Mutual authentication scheme specified in this document assures the user that the server truly knows the user's encrypted password.") +[`Negotiate`](/concepts/http-authentication-scheme/Negotiate "Use of Kerberos is wrapped in an HTTP auth-scheme of "Negotiate".") | [**RFC 4559**: SPNEGO-based Kerberos and NTLM HTTP Authentication in Microsoft Windows](/specs/IETF/RFC/4559 "This document describes how the Microsoft Internet Explorer (MSIE) and Internet Information Services (IIS) incorporated in Microsoft Windows 2000 use Kerberos for security enhancements of web transactions. The Hypertext Transport Protocol (HTTP) auth-scheme of "negotiate" is defined here; when the negotiation results in the selection of Kerberos, the security services of authentication and, optionally, impersonation (the IIS server assumes the windows identity of the principal that has been authenticated) are performed. This document explains how HTTP authentication utilizes the Simple and Protected GSS-API Negotiation mechanism. Details of Simple And Protected Negotiate (SPNEGO) implementation are not provided in this document.") +[`OAuth`](/concepts/http-authentication-scheme/OAuth "Protocol parameters can be transmitted using the HTTP "Authorization" header field as defined by RFC 2617 with the auth-scheme name set to "OAuth" (case insensitive). Servers MAY indicate their support for the "OAuth" auth-scheme by returning the HTTP "WWW-Authenticate" response header field upon client requests for protected resources.") | [**RFC 5849**: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 "OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.") +[`SCRAM-SHA-1`](/concepts/http-authentication-scheme/SCRAM-SHA-1 "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. SCRAM-SHA-1 is registered for database compatibility with implementations of RFC 5802 that want to also expose HTTP access to a related service, but it is not recommended for new deployments.") | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.") +[`SCRAM-SHA-256`](/concepts/http-authentication-scheme/SCRAM-SHA-256 "HTTP SCRAM is an HTTP Authentication mechanism whose client response and server challenge messages are text-based messages containing one or more attribute-value pairs separated by commas. For interoperability, all HTTP clients and servers supporting SCRAM MUST implement the SCRAM-SHA-256 authentication mechanism.") | [**RFC 7804**: Salted Challenge Response HTTP Authentication Mechanism](/specs/IETF/RFC/7804 "This specification describes a family of HTTP authentication mechanisms called the Salted Challenge Response Authentication Mechanism (SCRAM), which provides a more robust authentication mechanism than a plaintext password protected by Transport Layer Security (TLS) and avoids the deployment obstacles presented by earlier TLS-protected challenge response authentication mechanisms.") +[`vapid`](/concepts/http-authentication-scheme/vapid "This authentication scheme carries a signed JWT, plus the key that signed that JWT. This authentication scheme is for origin-server authentication only. Therefore, this authentication scheme MUST NOT be used with the Proxy-Authenticate or Proxy-Authorization header fields. ") | [**Internet Draft ietf-webpush-vapid**: Voluntary Application Server Identification (VAPID) for Web Push](/specs/IETF/I-D/ietf-webpush-vapid "An application server can use the method described to voluntarily identify itself to a push service. This identification information can be used by the push service to attribute requests that are made by the same application server to a single entity. An application server can include additional information that the operator of a push service can use to contact the operator of the application server. This identification information can be used to restrict the use of a push subscription a single application server.")
diff --git a/concepts/http-cache-directive.md b/concepts/http-cache-directive.md index b9db07d7..10f736d6 100644 --- a/concepts/http-cache-directive.md +++ b/concepts/http-cache-directive.md @@ -10,21 +10,21 @@ The following 15 HTTP Cache Directive values were found in [all available `webco HTTP Cache Directive | Specification -------: | :------- -[`immutable`](/concepts/http-cache-directive/immutable) | [**RFC 8246**: HTTP Immutable Responses](/specs/IETF/RFC/8246 "The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.") -[`max-age`](/concepts/http-cache-directive/max-age) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`max-stale`](/concepts/http-cache-directive/max-stale) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`min-fresh`](/concepts/http-cache-directive/min-fresh) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`must-revalidate`](/concepts/http-cache-directive/must-revalidate) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`no-cache`](/concepts/http-cache-directive/no-cache) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`no-store`](/concepts/http-cache-directive/no-store) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`no-transform`](/concepts/http-cache-directive/no-transform) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`only-if-cached`](/concepts/http-cache-directive/only-if-cached) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`private`](/concepts/http-cache-directive/private) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`proxy-revalidate`](/concepts/http-cache-directive/proxy-revalidate) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`public`](/concepts/http-cache-directive/public) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`s-maxage`](/concepts/http-cache-directive/s-maxage) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`stale-if-error`](/concepts/http-cache-directive/stale-if-error) | [**RFC 5861**: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.") -[`stale-while-revalidate`](/concepts/http-cache-directive/stale-while-revalidate) | [**RFC 5861**: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.") +[`immutable`](/concepts/http-cache-directive/immutable "When present in an HTTP response, the immutable Cache-Control extension indicates that the origin server MUST NOT update the representation of that resource during the freshness lifetime of the response.") | [**RFC 8246**: HTTP Immutable Responses](/specs/IETF/RFC/8246 "The immutable HTTP response Cache-Control extension allows servers to identify resources that will not be updated during their freshness lifetime. This ensures that a client never needs to revalidate a cached fresh resource to be certain it has not been modified.") +[`max-age`](/concepts/http-cache-directive/max-age "The "max-age" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a stale response. The "max-age" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`max-stale`](/concepts/http-cache-directive/max-stale "The "max-stale" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`min-fresh`](/concepts/http-cache-directive/min-fresh "The "min-fresh" request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`must-revalidate`](/concepts/http-cache-directive/must-revalidate "The "must-revalidate" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`no-cache`](/concepts/http-cache-directive/no-cache "The "no-cache" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server. The "no-cache" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`no-store`](/concepts/http-cache-directive/no-store "The "no-store" directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. "MUST NOT store" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`no-transform`](/concepts/http-cache-directive/no-transform "The "no-transform" directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`only-if-cached`](/concepts/http-cache-directive/only-if-cached "The "only-if-cached" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`private`](/concepts/http-cache-directive/private "The "private" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`proxy-revalidate`](/concepts/http-cache-directive/proxy-revalidate "The "proxy-revalidate" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`public`](/concepts/http-cache-directive/public "The "public" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`s-maxage`](/concepts/http-cache-directive/s-maxage "The "s-maxage" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.") | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") +[`stale-if-error`](/concepts/http-cache-directive/stale-if-error "The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.") | [**RFC 5861**: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.") +[`stale-while-revalidate`](/concepts/http-cache-directive/stale-while-revalidate "When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.") | [**RFC 5861**: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 "This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.")
diff --git a/concepts/http-content-coding.md b/concepts/http-content-coding.md index b65fe79f..177afac6 100644 --- a/concepts/http-content-coding.md +++ b/concepts/http-content-coding.md @@ -10,16 +10,16 @@ The following 10 HTTP Content Coding values were found in [all available `webcon HTTP Content Coding | Specification -------: | :------- -[`aes128gcm`](/concepts/http-content-coding/aes128gcm) | [**RFC 8188**: Encrypted Content-Encoding for HTTP](/specs/IETF/RFC/8188 "This memo introduces a content coding for HTTP that allows message payloads to be encrypted.") -[`br`](/concepts/http-content-coding/br) | [**RFC 7932**: Brotli Compressed Data Format](/specs/IETF/RFC/7932 "This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.") -[`compress`](/concepts/http-content-coding/compress) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`deflate`](/concepts/http-content-coding/deflate) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`exi`](/concepts/http-content-coding/exi) | [**W3C TR http://www.w3.org/TR/exi**: Efficient XML Interchange (EXI) Format 1.0](/specs/W3C/TR/exi "This document is the specification of the Efficient XML Interchange (EXI) format. EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of datatype representations, it reliably produces efficient encodings of XML event streams. The grammar production system and format definition of EXI are presented.") -[`gzip`](/concepts/http-content-coding/gzip) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`identity`](/concepts/http-content-coding/identity) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`pack200-gzip`](/concepts/http-content-coding/pack200-gzip) | [**JSR 200**: Pack200: A Packed Class Deployment Format For Java Applications](/specs/JCP/JSR/200 "This document specifies an archive format called "Pack200". It is optimized for applications written in the Javatm programming language. Such applications are usually delivered as collections of classes, sometimes with associated resource files. This format allows any number (from one to hundreds of thousands) of Java classes to be encoded by a compressor, transmitted compactly in a single block of bytes, and decoded by a decompressor into equivalent Java class files. Because it can also represent class resources and other "side files", it can serve as an alternative to the JAR archive for some deployment tasks, notably downloading Java applications.") -[`x-compress`](/concepts/http-content-coding/x-compress) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`x-gzip`](/concepts/http-content-coding/x-gzip) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") +[`aes128gcm`](/concepts/http-content-coding/aes128gcm "The "aes128gcm" HTTP content coding indicates that a payload has been encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in RFC 5116. The AEAD_AES_128_GCM algorithm uses a 128 bit content encryption key.") | [**RFC 8188**: Encrypted Content-Encoding for HTTP](/specs/IETF/RFC/8188 "This memo introduces a content coding for HTTP that allows message payloads to be encrypted.") +[`br`](/concepts/http-content-coding/br "This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.") | [**RFC 7932**: Brotli Compressed Data Format](/specs/IETF/RFC/7932 "This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.") +[`compress`](/concepts/http-content-coding/compress "The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program "compress". A recipient SHOULD consider "x-compress" to be equivalent to "compress".") | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") +[`deflate`](/concepts/http-content-coding/deflate "The "deflate" coding is a "zlib" data format containing a "deflate" compressed data stream that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.") | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") +[`exi`](/concepts/http-content-coding/exi "The content-coding value "exi" is registered with the Internet Assigned Numbers Authority (IANA) for use with EXI. Protocols that can identify and negotiate the content coding of XML information independent of its media type, SHOULD use the content coding "exi" (case-insensitive) to convey the acceptance or actual use of EXI encoding for XML information.") | [**W3C TR http://www.w3.org/TR/exi**: Efficient XML Interchange (EXI) Format 1.0](/specs/W3C/TR/exi "This document is the specification of the Efficient XML Interchange (EXI) format. EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of datatype representations, it reliably produces efficient encodings of XML event streams. The grammar production system and format definition of EXI are presented.") +[`gzip`](/concepts/http-content-coding/gzip "The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider "x-gzip" to be equivalent to "gzip".") | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") +[`identity`](/concepts/http-content-coding/identity "An "identity" token is used as a synonym for "no encoding" in order to communicate when no encoding is preferred.") | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") +[`pack200-gzip`](/concepts/http-content-coding/pack200-gzip "The Pack200 format can decrease the size of a Java application by a factor of seven to nine, compared with an equivalent JAR containing uncompressed ("stored") class files. By contrast, using the zip DEFLATE algorithm integral to JAR and ZIP archives gains a factor of two.") | [**JSR 200**: Pack200: A Packed Class Deployment Format For Java Applications](/specs/JCP/JSR/200 "This document specifies an archive format called "Pack200". It is optimized for applications written in the Javatm programming language. Such applications are usually delivered as collections of classes, sometimes with associated resource files. This format allows any number (from one to hundreds of thousands) of Java classes to be encoded by a compressor, transmitted compactly in a single block of bytes, and decoded by a decompressor into equivalent Java class files. Because it can also represent class resources and other "side files", it can serve as an alternative to the JAR archive for some deployment tasks, notably downloading Java applications.") +[`x-compress`](/concepts/http-content-coding/x-compress "The "compress" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program "compress". A recipient SHOULD consider "x-compress" to be equivalent to "compress".") | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") +[`x-gzip`](/concepts/http-content-coding/x-gzip "The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider "x-gzip" to be equivalent to "gzip".") | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.")
diff --git a/concepts/http-forwarded-parameter.md b/concepts/http-forwarded-parameter.md index 38df2bb7..54739c9e 100644 --- a/concepts/http-forwarded-parameter.md +++ b/concepts/http-forwarded-parameter.md @@ -10,10 +10,10 @@ The following 4 HTTP Forwarded Parameter values were found in [all available `we HTTP Forwarded Parameter | Specification -------: | :------- -[`by`](/concepts/http-forwarded-parameter/by) | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") -[`for`](/concepts/http-forwarded-parameter/for) | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") -[`host`](/concepts/http-forwarded-parameter/host) | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") -[`proto`](/concepts/http-forwarded-parameter/proto) | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") +[`by`](/concepts/http-forwarded-parameter/by "The "by" parameter is used to disclose the interface where the request came in to the proxy server.") | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") +[`for`](/concepts/http-forwarded-parameter/for "The "for" parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies.") | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") +[`host`](/concepts/http-forwarded-parameter/host "The "host" parameter is used to forward the original value of the "Host" header field.") | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") +[`proto`](/concepts/http-forwarded-parameter/proto "The "proto" parameter has the value of the used protocol type.") | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.")
diff --git a/concepts/http-header.md b/concepts/http-header.md index 3e639ad0..0e1ca686 100644 --- a/concepts/http-header.md +++ b/concepts/http-header.md @@ -10,197 +10,197 @@ The following 202 HTTP Header Field values (191 distinct values) were found in [ HTTP Header Field | Specification -------: | :------- -[`A-IM`](/concepts/http-header/A-IM) | [**RFC 3229**: Delta encoding in HTTP](/specs/IETF/RFC/3229 "This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."") -[`ALPN`](/concepts/http-header/ALPN) | [**RFC 7639**: The ALPN HTTP Header Field](/specs/IETF/RFC/7639 "This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.") -[`Accept`](/concepts/http-header/Accept) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Accept-Additions`](/concepts/http-header/Accept-Additions)2 | [**RFC 2324**: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)](/specs/IETF/RFC/2324 "This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.")
[**RFC 7168**: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)](/specs/IETF/RFC/7168 "The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.") -[`Accept-CH`](/concepts/http-header/Accept-CH) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`Accept-CH-Lifetime`](/concepts/http-header/Accept-CH-Lifetime) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`Accept-Charset`](/concepts/http-header/Accept-Charset) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Accept-Datetime`](/concepts/http-header/Accept-Datetime) | [**RFC 7089**: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 "The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.") -[`Accept-Encoding`](/concepts/http-header/Accept-Encoding)2 | [**RFC 7694**: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding](/specs/IETF/RFC/7694 "In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages. Content codings can be used in request messages as well, however discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate that content codings are supported in requests.")
[**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Accept-Features`](/concepts/http-header/Accept-Features) | [**RFC 2295**: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 "HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.") -[`Accept-Indefinite-Ranges`](/concepts/http-header/Accept-Indefinite-Ranges) | [**Internet Draft combs-http-indeterminate-range**: HTTP/1.1: Range Responses of Indeterminate Length](/specs/IETF/I-D/combs-http-indeterminate-range "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document updates RFC 7233 Part 5 of the eight-part specification that defines the protocol referred to as "HTTP/1.1". Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. This document improves support for responding to range requests for resources of indeterminate size.") -[`Accept-Language`](/concepts/http-header/Accept-Language) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Accept-Patch`](/concepts/http-header/Accept-Patch) | [**RFC 5789**: PATCH Method for HTTP](/specs/IETF/RFC/5789 "Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.") -[`Accept-Post`](/concepts/http-header/Accept-Post) | [**W3C TR http://www.w3.org/TR/ldp**: Linked Data Platform 1.0 (LDP)](/specs/W3C/TR/ldp "Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.") -[`Accept-Push-Policy`](/concepts/http-header/Accept-Push-Policy) | [**Internet Draft ruellan-http-accept-push-policy**: Accept-Push-Policy Header Field](/specs/IETF/I-D/ruellan-http-accept-push-policy "The "Accept-Push-Policy" and "Push-Policy" header fields enable a client and a server to negotiate the behaviour of the server regarding the usage of push on a per-request basis.") -[`Accept-Ranges`](/concepts/http-header/Accept-Ranges) | [**RFC 7233**: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.") -[`Access-Control-Allow-Credentials`](/concepts/http-header/Access-Control-Allow-Credentials) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Allow-Headers`](/concepts/http-header/Access-Control-Allow-Headers) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Allow-Methods`](/concepts/http-header/Access-Control-Allow-Methods) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Allow-Origin`](/concepts/http-header/Access-Control-Allow-Origin) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Expose-Headers`](/concepts/http-header/Access-Control-Expose-Headers) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Max-Age`](/concepts/http-header/Access-Control-Max-Age) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Request-Headers`](/concepts/http-header/Access-Control-Request-Headers) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Access-Control-Request-Method`](/concepts/http-header/Access-Control-Request-Method) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Age`](/concepts/http-header/Age) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`Allow`](/concepts/http-header/Allow) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Alt-Svc`](/concepts/http-header/Alt-Svc) | [**RFC 7838**: HTTP Alternate Services](/specs/IETF/RFC/7838 "This document specifies "alternative services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.") -[`Alt-Used`](/concepts/http-header/Alt-Used) | [**RFC 7838**: HTTP Alternate Services](/specs/IETF/RFC/7838 "This document specifies "alternative services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.") -[`Alternates`](/concepts/http-header/Alternates) | [**RFC 2295**: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 "HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.") -[`Apply-To-Redirect-Ref`](/concepts/http-header/Apply-To-Redirect-Ref) | [**RFC 4437**: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 "This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.") -[`Authentication-Control`](/concepts/http-header/Authentication-Control) | [**RFC 8053**: HTTP Authentication Extensions for Interactive Clients](/specs/IETF/RFC/8053 "This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.") -[`Authentication-Info`](/concepts/http-header/Authentication-Info) | [**RFC 7615**: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields](/specs/IETF/RFC/7615 "This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted.") -[`Authorization`](/concepts/http-header/Authorization)3 | [**RFC 7616**: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 "The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.")
[**RFC 7235**: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.")
[**RFC 5849**: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 "OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.") -[`C-Ext`](/concepts/http-header/C-Ext) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`C-Man`](/concepts/http-header/C-Man) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`C-Opt`](/concepts/http-header/C-Opt) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`C-PEP`](/concepts/http-header/C-PEP) | [**W3C TR http://www.w3.org/TR/WD-http-pep**: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep " HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.") -[`C-PEP-Info`](/concepts/http-header/C-PEP-Info) | [**W3C TR http://www.w3.org/TR/WD-http-pep**: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep " HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.") -[`Cache-Control`](/concepts/http-header/Cache-Control) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`Cache-NT`](/concepts/http-header/Cache-NT) | [**Internet Draft drechsler-httpbis-improved-caching**: Hypertext Transfer Protocol: Improved HTTP Caching](/specs/IETF/I-D/drechsler-httpbis-improved-caching "This document describes an improved HTTP caching method which can be applied in addition to the standard caching behavior for HTTP. It defines the associated header field that controls this improved caching mechanism and a modified caching operation which is slightly different to standard caching operation for HTTP.") -[`Cal-Managed-ID`](/concepts/http-header/Cal-Managed-ID) | [**Internet Draft ietf-calext-caldav-attachments**: CalDAV Managed Attachments](/specs/IETF/I-D/ietf-calext-caldav-attachments "This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server.") -[`Clear-Site-Data`](/concepts/http-header/Clear-Site-Data) | [**W3C TR http://www.w3.org/TR/clear-site-data**: Clear Site Data](/specs/W3C/TR/clear-site-data "This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a user's locally stored data related to a host and its subdomains.") -[`Close`](/concepts/http-header/Close) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`Connection`](/concepts/http-header/Connection) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`Content-Base`](/concepts/http-header/Content-Base) | [**RFC 2068**: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".") -[`Content-DPR`](/concepts/http-header/Content-DPR) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`Content-Disposition`](/concepts/http-header/Content-Disposition) | [**RFC 6266**: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)](/specs/IETF/RFC/6266 "RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.") -[`Content-Encoding`](/concepts/http-header/Content-Encoding) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Content-Language`](/concepts/http-header/Content-Language) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Content-Length`](/concepts/http-header/Content-Length) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`Content-Location`](/concepts/http-header/Content-Location) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Content-Range`](/concepts/http-header/Content-Range)2 | [**Internet Draft combs-http-indeterminate-range**: HTTP/1.1: Range Responses of Indeterminate Length](/specs/IETF/I-D/combs-http-indeterminate-range "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document updates RFC 7233 Part 5 of the eight-part specification that defines the protocol referred to as "HTTP/1.1". Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. This document improves support for responding to range requests for resources of indeterminate size.")
[**RFC 7233**: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.") -[`Content-Security-Policy`](/concepts/http-header/Content-Security-Policy)2 | [**W3C TR http://www.w3.org/TR/CSP2**: Content Security Policy Level 2](/specs/W3C/TR/CSP2 "This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.")
[**W3C TR http://www.w3.org/TR/CSP3**: Content Security Policy Level 3](/specs/W3C/TR/CSP3 "This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.") -[`Content-Security-Policy-Pin`](/concepts/http-header/Content-Security-Policy-Pin) | [**W3C TR http://www.w3.org/TR/csp-pinning**: Content Security Policy Pinning](/specs/W3C/TR/csp-pinning "This document defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.") -[`Content-Security-Policy-Report-Only`](/concepts/http-header/Content-Security-Policy-Report-Only)2 | [**W3C TR http://www.w3.org/TR/CSP2**: Content Security Policy Level 2](/specs/W3C/TR/CSP2 "This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.")
[**W3C TR http://www.w3.org/TR/CSP3**: Content Security Policy Level 3](/specs/W3C/TR/CSP3 "This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.") -[`Content-Security-Policy-Report-Only-Pin`](/concepts/http-header/Content-Security-Policy-Report-Only-Pin) | [**W3C TR http://www.w3.org/TR/csp-pinning**: Content Security Policy Pinning](/specs/W3C/TR/csp-pinning "This document defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.") -[`Content-Signature`](/concepts/http-header/Content-Signature) | [**Internet Draft thomson-http-content-signature**: Content-Signature Header Field for HTTP](/specs/IETF/I-D/thomson-http-content-signature "A Content-Signature header field is defined for use in HTTP. This header field carries a signature of the payload body of a message.") -[`Content-Translation-Type`](/concepts/http-header/Content-Translation-Type) | [**RFC 8255**: Multiple Language Content Type](/specs/IETF/RFC/8255 "This document defines the 'multipart/multilingual' content type, which is an addition to the Multipurpose Internet Mail Extensions (MIME) standard. This content type makes it possible to send one message that contains multiple language versions of the same information. The translations would be identified by a language tag and selected by the email client based on a user's language settings.") -[`Content-Type`](/concepts/http-header/Content-Type) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Content-Version`](/concepts/http-header/Content-Version) | [**RFC 2068**: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".") -[`Cookie`](/concepts/http-header/Cookie)2 | [**Internet Draft ietf-httpbis-rfc6265bis**: HTTP State Management Mechanism](/specs/IETF/I-D/ietf-httpbis-rfc6265bis "This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet. This document obsoletes RFC 2965.")
[**RFC 6265**: HTTP State Management Mechanism](/specs/IETF/RFC/6265 "This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.") -[`Cookie2`](/concepts/http-header/Cookie2) | [**RFC 2965**: HTTP State Management Mechanism](/specs/IETF/RFC/2965 "This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method.") -[`DASL`](/concepts/http-header/DASL) | [**RFC 5323**: Web Distributed Authoring and Versioning (WebDAV) SEARCH](/specs/IETF/RFC/5323 "This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria.") -[`DAV`](/concepts/http-header/DAV) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`DNT`](/concepts/http-header/DNT) | [**W3C TR http://www.w3.org/TR/tracking-dnt**: Tracking Preference Expression (DNT)](/specs/W3C/TR/tracking-dnt "This specification defines the technical mechanisms for expressing a tracking preference via the DNT request header field in HTTP, via an HTML DOM property readable by embedded scripts, and via properties accessible to various user agent plug-in or extension APIs. It also defines mechanisms for sites to signal whether and how they honor this preference, both in the form of a machine-readable tracking status resource at a well-known location and via a "Tk" response header field, and a mechanism for allowing the user to approve exceptions to DNT as desired.") -[`DPR`](/concepts/http-header/DPR) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`Date`](/concepts/http-header/Date) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Delta-Base`](/concepts/http-header/Delta-Base) | [**RFC 3229**: Delta encoding in HTTP](/specs/IETF/RFC/3229 "This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."") -[`Depth`](/concepts/http-header/Depth) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`Destination`](/concepts/http-header/Destination) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`Digest`](/concepts/http-header/Digest) | [**RFC 3230**: Instance Digests in HTTP](/specs/IETF/RFC/3230 "HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.") -[`Downlink`](/concepts/http-header/Downlink) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`EDIINT-Features`](/concepts/http-header/EDIINT-Features) | [**RFC 6017**: Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field](/specs/IETF/RFC/6017 "With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality.") -[`EPR`](/concepts/http-header/EPR) | [**W3C TR http://www.w3.org/TR/epr**: Entry Point Regulation (EPR)](/specs/W3C/TR/epr "Entry Point Regulation aims to mitigate the risk of reflected cross-site scripting (XSS), cross-site script inclusion (XSSI), and cross-site request forgery (CSRF) attacks by demarcating the areas of an application which are intended to be externally referencable. A specified policy is applied on external requests for all non-demarcated resources.") -[`ETag`](/concepts/http-header/ETag) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`Expect`](/concepts/http-header/Expect) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Expect-CT`](/concepts/http-header/Expect-CT) | [**Internet Draft ietf-httpbis-expect-ct**: Expect-CT Extension for HTTP](/specs/IETF/I-D/ietf-httpbis-expect-ct "This document defines a new HTTP header, named Expect-CT, that allows web host operators to instruct user agents to expect valid Signed Certificate Timestamps (SCTs) to be served on connections to these hosts. When configured in enforcement mode, user agents (UAs) will remember that hosts expect SCTs and will refuse connections that do not conform to the UA's Certificate Transparency policy. When configured in report-only mode, UAs will report the lack of valid SCTs to a URI configured by the host, but will allow the connection. By turning on Expect-CT, web host operators can discover misconfigurations in their Certificate Transparency deployments and ensure that misissued certificates accepted by UAs are discoverable in Certificate Transparency logs.") -[`Expires`](/concepts/http-header/Expires) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`Ext`](/concepts/http-header/Ext) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`Forwarded`](/concepts/http-header/Forwarded) | [**RFC 7239**: Forwarded HTTP Extension](/specs/IETF/RFC/7239 "This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.") -[`From`](/concepts/http-header/From) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`GET-Location`](/concepts/http-header/GET-Location) | [**Internet Draft reschke-http-get-location**: The Sunset HTTP Header](/specs/IETF/I-D/reschke-http-get-location "Several hypertext transfer protocol (HTTP) extensions use methods other than GET to expose information. This has the drawback that this kind of information is harder to identify (missing a URL to which a GET request could be applied) and to cache. This document specifies a simple extension header through which a server can advertise a substitute URL that an HTTP client subsequently can use with the GET method.") -[`HTTP2-Settings`](/concepts/http-header/HTTP2-Settings) | [**RFC 7540**: Hypertext Transfer Protocol Version 2](/specs/IETF/RFC/7540 "This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.") -[`HTTPS`](/concepts/http-header/HTTPS) | [**W3C TR http://www.w3.org/TR/upgrade-insecure-requests**: Upgrade Insecure Requests](/specs/W3C/TR/upgrade-insecure-requests "This document defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them.") -[`Hobareg`](/concepts/http-header/Hobareg) | [**RFC 7486**: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 "HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.") -[`Host`](/concepts/http-header/Host) | [**RFC 7230**: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.") -[`IM`](/concepts/http-header/IM) | [**RFC 3229**: Delta encoding in HTTP](/specs/IETF/RFC/3229 "This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."") -[`If`](/concepts/http-header/If) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`If-Match`](/concepts/http-header/If-Match) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`If-Modified-Since`](/concepts/http-header/If-Modified-Since) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`If-None-Match`](/concepts/http-header/If-None-Match) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`If-Range`](/concepts/http-header/If-Range) | [**RFC 7233**: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.") -[`If-Schedule-Tag-Match`](/concepts/http-header/If-Schedule-Tag-Match) | [**RFC 6638**: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 "This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.") -[`If-Unmodified-Since`](/concepts/http-header/If-Unmodified-Since) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`Key`](/concepts/http-header/Key) | [**Internet Draft ietf-httpbis-key**: The Key HTTP Response Header Field](/specs/IETF/I-D/ietf-httpbis-key "The 'Key' header field for HTTP responses allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending Accept* fields in order to reduce the risk of fingerprinting.") -[`Label`](/concepts/http-header/Label) | [**RFC 3253**: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 "This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.") -[`Last-Event-ID`](/concepts/http-header/Last-Event-ID) | [**W3C TR http://www.w3.org/TR/eventsource**: Server-Sent Events](/specs/W3C/TR/eventsource " specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.") -[`Last-Modified`](/concepts/http-header/Last-Modified) | [**RFC 7232**: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.") -[`Link`](/concepts/http-header/Link)2 | [**Internet Draft nottingham-rfc5988bis**: Web Linking](/specs/IETF/I-D/nottingham-rfc5988bis "This specification defines a way to indicate the relationships between resources on the Web ("links") and the type of those relationships ("link relation types"). It also defines the use of such links in HTTP headers with the Link header field.")
[**RFC 5988**: Web Linking](/specs/IETF/RFC/5988 "This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.") -[`Link-Template`](/concepts/http-header/Link-Template) | [**Internet Draft nottingham-link-template**: The Link-Template HTTP Header Field](/specs/IETF/I-D/nottingham-link-template "This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated.") -[`Location`](/concepts/http-header/Location) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Lock-Token`](/concepts/http-header/Lock-Token) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`MIME-Version`](/concepts/http-header/MIME-Version) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Man`](/concepts/http-header/Man) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`Max-Forwards`](/concepts/http-header/Max-Forwards) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Memento-Datetime`](/concepts/http-header/Memento-Datetime) | [**RFC 7089**: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 "The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.") -[`Negotiate`](/concepts/http-header/Negotiate) | [**RFC 2295**: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 "HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.") -[`Nice`](/concepts/http-header/Nice) | [**Internet Draft thomson-http-nice**: Marking HTTP Requests as Unimportant](/specs/IETF/I-D/thomson-http-nice "An HTTP "Nice" header field is defined that marks a request as low priority. Intermediaries can choose to discard the request or serve it from cache rather than forwarding it to an origin server. This enables constrained origin servers, such as those that rely on battery power, to avoid expending limited resources on serving requests.") -[`OData-EntityId`](/concepts/http-header/OData-EntityId) | [**OASIS Standard odata-v4.0-part1-protocol**: OData Version 4.0 Part 1: Protocol](/specs/OASIS/standard/odata-v4.0-part1-protocol "The Open Data Protocol (OData) enables the creation of REST-based data services, which allow resources, identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages. This specification defines the core semantics and the behavioral aspects of the protocol.") -[`OData-Isolation`](/concepts/http-header/OData-Isolation) | [**OASIS Standard odata-v4.0-part1-protocol**: OData Version 4.0 Part 1: Protocol](/specs/OASIS/standard/odata-v4.0-part1-protocol "The Open Data Protocol (OData) enables the creation of REST-based data services, which allow resources, identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages. This specification defines the core semantics and the behavioral aspects of the protocol.") -[`OData-MaxVersion`](/concepts/http-header/OData-MaxVersion) | [**OASIS Standard odata-v4.0-part1-protocol**: OData Version 4.0 Part 1: Protocol](/specs/OASIS/standard/odata-v4.0-part1-protocol "The Open Data Protocol (OData) enables the creation of REST-based data services, which allow resources, identified using Uniform Resource Locators (URLs) and defined in a data model, to be published and edited by Web clients using simple HTTP messages. This specification defines the core semantics and the behavioral aspects of the protocol.") -[`Opt`](/concepts/http-header/Opt) | [**RFC 2774**: An HTTP Extension Framework](/specs/IETF/RFC/2774 "A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.") -[`Optional-WWW-Authenticate`](/concepts/http-header/Optional-WWW-Authenticate) | [**RFC 8053**: HTTP Authentication Extensions for Interactive Clients](/specs/IETF/RFC/8053 "This document specifies extensions for the HTTP authentication framework for interactive clients. Currently, fundamental features of HTTP-level authentication are insufficient for complex requirements of various Web-based applications. This forces these applications to implement their own authentication frameworks by means such as HTML forms, which becomes one of the hurdles against introducing secure authentication mechanisms handled jointly by servers and user agents. The extended framework fills gaps between Web application requirements and HTTP authentication provisions to solve the above problems, while maintaining compatibility with existing Web and non-Web uses of HTTP authentication.") -[`Ordering-Type`](/concepts/http-header/Ordering-Type) | [**RFC 3648**: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol](/specs/IETF/RFC/3648 "This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.") -[`Origin`](/concepts/http-header/Origin) | [**W3C TR http://www.w3.org/TR/cors**: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors "This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.") -[`Origin-Cookie`](/concepts/http-header/Origin-Cookie) | [**Internet Draft west-origin-cookies**: Origin Cookies](/specs/IETF/I-D/west-origin-cookies "This document updates RFC 6265, defining the "origin" attribute for cookies and the "Origin-Cookie" header field, which together allow servers to choose to harmonize the security policy of their cookies with the same-origin policy which governs other available client-side storage mechanisms.") -[`Overwrite`](/concepts/http-header/Overwrite) | [**RFC 4918**: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 "Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).") -[`P3P`](/concepts/http-header/P3P) | [**W3C TR http://www.w3.org/TR/P3P**: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification](/specs/W3C/TR/P3P "This is the specification of the Platform for Privacy Preferences (P3P). This document, along with its normative references, includes all the specification necessary for the implementation of interoperable P3P applications.") -[`PEP`](/concepts/http-header/PEP) | [**W3C TR http://www.w3.org/TR/WD-http-pep**: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep " HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.") -[`PEP-Info`](/concepts/http-header/PEP-Info) | [**W3C TR http://www.w3.org/TR/WD-http-pep**: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep " HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.") -[`POE`](/concepts/http-header/POE) | [**Internet Draft nottingham-http-poe**: POST Once Exactly (POE)](/specs/IETF/I-D/nottingham-http-poe "This specification describes a pattern of use that allows HTTP clients to automatically retry POST requests in a manner that assures no unintended side effects will take place, and defines mechanisms to allow implementations to automatically determine when such patterns are supported.") -[`POE-Links`](/concepts/http-header/POE-Links) | [**Internet Draft nottingham-http-poe**: POST Once Exactly (POE)](/specs/IETF/I-D/nottingham-http-poe "This specification describes a pattern of use that allows HTTP clients to automatically retry POST requests in a manner that assures no unintended side effects will take place, and defines mechanisms to allow implementations to automatically determine when such patterns are supported.") -[`Position`](/concepts/http-header/Position) | [**RFC 3648**: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol](/specs/IETF/RFC/3648 "This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.") -[`Pragma`](/concepts/http-header/Pragma) | [**RFC 7234**: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.") -[`Prefer`](/concepts/http-header/Prefer) | [**RFC 7240**: Prefer Header for HTTP](/specs/IETF/RFC/7240 "This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.") -[`Preference-Applied`](/concepts/http-header/Preference-Applied) | [**RFC 7240**: Prefer Header for HTTP](/specs/IETF/RFC/7240 "This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.") -[`Proxy-Authenticate`](/concepts/http-header/Proxy-Authenticate) | [**RFC 7235**: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.") -[`Proxy-Authentication-Info`](/concepts/http-header/Proxy-Authentication-Info) | [**RFC 7615**: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields](/specs/IETF/RFC/7615 "This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted.") -[`Proxy-Authorization`](/concepts/http-header/Proxy-Authorization) | [**RFC 7235**: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.") -[`Proxy-Features`](/concepts/http-header/Proxy-Features) | [**W3C TR http://www.w3.org/TR/WD-proxy**: Notification for Proxy Caches](/specs/W3C/TR/WD-proxy "A mechanism to enable better functioning of proxies is proposed. This mechanism allows proxies to inform a remote server about transactions performed using the cache and for servers to inform proxies when data becomes stale.") -[`Proxy-Instruction`](/concepts/http-header/Proxy-Instruction) | [**W3C TR http://www.w3.org/TR/WD-proxy**: Notification for Proxy Caches](/specs/W3C/TR/WD-proxy "A mechanism to enable better functioning of proxies is proposed. This mechanism allows proxies to inform a remote server about transactions performed using the cache and for servers to inform proxies when data becomes stale.") -[`Public`](/concepts/http-header/Public) | [**RFC 2068**: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".") -[`Public-Key-Pins`](/concepts/http-header/Public-Key-Pins) | [**RFC 7469**: Public Key Pinning Extension for HTTP](/specs/IETF/RFC/7469 "This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.") -[`Public-Key-Pins-Report-Only`](/concepts/http-header/Public-Key-Pins-Report-Only) | [**RFC 7469**: Public Key Pinning Extension for HTTP](/specs/IETF/RFC/7469 "This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.") -[`Push-Policy`](/concepts/http-header/Push-Policy) | [**Internet Draft ruellan-http-accept-push-policy**: Accept-Push-Policy Header Field](/specs/IETF/I-D/ruellan-http-accept-push-policy "The "Accept-Push-Policy" and "Push-Policy" header fields enable a client and a server to negotiate the behaviour of the server regarding the usage of push on a per-request basis.") -[`Range`](/concepts/http-header/Range) | [**RFC 7233**: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.") -[`Redirect-Ref`](/concepts/http-header/Redirect-Ref) | [**RFC 4437**: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 "This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.") -[`Referer`](/concepts/http-header/Referer) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`Report-To`](/concepts/http-header/Report-To) | [**W3C TR http://www.w3.org/TR/reporting-1**: Reporting API 1](/specs/W3C/TR/reporting-1 "This document defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner.") -[`Retry-After`](/concepts/http-header/Retry-After) | [**RFC 7231**: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 "The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.") -[`SOAPAction`](/concepts/http-header/SOAPAction) | [**W3C TR http://www.w3.org/TR/SOAP**: Simple Object Access Protocol (SOAP) 1.1](/specs/W3C/TR/SOAP "SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.") -[`Safe`](/concepts/http-header/Safe) | [**RFC 2310**: The Safe Response Header Field](/specs/IETF/RFC/2310 "This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.") -[`Save-Data`](/concepts/http-header/Save-Data) | [**Internet Draft ietf-httpbis-client-hints**: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints "An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.") -[`Schedule-Reply`](/concepts/http-header/Schedule-Reply) | [**RFC 6638**: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 "This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.") -[`Schedule-Tag`](/concepts/http-header/Schedule-Tag) | [**RFC 6638**: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 "This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.") -[`Sec-COWL`](/concepts/http-header/Sec-COWL) | [**W3C TR http://www.w3.org/TR/COWL**: Confinement with Origin Web Labels](/specs/W3C/TR/COWL "This specification defines an API for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining code according to such policies. This allows Web application authors and server operators to share data with untrusted—buggy but not malicious—code (e.g., in a mashup scenario) yet impose restrictions on how the code can share the data further.") -[`Sec-WebSocket-Accept`](/concepts/http-header/Sec-WebSocket-Accept) | [**RFC 6455**: The WebSocket Protocol](/specs/IETF/RFC/6455 "The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or