{ "concept" : "http-header", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "name-singular" : "HTTP Header Field", "name-plural" : "HTTP Header Fields", "registry" : "http:\/\/www.iana.org\/assignments\/message-headers\/message-headers.xhtml", "values" : [ { "value" : "A-IM", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/A-IM", "details" : [ { "description" : "The A-IM request-header field is similar to Accept, but restricts the instance-manipulations that are acceptable in the response. A response may be the result of applying multiple instance-manipulations. When an A-IM request-header field includes one or more delta-coding values, the request MUST contain an If-None-Match header field, listing one or more entity tags from prior responses for the request-URI.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3229#section-10.5.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3229", "spec-name" : "RFC 3229" } ] }, { "value" : "ALPN", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/ALPN", "details" : [ { "description" : "Clients include the ALPN header field in an HTTP CONNECT request to indicate the application-layer protocol that a client intends to use within the tunnel, or a set of protocols that might be used within the tunnel.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7639#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7639", "spec-name" : "RFC 7639" } ] }, { "value" : "Accept", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept", "details" : [ { "description" : "The \"Accept\" header field can be used by user agents to specify response media types that are acceptable. Accept header fields can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Accept-Additions", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Additions", "details" : [ { "description" : "In HTTP, the \"Accept\" request-header field is used to specify media types which are acceptable for the response. However, in HTCPCP, the response may result in additional actions on the part of the automated pot. For this reason, HTCPCP adds a new header field, \"Accept-Additions\".", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2324#section-2.2.2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2324", "spec-name" : "RFC 2324" }, { "description" : "It has been observed that some users of blended teas have an occasional preference for teas brewed as an emulsion of cane sugar with hints of water. To allow for this circumstance, the Accept-Additions header field defined in the base HTCPCP specification is updated to allow the following options.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7168#section-2.2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7168", "spec-name" : "RFC 7168" } ] }, { "value" : "Accept-CH", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-CH", "details" : [ { "description" : "The Accept-CH response header field or the equivalent HTML meta element with http-equiv attribute (HTML5) indicate server support for particular hints indicated in its value.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-hints#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-hints", "spec-name" : "Internet Draft ietf-httpbis-client-hints" } ] }, { "value" : "Accept-Charset", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Charset", "details" : [ { "description" : "The \"Accept-Charset\" header field can be sent by a user agent to indicate what charsets are acceptable in textual response content. This field allows user agents capable of understanding more comprehensive or special-purpose charsets to signal that capability to an origin server that is capable of representing information in those charsets.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Accept-Datetime", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Datetime", "details" : [ { "description" : "The \"Accept-Datetime\" request header is transmitted by a user agent to indicate it wants to access a past state of an Original Resource. To that end, the \"Accept-Datetime\" header is conveyed in an HTTP request issued against a TimeGate for an Original Resource, and its value indicates the datetime of the desired past state of the Original Resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7089#section-2.1.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7089", "spec-name" : "RFC 7089" } ] }, { "value" : "Accept-Encoding", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Encoding", "details" : [ { "description" : "Section 5.3.4 of RFC 7231 defines \"Accept-Encoding\" as a request header field only. This specification expands that definition to allow \"Accept-Encoding\" as a response header field as well. When present in a response, it indicates what content codings the resource was willing to accept in the associated request. A field value that only contains \"identity\" implies that no content codings were supported.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7694#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7694", "spec-name" : "RFC 7694" }, { "description" : "The \"Accept-Encoding\" header field can be used by user agents to indicate what response content-codings are acceptable in the response. An \"identity\" token is used as a synonym for \"no encoding\" in order to communicate when no encoding is preferred.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Accept-Features", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Features", "details" : [ { "description" : "The Accept-Features request header can be used by a user agent to give information about the presence or absence of certain features in the feature set of the current request. Servers can use this information when running a remote variant selection algorithm.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295", "spec-name" : "RFC 2295" } ] }, { "value" : "Accept-Indefinite-Ranges", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Indefinite-Ranges", "details" : [ { "description" : "The Accept-Indefinite-Ranges request-header field allows the client to indicate its acceptance of indefinite-sized range requests for a resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-combs-http-indeterminate-range#section-2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/combs-http-indeterminate-range", "spec-name" : "Internet Draft combs-http-indeterminate-range" } ] }, { "value" : "Accept-Language", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Language", "details" : [ { "description" : "The \"Accept-Language\" header field can be used by user agents to indicate the set of natural languages that are preferred in the response.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.3.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Accept-Patch", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Patch", "details" : [ { "description" : "This specification introduces a new response header Accept-Patch used to specify the patch document formats accepted by the server. Accept-Patch SHOULD appear in the OPTIONS response for any resource that supports the use of the PATCH method. The presence of the Accept-Patch header in response to any method is an implicit indication that PATCH is allowed on the resource identified by the Request-URI.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5789#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5789", "spec-name" : "RFC 5789" } ] }, { "value" : "Accept-Post", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Post", "details" : [ { "description" : "The Accept-Post HTTP header SHOULD appear in the OPTIONS response for any resource that supports the use of the POST method. The presence of the Accept-Post header in response to any method is an implicit indication that POST is allowed on the resource identified by the Request-URI. The presence of a specific document format in this header indicates that that specific format is allowed on POST requests to the resource identified by the Request-URI.", "documentation" : "http:\/\/www.w3.org\/TR\/ldp\/#header-accept-post", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/ldp", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/ldp" } ] }, { "value" : "Accept-Profile", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Profile", "details" : [ { "description" : "In order to allow a user agent to inform a server about its preferences regarding profiles for resource representations, the \"Accept-Profile\" HTTP header used. A user agent can specify several profiles and use quality indicators (q-values) to indicate preferences.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-svensson-profiled-representations#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/svensson-profiled-representations", "spec-name" : "Internet Draft svensson-profiled-representations" } ] }, { "value" : "Accept-Push-Policy", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Push-Policy", "details" : [ { "description" : "A client can express the desired push policy for a request by sending an \"Accept-Push-Policy\" header field in the request. The header field value contains the push policy that the client expects the server to use when processing the request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ruellan-http-accept-push-policy#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ruellan-http-accept-push-policy", "spec-name" : "Internet Draft ruellan-http-accept-push-policy" } ] }, { "value" : "Accept-Query", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Query", "details" : [ { "description" : "The \"Accept-Query\" response header field MAY be used by a server to directly signal support for the QUERY method while identifying the specific query format media type(s) that may be used.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-safe-method-w-body#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-safe-method-w-body", "spec-name" : "Internet Draft ietf-httpbis-safe-method-w-body" } ] }, { "value" : "Accept-Ranges", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Accept-Ranges", "details" : [ { "description" : "The \"Accept-Ranges\" header field allows a server to indicate that it supports range requests for the target resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7233#section-2.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7233", "spec-name" : "RFC 7233" } ] }, { "value" : "Access-Control-Allow-Credentials", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Credentials", "details" : [ { "description" : "The Access-Control-Allow-Credentials header indicates whether the response to request can be exposed when the omit credentials flag is unset. When part of the response to a preflight request it indicates that the actual request can include user credentials.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-credentials-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Allow-Headers", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Headers", "details" : [ { "description" : "The Access-Control-Allow-Headers header indicates, as part of the response to a preflight request, which header field names can be used during the actual request.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-headers-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Allow-Methods", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Methods", "details" : [ { "description" : "The Access-Control-Allow-Methods header indicates, as part of the response to a preflight request, which methods can be used during the actual request.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-methods-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Allow-Origin", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Allow-Origin", "details" : [ { "description" : "The Access-Control-Allow-Origin header indicates whether a resource can be shared based by returning the value of the Origin request header, \"*\", or \"null\" in the response.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-allow-origin-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Expose-Headers", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Expose-Headers", "details" : [ { "description" : "The Access-Control-Expose-Headers header indicates which headers are safe to expose to the API of a CORS API specification.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-expose-headers-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Max-Age", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Max-Age", "details" : [ { "description" : "The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached in a preflight result cache.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-max-age-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Request-Headers", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Request-Headers", "details" : [ { "description" : "The Access-Control-Request-Headers header indicates which headers will be used in the actual request as part of the preflight request.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-request-headers-request-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Access-Control-Request-Method", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Access-Control-Request-Method", "details" : [ { "description" : "The Access-Control-Request-Method header indicates which method will be used in the actual request as part of the preflight request.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#access-control-request-method-request-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Age", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Age", "details" : [ { "description" : "The \"Age\" header field conveys the sender's estimate of the amount of time since the response was generated or successfully validated at the origin server.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234", "spec-name" : "RFC 7234" } ] }, { "value" : "Allow", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Allow", "details" : [ { "description" : "The \"Allow\" header field lists the set of methods advertised as supported by the target resource. The purpose of this field is strictly to inform the recipient of valid request methods associated with the resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Alt-Svc", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alt-Svc", "details" : [ { "description" : "An HTTP(S) origin server can advertise the availability of alternative services to clients by adding an Alt-Svc header field to responses.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7838#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7838", "spec-name" : "RFC 7838" } ] }, { "value" : "Alt-Used", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alt-Used", "details" : [ { "description" : "The Alt-Used header field is used in requests to indicate the identity of the alternative service in use, just as the Host header field identifies the host and port of the origin. Alt-Used is intended to allow alternative services to detect loops, differentiate traffic for purposes of load balancing, and generally to ensure that it is possible to identify the intended destination of traffic, since introducing this information after a protocol is in use has proven to be problematic.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7838#section-5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7838", "spec-name" : "RFC 7838" } ] }, { "value" : "Alternates", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Alternates", "details" : [ { "description" : "The Alternates response header is used to convey the list of variants bound to a negotiable resource. This list can also include directives for any content negotiation process. If a response from a transparently negotiable resource includes an Alternates header, this header MUST contain the complete variant list bound to the negotiable resource. Responses from resources which do not support transparent content negotiation MAY also use Alternates headers.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295", "spec-name" : "RFC 2295" } ] }, { "value" : "Apply-To-Redirect-Ref", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Apply-To-Redirect-Ref", "details" : [ { "description" : "The optional Apply-To-Redirect-Ref header can be used on any request to a redirect reference resource. When it is present and set to \"T\", the request MUST be applied to the reference resource itself, and a 3xx response MUST NOT be returned.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4437#section-12.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4437", "spec-name" : "RFC 4437" } ] }, { "value" : "Authentication-Control", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authentication-Control", "details" : [ { "description" : "The Authentication-Control header provides more precise control of the client behavior for Web applications using an HTTP authentication protocol.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8053#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8053", "spec-name" : "RFC 8053" } ] }, { "value" : "Authentication-Info", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authentication-Info", "details" : [ { "description" : "HTTP authentication schemes can use the Authentication-Info response header field to communicate information after the client's authentication credentials have been accepted. This information can include a finalization message from the server (e.g., it can contain the server authentication).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7615#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7615", "spec-name" : "RFC 7615" } ] }, { "value" : "Authorization", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Authorization", "details" : [ { "description" : "The client is expected to retry the request, passing an Authorization header field line with Digest scheme, which is defined according to the framework above. The values of the opaque and algorithm fields must be those supplied in the WWW-Authenticate response header field for the entity being requested.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7616#section-3.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7616", "spec-name" : "RFC 7616" }, { "description" : "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).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5849#section-3.5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5849", "spec-name" : "RFC 5849" }, { "description" : "The \"Authorization\" header field allows a user agent to authenticate itself with an origin server - usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7235#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7235", "spec-name" : "RFC 7235" } ] }, { "value" : "C-Ext", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Ext", "details" : [ { "description" : "The C-Ext response header field is used to indicate that all hop-by-hop mandatory extension declarations in the request were fulfilled.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "C-Man", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Man", "details" : [ { "description" : "A mandatory extension declaration indicates that the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting an error. Hop-by-hop extension declarations are meaningful only for a single HTTP connection. In HTTP\/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. That is, these header fields are to be included as Connection header field directives.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "C-Opt", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-Opt", "details" : [ { "description" : "An optional extension declaration indicates that the ultimate recipient of the extension MAY consult and adhere to the rules given by the extension when processing the message, or ignore the extension declaration completely. An agent may not be able to distinguish whether the ultimate recipient does not understand an extension referred to by an optional extension or simply ignores the extension declaration. Hop-by-hop extension declarations are meaningful only for a single HTTP connection. In HTTP\/1.1, C-Man, C-Opt, and all header fields with matching header-prefix values defined by C-Man and C-Opt MUST be protected by a Connection header field. That is, these header fields are to be included as Connection header field directives.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "C-PEP", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-PEP", "details" : [ { "description" : "PEP hop-by-hop extension declarations are meaningful only for a single transport-level connection. The C-PEP header field is a hop-by-hop header field and must not be communicated by proxies over further connections.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743948", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] }, { "value" : "C-PEP-Info", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/C-PEP-Info", "details" : [ { "description" : "PEP hop-by-hop policies are meaningful only for a single transport-level connection. The C-PEP-Info header field is a hop-by-hop header field and MUST NOT be communicated by proxies over further connections.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743954", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] }, { "value" : "CDN-Cache-Control", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/CDN-Cache-Control", "details" : [ { "description" : "The CDN-Cache-Control response header field is a targeted field that allows origin servers to control the behavior of CDN caches interposed between them and clients separately from other caches that might handle the response. It applies to caches that are part of a distributed network that operate on behalf of an origin server (commonly called a CDN).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc9213#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/9213", "spec-name" : "RFC 9213" } ] }, { "value" : "Cache-Control", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-Control", "details" : [ { "description" : "The \"Cache-Control\" header field is used to specify directives for caches along the request\/response chain. Such cache directives are unidirectional in that the presence of a directive in a request does not imply that the same directive is to be given in the response.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234", "spec-name" : "RFC 7234" } ] }, { "value" : "Cache-NT", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-NT", "details" : [ { "description" : "For precisely identifying transferred content independent of the used URL and independent of additional header fields in the context of content negotiation, the Cache-NT header field is used. The new header field carries an SHA-256 value.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-drechsler-httpbis-improved-caching#section-2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/drechsler-httpbis-improved-caching", "spec-name" : "Internet Draft drechsler-httpbis-improved-caching" } ] }, { "value" : "Cache-Status", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cache-Status", "details" : [ { "description" : "The Cache-Status HTTP response header field indicates how caches have handled that response and its corresponding request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-cache-header#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-cache-header", "spec-name" : "Internet Draft ietf-httpbis-cache-header" } ] }, { "value" : "Cal-Managed-ID", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cal-Managed-ID", "details" : [ { "description" : "The Cal-Managed-ID response header field provides the value of the MANAGED-ID parameter corresponding to a newly added ATTACH property. It MUST be sent only in response to a successful POST request with an action set to attachment-add or attachment-update.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-calext-caldav-attachments#section-5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-calext-caldav-attachments", "spec-name" : "Internet Draft ietf-calext-caldav-attachments" } ] }, { "value" : "Clear-Site-Data", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Clear-Site-Data", "details" : [ { "description" : "The Clear-Site-Data HTTP response header field sends a signal to the user agent that it ought to remove all data of a certain set of types.", "documentation" : "http:\/\/www.w3.org\/TR\/clear-site-data\/#header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/clear-site-data", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/clear-site-data" } ] }, { "value" : "Client-Cert", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Client-Cert", "details" : [ { "description" : "In the context of a TLS terminating reverse proxy deployment, the proxy makes the TLS client certificate available to the backend application with the Client-Cert HTTP header field. This field contains the end-entity certificate used by the client in the TLS handshake.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-cert-field#section-2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-cert-field", "spec-name" : "Internet Draft ietf-httpbis-client-cert-field" } ] }, { "value" : "Client-Cert-Chain", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Client-Cert-Chain", "details" : [ { "description" : "In the context of a TLS terminating reverse proxy deployment, the proxy MAY make the certificate chain used for validation of the end-entity certificate available to the backend application with the Client-Cert-Chain HTTP header field. This field contains certificates used by the proxy to validate the certificate used by the client in the TLS handshake. These certificates might or might not have been provided by the client during the TLS handshake.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-client-cert-field#section-2.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-client-cert-field", "spec-name" : "Internet Draft ietf-httpbis-client-cert-field" } ] }, { "value" : "Close", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Close", "details" : [ { "description" : "The header field-name \"Close\" has been registered as \"reserved\", since using that name as an HTTP header field might conflict with the \"close\" connection option of the Connection header field.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-8.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230", "spec-name" : "RFC 7230" } ] }, { "value" : "Connection", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Connection", "details" : [ { "description" : "The \"Connection\" header field allows the sender to indicate desired control options for the current connection. In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-6.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230", "spec-name" : "RFC 7230" } ] }, { "value" : "Content-Base", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Base", "details" : [ { "description" : "The Content-Base entity-header field may be used to specify the base URI for resolving relative URLs within the entity. This header field is described as Base in RFC 1808, which is expected to be revised.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2068#section-14.11", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2068", "spec-name" : "RFC 2068" } ] }, { "value" : "Content-Digest", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Digest", "details" : [ { "description" : "The Content-Digest HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the actual message content.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-digest-headers#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-digest-headers", "spec-name" : "Internet Draft ietf-httpbis-digest-headers" } ] }, { "value" : "Content-Disposition", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Disposition", "details" : [ { "description" : "The Content-Disposition response header field is used to convey additional information about how to process the response payload, and also can be used to attach additional metadata, such as the filename to use when saving the response payload locally.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6266#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6266", "spec-name" : "RFC 6266" } ] }, { "value" : "Content-Encoding", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Encoding", "details" : [ { "description" : "The \"Content-Encoding\" header field indicates what content codings have been applied to the representation, beyond those inherent in the media type, and thus what decoding mechanisms have to be applied in order to obtain data in the media type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a representation's data to be compressed without losing the identity of its underlying media type.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-3.1.2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Content-Language", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Language", "details" : [ { "description" : "The \"Content-Language\" header field describes the natural language(s) of the intended audience for the representation. Note that this might not be equivalent to all the languages used within the representation.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-3.1.3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Content-Length", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Length", "details" : [ { "description" : "When a message does not have a Transfer-Encoding header field, a Content-Length header field can provide the anticipated size, as a decimal number of octets, for a potential payload body. For messages that do include a payload body, the Content-Length field-value provides the framing information necessary for determining where the body (and message) ends. For messages that do not include a payload body, the Content-Length indicates the size of the selected representation (Section 3 of [Part2]).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-3.3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230", "spec-name" : "RFC 7230" } ] }, { "value" : "Content-Location", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Location", "details" : [ { "description" : "The \"Content-Location\" header field references a URI that can be used as an identifier for a specific resource corresponding to the representation in this message's payload. In other words, if one were to perform a GET request on this URI at the time of this message's generation, then a 200 (OK) response would contain the same representation that is enclosed as payload in this message.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-3.1.4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Content-Range", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Range", "details" : [ { "description" : "The Content-Range entity-header is sent with a partial entity-body to specify where in the full entity-body the partial body should be applied.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-combs-http-indeterminate-range#section-2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/combs-http-indeterminate-range", "spec-name" : "Internet Draft combs-http-indeterminate-range" }, { "description" : "The \"Content-Range\" header field is sent in a single part 206 (Partial Content) response to indicate the partial range of the selected representation enclosed as the message payload, sent in each part of a multipart 206 response to indicate the range enclosed within each body part, and sent in 416 (Range Not Satisfiable) responses to provide information about the selected representation.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7233#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7233", "spec-name" : "RFC 7233" } ] }, { "value" : "Content-Security-Policy", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Security-Policy", "details" : [ { "description" : "The Content-Security-Policy HTTP response header field is the preferred mechanism for delivering a policy from a server to a client.", "documentation" : "http:\/\/www.w3.org\/TR\/CSP3\/#csp-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/CSP3", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/CSP3" }, { "description" : "The Content-Security-Policy header field is the preferred mechanism for delivering a policy.", "documentation" : "http:\/\/www.w3.org\/TR\/CSP2\/#content-security-policy-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/CSP2", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/CSP2" } ] }, { "value" : "Content-Security-Policy-Pin", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Security-Policy-Pin", "details" : [ { "description" : "The Content-Security-Policy-Pin header field is the mechanism for delivering a pinned policy that the user agent MUST enforce for any resource which is not delivered with a Content-Security-Policy header (as described in the \"Pin a policy to response\" algorithm).", "documentation" : "http:\/\/www.w3.org\/TR\/csp-pinning\/#content-security-policy-pin-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/csp-pinning", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/csp-pinning" } ] }, { "value" : "Content-Security-Policy-Report-Only", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Security-Policy-Report-Only", "details" : [ { "description" : "The Content-Security-Policy-Report-Only HTTP response header field allows web developers to experiment with policies by monitoring (but not enforcing) their effects.", "documentation" : "http:\/\/www.w3.org\/TR\/CSP3\/#cspro-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/CSP3", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/CSP3" }, { "description" : "The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy.", "documentation" : "http:\/\/www.w3.org\/TR\/CSP2\/#content-security-policy-report-only-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/CSP2", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/CSP2" } ] }, { "value" : "Content-Security-Policy-Report-Only-Pin", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Security-Policy-Report-Only-Pin", "details" : [ { "description" : "The Content-Security-Policy-Report-Only-Pin header field is the mechanism for delivering a pinned policy that the user agent MUST monitor for any resource which is not delivered with a Content-Security-Policy-Report-Only header (as described in the \"Pin a policy to response\" algorithm).", "documentation" : "http:\/\/www.w3.org\/TR\/csp-pinning\/#content-security-policy-report-only-pin-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/csp-pinning", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/csp-pinning" } ] }, { "value" : "Content-Signature", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Signature", "details" : [ { "description" : "The Content-Signature header field carries a signature of the payload body of an HTTP message. This allows for content to be protected from modification.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-thomson-http-content-signature#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/thomson-http-content-signature", "spec-name" : "Internet Draft thomson-http-content-signature" } ] }, { "value" : "Content-Translation-Type", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Translation-Type", "details" : [ { "description" : "The Content-Translation-Type field can be used in the individual language message parts to identify the type of translation. Based on the value of this field and the user's preferences, a conforming email client can determine which message part to display.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8255#section-6", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8255", "spec-name" : "RFC 8255" } ] }, { "value" : "Content-Type", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Type", "details" : [ { "description" : "The \"Content-Type\" header field indicates the media type of the associated representation: either the representation enclosed in the message payload or the selected representation, as determined by the message semantics. The indicated media type defines both the data format and how that data is intended to be processed by a recipient, within the scope of the received message semantics, after any content codings indicated by Content-Encoding are decoded.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-3.1.1.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Content-Version", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Version", "details" : [ { "description" : "The Content-Version entity-header field defines the version tag associated with a rendition of an evolving entity. Together with the Derived-From field, it allows a group of people to work simultaneously on the creation of a work as an iterative process. The field should be used to allow evolution of a particular work along a single path rather than derived works or renditions in different representations.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2068#section-19.6.2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2068", "spec-name" : "RFC 2068" } ] }, { "value" : "Content-Warning", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Content-Warning", "details" : [ { "description" : "The Content-Warning header allows to return different kinds of warning information via HTTP.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-cedik-http-warning#section-8.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/cedik-http-warning", "spec-name" : "Internet Draft cedik-http-warning" } ] }, { "value" : "Cookie", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cookie", "details" : [ { "description" : "The user agent sends stored cookies to the origin server in the Cookie header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-rfc6265bis#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-rfc6265bis", "spec-name" : "Internet Draft ietf-httpbis-rfc6265bis" }, { "description" : "The user agent sends stored cookies to the origin server in the Cookie header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6265#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6265", "spec-name" : "RFC 6265" } ] }, { "value" : "Cookie2", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Cookie2", "details" : [ { "description" : "The Cookie2 request header facilitates interoperation between clients and servers that understand different versions of the cookie specification.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2965#section-3.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2965", "spec-name" : "RFC 2965" } ] }, { "value" : "DASL", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/DASL", "details" : [ { "description" : "The DASL response header indicates server support for query grammars in the OPTIONS method. The value is a list of URIs that indicate the types of supported grammars. Note that although the URIs can be used to identify each supported search grammar, there is not necessarily a direct relationship between the URI and the XML element name that can be used in XML based SEARCH requests (the element name itself is identified by its namespace name (a URI reference) and the element's local name).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5323#section-9.1.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5323", "spec-name" : "RFC 5323" } ] }, { "value" : "DAV", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/DAV", "details" : [ { "description" : "This general-header appearing in the response indicates that the resource supports the DAV schema and protocol as specified. As a request header, this header allows the client to advertise compliance with named features when the server needs that information.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "DNT", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/DNT", "details" : [ { "description" : "The DNT header field is defined as the means for expressing a user's tracking preference via HTTP.", "documentation" : "http:\/\/www.w3.org\/TR\/tracking-dnt\/#dnt-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/tracking-dnt", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/tracking-dnt" } ] }, { "value" : "Date", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Date", "details" : [ { "description" : "The \"Date\" header field represents the date and time at which the message was originated, having the same semantics as the Origination Date Field (orig-date) defined in Section 3.6.1 of RFC 5322.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.1.1.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Delta-Base", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Delta-Base", "details" : [ { "description" : "The Delta-Base entity-header field is used in a delta-encoded response to specify the entity tag of the base instance. A Delta-Base header field MUST be included in a response with an IM header that includes a delta-coding, if the request included more than one entity tag in its If-None-Match header field. Any response with an IM header that includes a delta-coding MAY include a Delta-Base header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3229#section-10.5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3229", "spec-name" : "RFC 3229" } ] }, { "value" : "Deprecation", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Deprecation", "details" : [ { "description" : "The \"Deprecation\" HTTP response header field allows a server to communicate to a client that the URI-identified resource in context of the message is deprecated. It can also provide information that the resource is deprecated since which version.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpapi-deprecation-header#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-deprecation-header", "spec-name" : "Internet Draft ietf-httpapi-deprecation-header" } ] }, { "value" : "Depth", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Depth", "details" : [ { "description" : "The Depth request header is used with methods executed on resources that could potentially have internal members to indicate whether the method is to be applied only to the resource (\"Depth: 0\"), to the resource and its internal members only (\"Depth: 1\"), or the resource and all its members (\"Depth: infinity\").", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "Destination", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Destination", "details" : [ { "description" : "The Destination request header specifies the URI that identifies a destination resource for methods such as COPY and MOVE, which take two URIs as parameters.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "Device-Memory", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Device-Memory", "details" : [ { "description" : "The Device Memory header field is a number that indicates the client's device memory i.e. approximate amount of ram in GiB.", "documentation" : "http:\/\/www.w3.org\/TR\/device-memory-1\/#sec-device-memory-client-hint-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/device-memory-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/device-memory-1" } ] }, { "value" : "Digest", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Digest", "details" : [ { "description" : "The Digest message header field provides a message digest of the instance described by the message.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3230#section-4.3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3230", "spec-name" : "RFC 3230" } ] }, { "value" : "EDIINT-Features", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/EDIINT-Features", "details" : [ { "description" : "The EDIINT-Features header field indicates the originating user agent is capable of supporting the features listed.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6017#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6017", "spec-name" : "RFC 6017" } ] }, { "value" : "EPR", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/EPR", "details" : [ { "description" : "Servers may request the protections outlined by Entry Point Regulation (EPR) by sending an EPR HTTP response header field along with a response.", "documentation" : "http:\/\/www.w3.org\/TR\/epr\/#epr-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/epr", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/epr" } ] }, { "value" : "ETag", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/ETag", "details" : [ { "description" : "The \"ETag\" header field in a response provides the current entity-tag for the selected representation, as determined at the conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the same time, or both.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-2.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "Early-Data", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Early-Data", "details" : [ { "description" : "The Early-Data request header field indicates that the request has been conveyed in early data and that a client understands the 425 (Too Early) status code.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8470#section-5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8470", "spec-name" : "RFC 8470" } ] }, { "value" : "Expect", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Expect", "details" : [ { "description" : "The \"Expect\" header field in a request indicates a certain set of behaviors (expectations) that need to be supported by the server in order to properly handle this request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.1.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Expect-CT", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Expect-CT", "details" : [ { "description" : "The Expect-CT response header field is a new field defined in this specification. It is used by a server to indicate that UAs should evaluate connections to the host emitting the header field for CT compliance.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc9239#section-2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/9163", "spec-name" : "RFC 9163" } ] }, { "value" : "Expires", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Expires", "details" : [ { "description" : "The \"Expires\" header field gives the date\/time after which the response is considered stale. The presence of an Expires field does not imply that the original resource will change or cease to exist at, before, or after that time.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234", "spec-name" : "RFC 7234" } ] }, { "value" : "Ext", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Ext", "details" : [ { "description" : "The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "Feature-Policy", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Feature-Policy", "details" : [ { "description" : "The Feature-Policy HTTP header field can be used in the response (server to client) to communicate the feature policy that should be enforced by the client.", "documentation" : "http:\/\/www.w3.org\/TR\/feature-policy-1\/#feature-policy-http-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/feature-policy-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/feature-policy-1" } ] }, { "value" : "Forwarded", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Forwarded", "details" : [ { "description" : "The \"Forwarded\" HTTP header field is an OPTIONAL header field that, when used, contains a list of parameter-identifier pairs that disclose information that is altered or lost when a proxy is involved in the path of the request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7239#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7239", "spec-name" : "RFC 7239" } ] }, { "value" : "From", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/From", "details" : [ { "description" : "The \"From\" header field contains an Internet email address for a human user who controls the requesting user agent.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "GET-Location", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/GET-Location", "details" : [ { "description" : "The GET-Location entity header identifies a substitute resource that can be used in subsequent requests for the same information, but using the GET method.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-reschke-http-get-location#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/reschke-http-get-location", "spec-name" : "Internet Draft reschke-http-get-location" } ] }, { "value" : "HTTP2-Settings", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/HTTP2-Settings", "details" : [ { "description" : "A request that upgrades from HTTP\/1.1 to HTTP\/2 MUST include exactly one \"HTTP2-Settings\" header field. The \"HTTP2-Settings\" header field is a connection-specific header field that includes parameters that govern the HTTP\/2 connection, provided in anticipation of the server accepting the request to upgrade.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7540#section-3.2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7540", "spec-name" : "RFC 7540" } ] }, { "value" : "Hobareg", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Hobareg", "details" : [ { "description" : "The server MUST add a header field to the response message when the registration has succeeded in order to indicate the new state. The header to be used is \"Hobareg\", and the value when registration has succeeded is to be \"regok\". When registration is in an intermediate state (e.g., on an HTTP response for an interstitial page), the server MAY add this header with a value of \"reginwork\".", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7486#section-6.1.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7486", "spec-name" : "RFC 7486" } ] }, { "value" : "Host", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Host", "details" : [ { "description" : "The \"Host\" header field in a request provides the host and port information from the target URI, enabling the origin server to distinguish among resources while servicing requests for multiple host names on a single IP address.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-5.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230", "spec-name" : "RFC 7230" } ] }, { "value" : "IM", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/IM", "details" : [ { "description" : "The IM response-header field is used to indicate the instance-manipulations, if any, that have been applied to the instance represented by the response. Typical instance manipulations include delta encoding and compression.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3229#section-10.5.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3229", "spec-name" : "RFC 3229" } ] }, { "value" : "Idempotency-Key", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Idempotency-Key", "details" : [ { "description" : "An idempotency key is a unique value generated by the client which the resource server uses to recognize subsequent retries of the same request. The \"Idempotency-Key\" HTTP request header field carries this key.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpapi-idempotency-key-header-00#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-idempotency-key-header", "spec-name" : "Internet Draft ietf-httpapi-idempotency-key-header" } ] }, { "value" : "If", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If", "details" : [ { "description" : "The If request header is intended to have similar functionality to the If-Match header defined in Section 14.24 of RFC 2616. However, the If header handles any state token as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "If-Match", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-Match", "details" : [ { "description" : "The \"If-Match\" header field makes the request method conditional on the recipient origin server either having at least one current representation of the target resource, when the field-value is \"*\", or having a current representation of the target resource that has an entity-tag matching a member of the list of entity-tags provided in the field-value.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "If-Modified-Since", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-Modified-Since", "details" : [ { "description" : "The \"If-Modified-Since\" header field makes a GET or HEAD request method conditional on the selected representation's modification date being more recent than the date provided in the field-value. Transfer of the selected representation's data is avoided if that data has not changed.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-3.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "If-None-Match", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-None-Match", "details" : [ { "description" : "The \"If-None-Match\" header field makes the request method conditional on a recipient cache or origin server either not having any current representation of the target resource, when the field-value is \"*\", or having a selected representation with an entity-tag that does not match any of those listed in the field-value.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "If-Range", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-Range", "details" : [ { "description" : "If a client has a partial copy of a representation and wishes to have an up-to-date copy of the entire representation, it could use the Range header field with a conditional GET (using either or both of If-Unmodified-Since and If-Match.) However, if the precondition fails because the representation has been modified, the client would then have to make a second request to obtain the entire current representation. The \"If-Range\" header field allows a client to \"short-circuit\" the second request. Informally, its meaning is: if the representation is unchanged, send me the part(s) that I am requesting in Range; otherwise, send me the entire representation.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7233#section-3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7233", "spec-name" : "RFC 7233" } ] }, { "value" : "If-Schedule-Tag-Match", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-Schedule-Tag-Match", "details" : [ { "description" : "The If-Schedule-Tag-Match request header field is used with a method to make it conditional. Clients can set this header to the value returned in the Schedule-Tag response header, or the CALDAV:schedule-tag property, of a scheduling object resource previously retrieved from the server to avoid overwriting \"consequential\" changes to the scheduling object resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6638#section-8.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6638", "spec-name" : "RFC 6638" } ] }, { "value" : "If-Unmodified-Since", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/If-Unmodified-Since", "details" : [ { "description" : "The \"If-Unmodified-Since\" header field makes the request method conditional on the selected representation's last modification date being earlier than or equal to the date provided in the field-value. This field accomplishes the same purpose as If-Match for cases where the user agent does not have an entity-tag for the representation.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-3.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "Include-Referred-Token-Binding-ID", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Include-Referred-Token-Binding-ID", "details" : [ { "description" : "When a Token Consumer redirects the client to a Token Provider as a means to deliver the token request, it SHOULD include an Include-Referred-Token-Binding-ID HTTP response header field in its HTTP response.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8473#section-5.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8473", "spec-name" : "RFC 8473" } ] }, { "value" : "Key", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Key", "details" : [ { "description" : "The \"Key\" response header field describes the request attributes that the server has used to select the current representation. As such, its semantics are similar to the \"Vary\" response header field, but it allows more fine-grained description, using \"key modifiers\".", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-key#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-key", "spec-name" : "Internet Draft ietf-httpbis-key" } ] }, { "value" : "Label", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Label", "details" : [ { "description" : "For certain methods (e.g. GET, PROPFIND), if the request-URL identifies a version-controlled resource, a label can be specified in a Label request header to cause the method to be applied to the version selected by that label from the version history of that version-controlled resource.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3253#section-8.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3253", "spec-name" : "RFC 3253" } ] }, { "value" : "Last-Event-ID", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Last-Event-ID", "details" : [ { "description" : "The Last-Event-ID HTTP header specifies the value of the event source's last event ID string, encoded as UTF-8.", "documentation" : "http:\/\/www.w3.org\/TR\/eventsource\/#last-event-id", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/eventsource", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/eventsource" } ] }, { "value" : "Last-Modified", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Last-Modified", "details" : [ { "description" : "The \"Last-Modified\" header field in a response provides a timestamp indicating the date and time at which the origin server believes the selected representation was last modified, as determined at the conclusion of handling the request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7232#section-2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7232", "spec-name" : "RFC 7232" } ] }, { "value" : "Link", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Link", "details" : [ { "description" : "The Link header field provides a means for serialising one or more links into HTTP headers.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8288#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8288", "spec-name" : "RFC 8288" } ] }, { "value" : "Link-Template", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Link-Template", "details" : [ { "description" : "The Link-Template header field provides a means for serialising one or more links into HTTP message metadata. It is semantically equivalent to the Link header field defined in Section 3 of \"Web Linking\", except that it uses URI Templates to convey the structure of links.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpapi-link-template#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-link-template", "spec-name" : "Internet Draft ietf-httpapi-link-template" } ] }, { "value" : "Location", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Location", "details" : [ { "description" : "The \"Location\" header field is used in some responses to refer to a specific resource in relation to the response. The type of relationship is defined by the combination of request method and status code semantics.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.1.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Lock-Token", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Lock-Token", "details" : [ { "description" : "The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "MIME-Version", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/MIME-Version", "details" : [ { "description" : "HTTP is not a MIME-compliant protocol. However, messages can include a single MIME-Version header field to indicate what version of the MIME protocol was used to construct the message. Use of the MIME-Version header field indicates that the message is in full conformance with the MIME protocol (as defined in RFC 2045). Senders are responsible for ensuring full conformance (where possible) when exporting HTTP messages to strict MIME environments.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#appendix-A.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Man", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Man", "details" : [ { "description" : "A mandatory extension declaration indicates that the ultimate recipient MUST consult and adhere to the rules given by the extension when processing the message or reporting an error.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "Max-Forwards", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Max-Forwards", "details" : [ { "description" : "The \"Max-Forwards\" header field provides a mechanism with the TRACE and OPTIONS request methods to limit the number of times that the request is forwarded by proxies.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.1.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Memento-Datetime", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Memento-Datetime", "details" : [ { "description" : "The \"Memento-Datetime\" response header is used by a server to indicate that a response reflects a prior state of an Original Resource. Its value expresses the datetime of that state.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7089#section-2.1.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7089", "spec-name" : "RFC 7089" } ] }, { "value" : "NEL", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/NEL", "details" : [ { "description" : "The NEL response header is used to communicate an origin's NEL policy to the user agent. The header's value is interpreted as an array of JSON objects. Each object in the array defines an NEL policy for the origin.", "documentation" : "http:\/\/www.w3.org\/TR\/network-error-logging-1\/#nel-response-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/network-error-logging-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/network-error-logging-1" } ] }, { "value" : "Negotiate", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Negotiate", "details" : [ { "description" : "The Negotiate request header can contain directives for any content negotiation process initiated by the request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295", "spec-name" : "RFC 2295" } ] }, { "value" : "Nice", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Nice", "details" : [ { "description" : "The \"Nice\" header field indicates that a request is less important than a request that doesn't bear this header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-thomson-http-nice#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/thomson-http-nice", "spec-name" : "Internet Draft thomson-http-nice" } ] }, { "value" : "OData-EntityId", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/OData-EntityId", "details" : [ { "description" : "A response to a create or upsert operation that returns 204 No Content MUST include an OData-EntityId response header. The value of the header is the entity-id of the entity that was acted on by the request.", "documentation" : "http:\/\/docs.oasis-open.org\/odata\/odata\/v4.0\/errata03\/os\/complete\/part1-protocol\/odata-v4.0-errata03-os-part1-protocol-complete.html#_Toc453752238", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/odata-v4.0-part1-protocol", "spec-name" : "OASIS Standard odata-v4.0-part1-protocol" } ] }, { "value" : "OData-Isolation", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/OData-Isolation", "details" : [ { "description" : "The OData-Isolation header specifies the isolation of the current request from external changes. The only supported value for this header is snapshot.", "documentation" : "http:\/\/docs.oasis-open.org\/odata\/odata\/v4.0\/errata03\/os\/complete\/part1-protocol\/odata-v4.0-errata03-os-part1-protocol-complete.html#_Toc453752232", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/odata-v4.0-part1-protocol", "spec-name" : "OASIS Standard odata-v4.0-part1-protocol" } ] }, { "value" : "OData-MaxVersion", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/OData-MaxVersion", "details" : [ { "description" : "Clients SHOULD specify an OData-MaxVersion request header. If specified the service MUST generate a response with an OData-Version less than or equal to the specified OData-MaxVersion.", "documentation" : "http:\/\/docs.oasis-open.org\/odata\/odata\/v4.0\/errata03\/os\/complete\/part1-protocol\/odata-v4.0-errata03-os-part1-protocol-complete.html#_Toc453752233", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/odata-v4.0-part1-protocol", "spec-name" : "OASIS Standard odata-v4.0-part1-protocol" } ] }, { "value" : "OSCORE", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/OSCORE", "details" : [ { "description" : "The HTTP OSCORE header field (see Section 13.4) is used for carrying the content of the CoAP OSCORE option when transporting OSCORE messages over HTTP hops.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8613#section-11.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8613", "spec-name" : "RFC 8613" } ] }, { "value" : "Opt", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Opt", "details" : [ { "description" : "An optional extension declaration indicates that the ultimate recipient of the extension MAY consult and adhere to the rules given by the extension when processing the message, or ignore the extension declaration completely. An agent may not be able to distinguish whether the ultimate recipient does not understand an extension referred to by an optional extension or simply ignores the extension declaration.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2774#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2774", "spec-name" : "RFC 2774" } ] }, { "value" : "Optional-WWW-Authenticate", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Optional-WWW-Authenticate", "details" : [ { "description" : "The Optional-WWW-Authenticate header enables a non-mandatory authentication, which is not possible under the current HTTP authentication mechanism.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8053#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8053", "spec-name" : "RFC 8053" } ] }, { "value" : "Ordering-Type", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Ordering-Type", "details" : [ { "description" : "When a collection is created, the client MAY request that it be ordered and specify the semantics of the ordering by using the new Ordering-Type header with a MKCOL request. For collections that are ordered, the client SHOULD identify the semantics of the ordering with a URI in the Ordering-Type header, although the client MAY simply set the header value to DAV:custom to indicate that the collection is ordered but the semantics of the ordering are not being advertised.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3648#section-5.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3648", "spec-name" : "RFC 3648" } ] }, { "value" : "Origin", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Origin", "details" : [ { "description" : "The Origin header indicates where the cross-origin request or preflight request originates from.", "documentation" : "http:\/\/www.w3.org\/TR\/cors\/#origin-request-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/cors", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/cors" } ] }, { "value" : "Origin-Cookie", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Origin-Cookie", "details" : [ { "description" : "The user agent includes stored cookies whose \"origin-flag\" is set in the \"Origin-Cookie\" request header. When the user agent generates an HTTP request, it MUST NOT attach more than one \"Origin-Cookie\" header field.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-west-origin-cookies#section-4.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/west-origin-cookies", "spec-name" : "Internet Draft west-origin-cookies" } ] }, { "value" : "Overwrite", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Overwrite", "details" : [ { "description" : "The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.6", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "P3P", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/P3P", "details" : [ { "description" : "Any document retrieved by HTTP may point to a policy reference file through the use of a new response header, the P3P header. If a site is using P3P headers, it SHOULD include this on responses for all appropriate request methods, including HEAD and OPTIONS requests. The P3P header gives one or more comma-separated directives.", "documentation" : "http:\/\/www.w3.org\/TR\/P3P\/#syntax_ext", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/P3P", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/P3P" } ] }, { "value" : "PEP", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/PEP", "details" : [ { "description" : "PEP end-to-end declarations must be transmitted to the ultimate recipient of the declaration. The PEP header field is an end-to-end header field.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743947", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] }, { "value" : "PEP-Info", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/PEP-Info", "details" : [ { "description" : "PEP end-to-end policies MUST be transmitted to the ultimate recipient of a message.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-http-pep-971121.html#_Toc404743953", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-http-pep", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-http-pep" } ] }, { "value" : "POE", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/POE", "details" : [ { "description" : "The POE HTTP header is a request-header field whose field-value indicates the version of POE that a client supports.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-nottingham-http-poe-00#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/nottingham-http-poe", "spec-name" : "Internet Draft nottingham-http-poe" } ] }, { "value" : "POE-Links", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/POE-Links", "details" : [ { "description" : "The POE-Links HTTP header is an entity-header field whose field-value is a comma-separated list of quoted URI-references (without fragment identifiers) that the origin server asserts to be POE resources. The contents of the POE-Links response header SHOULD correspond to links found in the content of the response body.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-nottingham-http-poe-00#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/nottingham-http-poe", "spec-name" : "Internet Draft nottingham-http-poe" } ] }, { "value" : "Position", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Position", "details" : [ { "description" : "When a new member is added to a collection with a client-maintained ordering (for example, with PUT, COPY, or MKCOL), its position in the ordering can be set with the new Position header. The Position header allows the client to specify that an internal member URI should be first in the collection's ordering, last in the collection's ordering, immediately before some other internal member URI in the collection's ordering, or immediately after some other internal member URI in the collection's ordering.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc3648#section-6.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/3648", "spec-name" : "RFC 3648" } ] }, { "value" : "Pragma", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Pragma", "details" : [ { "description" : "The \"Pragma\" header field allows backwards compatibility with HTTP\/1.0 caches, so that clients can specify a \"no-cache\" request that they will understand (as Cache-Control was not defined until HTTP\/1.1). When the Cache-Control header field is also present and understood in a request, Pragma is ignored.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7234#section-5.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7234", "spec-name" : "RFC 7234" } ] }, { "value" : "Prefer", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Prefer", "details" : [ { "description" : "The Prefer request header field is used to indicate that particular server behaviors are preferred by the client, but not required for successful completion of the request. Prefer is similar in nature to the Expect header field with the exception that servers are allowed to ignore stated preferences.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7240#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7240", "spec-name" : "RFC 7240" } ] }, { "value" : "Prefer-Push", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Prefer-Push", "details" : [ { "description" : "\"Prefer-Push\" is an HTTP header field that a client may use to request that a server uses HTTP\/2 Push to send related resources as identified by their link relationships.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-pot-prefer-push#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/pot-prefer-push", "spec-name" : "Internet Draft pot-prefer-push" } ] }, { "value" : "Preference-Applied", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Preference-Applied", "details" : [ { "description" : "The Preference-Applied response header MAY be included within a response message as an indication as to which Prefer tokens were honored by the server and applied to the processing of a request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7240#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7240", "spec-name" : "RFC 7240" } ] }, { "value" : "Priority", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Priority", "details" : [ { "description" : "The Priority HTTP header field can appear in requests and responses. A client uses it to specify the priority of the response. A server uses it to inform the client that the priority was overwritten. An intermediary can use the Priority information from client requests and server responses to correct or amend the precedence to suit it. The Priority header field is an end-to-end signal of the request priority from the client or the response priority from the server.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-priority#section-5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-priority", "spec-name" : "Internet Draft ietf-httpbis-priority" } ] }, { "value" : "Proxy-Authenticate", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Authenticate", "details" : [ { "description" : "The \"Proxy-Authenticate\" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the proxy for this effective request URI. It MUST be included as part of a 407 (Proxy Authentication Required) response.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7235#section-4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7235", "spec-name" : "RFC 7235" } ] }, { "value" : "Proxy-Authentication-Info", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Authentication-Info", "details" : [ { "description" : "The Proxy-Authentication-Info response header field is equivalent to Authentication-Info, except that it applies to proxy authentication. However, unlike Authentication-Info, the Proxy-Authentication-Info header field applies only to the next outbound client on the response chain. This is because only the client that chose a given proxy is likely to have the credentials necessary for authentication.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7615#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7615", "spec-name" : "RFC 7615" } ] }, { "value" : "Proxy-Authorization", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Authorization", "details" : [ { "description" : "The \"Proxy-Authorization\" header field allows the client to identify itself (or its user) to a proxy that requires authentication. Its value consists of credentials containing the authentication information of the client for the proxy and\/or realm of the resource being requested.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7235#section-4.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7235", "spec-name" : "RFC 7235" } ] }, { "value" : "Proxy-Features", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Features", "details" : [ { "description" : "The proxy features header is used by a proxy sending data to a server. It specifies the features supported by the specified proxy.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-proxy", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-proxy", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-proxy" } ] }, { "value" : "Proxy-Instruction", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Instruction", "details" : [ { "description" : "The proxy instruction header is used to reply to a proxy features header. It should only be present when a Proxy-Features header was present in the corresponding request.", "documentation" : "http:\/\/www.w3.org\/TR\/WD-proxy", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/WD-proxy", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/WD-proxy" } ] }, { "value" : "Proxy-Status", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Proxy-Status", "details" : [ { "description" : "The Proxy-Status HTTP response field allows an intermediary to convey additional information about its handling of a response and its associated request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc9209#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/9209", "spec-name" : "RFC 9209" } ] }, { "value" : "Public", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Public", "details" : [ { "description" : "The Public response-header field lists the set of methods supported by the server. The purpose of this field is strictly to inform the recipient of the capabilities of the server regarding unusual methods. The methods listed may or may not be applicable to the Request-URI; the Allow header field MAY be used to indicate methods allowed for a particular URI.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2068#section-14.35", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2068", "spec-name" : "RFC 2068" } ] }, { "value" : "Public-Key-Pins", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Public-Key-Pins", "details" : [ { "description" : "Whenever a UA receives a Valid Pinning Header, it MUST set its Pinning Metadata to the exact Pins, Effective Expiration Date (computed from max-age), and (if any) report-uri given in the most recently received Valid Pinning Header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7469#section-2.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7469", "spec-name" : "RFC 7469" } ] }, { "value" : "Public-Key-Pins-Report-Only", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Public-Key-Pins-Report-Only", "details" : [ { "description" : "Upon receipt of a Public-Key-Pins-Report-Only response header field, the UA should evaluate the policy expressed in the field, and SHOULD generate and send a report. However, failure to validate the Pins in the field MUST have no effect on the validity or non-validity of the policy expressed in the PKP field or in previously noted Pins for the Known Pinned Host.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7469#section-2.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7469", "spec-name" : "RFC 7469" } ] }, { "value" : "Push-Policy", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Push-Policy", "details" : [ { "description" : "A server can indicate to a client the push policy it used when processing a request by sending a \"Push-Policy\" header field in the corresponding response.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ruellan-http-accept-push-policy#section-3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ruellan-http-accept-push-policy", "spec-name" : "Internet Draft ruellan-http-accept-push-policy" } ] }, { "value" : "Range", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Range", "details" : [ { "description" : "The \"Range\" header field on a GET request modifies the method semantics to request transfer of only one or more subranges of the selected representation data, rather than the entire selected representation data.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7233#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7233", "spec-name" : "RFC 7233" } ] }, { "value" : "RateLimit-Limit", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/RateLimit-Limit", "details" : [ { "description" : "The RateLimit-Limit response header field indicates the maximum number of requests that the server allocated to the client in the current time-window.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpapi-ratelimit-headers#section-3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-ratelimit-headers", "spec-name" : "Internet Draft ietf-httpapi-ratelimit-headers" } ] }, { "value" : "RateLimit-Remaining", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/RateLimit-Remaining", "details" : [ { "description" : "The RateLimit-Remaining response header field indicates the number of requests left for the client until the quota resets.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpapi-ratelimit-headers#section-3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-ratelimit-headers", "spec-name" : "Internet Draft ietf-httpapi-ratelimit-headers" } ] }, { "value" : "RateLimit-Reset", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/RateLimit-Reset", "details" : [ { "description" : "The RateLimit-Reset response header field indicates either the number of seconds until the quota resets, or the timestamp when the quota resets.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-polli-ratelimit-headers#section-3.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpapi-ratelimit-headers", "spec-name" : "Internet Draft ietf-httpapi-ratelimit-headers" } ] }, { "value" : "Redirect-Ref", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Redirect-Ref", "details" : [ { "description" : "The Redirect-Ref header is used in all 3xx responses from redirect reference resources. The value is the link target as specified during redirect reference resource creation.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4437#section-12.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4437", "spec-name" : "RFC 4437" } ] }, { "value" : "Referer", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Referer", "details" : [ { "description" : "The \"Referer\" header field allows the user agent to specify a URI reference for the resource from which the target URI was obtained (i.e., the \"referrer\", though the field name is misspelled).", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-5.5.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Repeatability-Client-ID", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Repeatability-Client-ID", "details" : [ { "description" : "Repeatability-Client-ID is an optional header that MAY be provided by the client. Repeatability-Client-ID is an opaque string representing a client-generated, globally unique for all time, identifier for the instance of the client application that issued the request.", "documentation" : "https:\/\/docs.oasis-open.org\/odata\/repeatable-requests\/v1.0\/cs01\/repeatable-requests-v1.0-cs01.html#sec_RepeatabilityClientID", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/repeatable-requests-v1.0", "spec-name" : "OASIS Standard repeatable-requests-v1.0" } ] }, { "value" : "Repeatability-First-Sent", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Repeatability-First-Sent", "details" : [ { "description" : "Repeatability-First-Sent MUST be sent by clients to specify that a request is repeatable. Repeatability-First-Sent is used to specify the date and time at which the request was first created.", "documentation" : "https:\/\/docs.oasis-open.org\/odata\/repeatable-requests\/v1.0\/cs01\/repeatable-requests-v1.0-cs01.html#sec_RepeatabilityFirstSent", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/repeatable-requests-v1.0", "spec-name" : "OASIS Standard repeatable-requests-v1.0" } ] }, { "value" : "Repeatability-Request-ID", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Repeatability-Request-ID", "details" : [ { "description" : "Repeatability-Request-ID MUST be sent by clients to specify that a request is repeatable. The value of the Repeatability-Request-ID is an opaque string representing a client-generated, globally unique for all time, identifier for the request.", "documentation" : "https:\/\/docs.oasis-open.org\/odata\/repeatable-requests\/v1.0\/cs01\/repeatable-requests-v1.0-cs01.html#sec_RepeatabilityRequestID", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/repeatable-requests-v1.0", "spec-name" : "OASIS Standard repeatable-requests-v1.0" } ] }, { "value" : "Repeatability-Result", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Repeatability-Result", "details" : [ { "description" : "Servers aware of repeatability MUST return the Repeatability-Result response header in the result of a repeatable request with one of the case-insensitive values accepted or rejected.", "documentation" : "https:\/\/docs.oasis-open.org\/odata\/repeatable-requests\/v1.0\/cs01\/repeatable-requests-v1.0-cs01.html#sec_RepeatabilityResult", "specification" : "http:\/\/webconcepts.info\/specs\/OASIS\/standard\/repeatable-requests-v1.0", "spec-name" : "OASIS Standard repeatable-requests-v1.0" } ] }, { "value" : "Report-To", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Report-To", "details" : [ { "description" : "The Report-To HTTP response header field instructs the user agent to store reporting endpoints for an origin.", "documentation" : "http:\/\/www.w3.org\/TR\/reporting-1\/#header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/reporting-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/reporting-1" } ] }, { "value" : "Repr-Digest", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Repr-Digest", "details" : [ { "description" : "The Repr-Digest HTTP field can be used in requests and responses to communicate digests that are calculated using a hashing algorithm applied to the entire selected representation data.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-digest-headers#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-digest-headers", "spec-name" : "Internet Draft ietf-httpbis-digest-headers" } ] }, { "value" : "Retry-After", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Retry-After", "details" : [ { "description" : "Servers send the \"Retry-After\" header field to indicate how long the user agent ought to wait before making a follow-up request. When sent with a 503 (Service Unavailable) response, Retry-After indicates how long the service is expected to be unavailable to the client. When sent with any 3xx (Redirection) response, Retry-After indicates the minimum time that the user agent is asked to wait before issuing the redirected request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.1.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "SOAPAction", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/SOAPAction", "details" : [ { "description" : "The SOAPAction HTTP request header field can be used to indicate the intent of the SOAP HTTP request. The value is a URI identifying the intent. SOAP places no restrictions on the format or specificity of the URI or that it is resolvable. An HTTP client MUST use this header field when issuing a SOAP HTTP Request.", "documentation" : "http:\/\/www.w3.org\/TR\/2000\/NOTE-SOAP-20000508\/#_Toc478383528", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/SOAP", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/SOAP" } ] }, { "value" : "Safe", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Safe", "details" : [ { "description" : "The Safe response header field is used by origin servers to indicate whether repeating the received HTTP request is safe in the sense of Section 9.1.1 (Safe Methods) of the HTTP\/1.1 specification. For the purpose of this specification, a HTTP request is considered to be a repetition of a previous request if both requests are issued by the same user agent, and apply to the same resource, and have the same request method, and both have no request body, or both have request bodies which are byte-wise identical after decoding of any content and transfer codings.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2310#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2310", "spec-name" : "RFC 2310" } ] }, { "value" : "Schedule-Reply", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Schedule-Reply", "details" : [ { "description" : "The Schedule-Reply request header is used by a client to indicate to a server whether or not a scheduling operation ought to occur when an \"Attendee\" deletes a scheduling object resource. In particular, it controls whether a reply scheduling message is sent to the \"Organizer\" as a result of the removal. There are situations in which unsolicited scheduling messages need to be silently removed (or ignored) for security or privacy reasons. This request header allows the scheduling object resource to be removed if such a need arises.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6638#section-8.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6638", "spec-name" : "RFC 6638" } ] }, { "value" : "Schedule-Tag", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Schedule-Tag", "details" : [ { "description" : "The Schedule-Tag response header provides the current value of the CALDAV:schedule-tag property value.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6638#section-8.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6638", "spec-name" : "RFC 6638" } ] }, { "value" : "Sec-COWL", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-COWL", "details" : [ { "description" : "The Sec-COWL HTTP request and response headers are used by user agents and servers to convey label metadata to servers and user agents, respectively.", "documentation" : "http:\/\/www.w3.org\/TR\/COWL\/#header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/COWL", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/COWL" } ] }, { "value" : "Sec-Fetch-Dest", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-Fetch-Dest", "details" : [ { "description" : "The Sec-Fetch-Dest HTTP request header exposes a request's destination to a server.", "documentation" : "http:\/\/www.w3.org\/TR\/fetch-metadata\/#sec-fetch-dest-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/fetch-metadata", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/fetch-metadata" } ] }, { "value" : "Sec-Fetch-Mode", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-Fetch-Mode", "details" : [ { "description" : "The Sec-Fetch-Mode HTTP request header exposes a request's mode to a server.", "documentation" : "http:\/\/www.w3.org\/TR\/fetch-metadata\/#sec-fetch-mode-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/fetch-metadata", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/fetch-metadata" } ] }, { "value" : "Sec-Fetch-Site", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-Fetch-Site", "details" : [ { "description" : "The Sec-Fetch-Site HTTP request header exposes the relationship between a request initiator’s origin and its target’s origin.", "documentation" : "http:\/\/www.w3.org\/TR\/fetch-metadata\/#sec-fetch-site-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/fetch-metadata", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/fetch-metadata" } ] }, { "value" : "Sec-Fetch-User", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-Fetch-User", "details" : [ { "description" : "The Sec-Fetch-User HTTP request header exposes whether or not a navigation request was triggered by user activation.", "documentation" : "http:\/\/www.w3.org\/TR\/fetch-metadata\/#sec-fetch-user-header", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/fetch-metadata", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/fetch-metadata" } ] }, { "value" : "Sec-Token-Binding", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-Token-Binding", "details" : [ { "description" : "Once a client and server have negotiated the Token Binding protocol with HTTP\/1.1 or HTTP\/2, clients MUST include a Sec-Token-Binding header field in their HTTP requests and MUST include only one such header field per HTTP request. Also, the Sec-Token-Binding header field MUST NOT be included in HTTP responses.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8473#section-2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8473", "spec-name" : "RFC 8473" } ] }, { "value" : "Sec-WebSocket-Accept", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-WebSocket-Accept", "details" : [ { "description" : "The Sec-WebSocket-Accept header field is used in the WebSocket opening handshake. It is sent from the server to the client to confirm that the server is willing to initiate the WebSocket connection.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6455#section-11.3.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6455", "spec-name" : "RFC 6455" } ] }, { "value" : "Sec-WebSocket-Extensions", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-WebSocket-Extensions", "details" : [ { "description" : "The Sec-WebSocket-Extensions header field is used in the WebSocket opening handshake. It is initially sent from the client to the server, and then subsequently sent from the server to the client, to agree on a set of protocol-level extensions to use for the duration of the connection.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6455#section-11.3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6455", "spec-name" : "RFC 6455" } ] }, { "value" : "Sec-WebSocket-Key", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-WebSocket-Key", "details" : [ { "description" : "The Sec-WebSocket-Key header field is used in the WebSocket opening handshake. It is sent from the client to the server to provide part of the information used by the server to prove that it received a valid WebSocket opening handshake.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6455#section-11.3.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6455", "spec-name" : "RFC 6455" } ] }, { "value" : "Sec-WebSocket-Protocol", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-WebSocket-Protocol", "details" : [ { "description" : "The Sec-WebSocket-Protocol header field is used in the WebSocket opening handshake. It is sent from the client to the server and back from the server to the client to confirm the subprotocol of the connection. This enables scripts to both select a subprotocol and be sure that the server agreed to serve that subprotocol.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6455#section-11.3.4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6455", "spec-name" : "RFC 6455" } ] }, { "value" : "Sec-WebSocket-Version", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sec-WebSocket-Version", "details" : [ { "description" : "The Sec-WebSocket-Version header field is used in the WebSocket opening handshake. It is sent from the client to the server to indicate the protocol version of the connection. This enables servers to correctly interpret the opening handshake and subsequent data being sent from the data, and close the connection if the server cannot interpret that data in a safe manner. The Sec-WebSocket-Version header field is also sent from the server to the client on WebSocket handshake error, when the version received from the client does not match a version understood by the server. In such a case, the header field includes the protocol version(s) supported by the server.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6455#section-11.3.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6455", "spec-name" : "RFC 6455" } ] }, { "value" : "Security-Scheme", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Security-Scheme", "details" : [ { "description" : "All S-HTTP compliant agents must generate the Security-Scheme header in the headers of all HTTP messages they generate. This header permits other agents to detect that they are communicating with an S-HTTP compliant agent and generate the appropriate cryptographic options headers.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2660#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2660", "spec-name" : "RFC 2660" } ] }, { "value" : "Server", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Server", "details" : [ { "description" : "The \"Server\" header field contains information about the software used by the origin server to handle the request, which is often used by clients to help identify the scope of reported interoperability problems, to work around or tailor requests to avoid particular server limitations, and for analytics regarding server or operating system use.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7231#section-7.4.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7231", "spec-name" : "RFC 7231" } ] }, { "value" : "Server-Timing", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Server-Timing", "details" : [ { "description" : "The Server-Timing header field is used to communicate one or more metrics and descriptions for the given request-response cycle.", "documentation" : "http:\/\/www.w3.org\/TR\/server-timing\/#the-server-timing-header-field", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/server-timing", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/server-timing" } ] }, { "value" : "Service-Worker", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Service-Worker", "details" : [ { "description" : "An HTTP request to fetch a service worker's script resource will include the Service-Worker header. It indicates that this request is a service worker's script resource request.", "documentation" : "http:\/\/www.w3.org\/TR\/service-workers-1\/#service-worker-script-request", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/service-workers-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/service-workers-1" } ] }, { "value" : "Service-Worker-Allowed", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Service-Worker-Allowed", "details" : [ { "description" : "An HTTP response to a service worker's script resource request can include the Service-Worker-Allowed header. It indicates that the user agent will override the path restriction, which limits the maximum allowed scope url that the script can control, to the given value.", "documentation" : "http:\/\/www.w3.org\/TR\/service-workers-1\/#service-worker-script-response", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/service-workers-1", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/service-workers-1" } ] }, { "value" : "Set-Cookie", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Set-Cookie", "details" : [ { "description" : "The Set-Cookie HTTP response header is used to send cookies from the server to the user agent.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-ietf-httpbis-rfc6265bis#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/ietf-httpbis-rfc6265bis", "spec-name" : "Internet Draft ietf-httpbis-rfc6265bis" }, { "description" : "The Set-Cookie HTTP response header is used to send cookies from the server to the user agent.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6265#section-4.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6265", "spec-name" : "RFC 6265" } ] }, { "value" : "Set-Cookie2", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Set-Cookie2", "details" : [ { "description" : "The origin server initiates a session, if it so desires. To do so, it returns an extra response header to the client, Set-Cookie2.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2965#section-3.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2965", "spec-name" : "RFC 2965" } ] }, { "value" : "Signature", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Signature", "details" : [ { "description" : "The \"signature\" HTTP Header is based on the model that the sender must authenticate itself with a digital signature produced by either a private asymmetric key (e.g., RSA) or a shared symmetric key (e.g., HMAC). The scheme is parameterized enough such that it is not bound to any particular key type or signing algorithm. However, it does explicitly assume that senders can send an HTTP 'Date' header.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-cavage-http-signatures#section-4", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/cavage-http-signatures", "spec-name" : "Internet Draft cavage-http-signatures" } ] }, { "value" : "Slug", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Slug", "details" : [ { "description" : "Slug is an HTTP entity-header whose presence in a POST to a Collection constitutes a request by the client to use the header's value as part of any URIs that would normally be used to retrieve the to-be-created Entry or Media Resources.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc5023#section-9.7", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/5023", "spec-name" : "RFC 5023" } ] }, { "value" : "Status-URI", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Status-URI", "details" : [ { "description" : "The Status-URI response header may be used with the 102 (Processing) status code to inform the client as to the status of a method.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2518#section-9.7", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2518", "spec-name" : "RFC 2518" } ] }, { "value" : "Strict-Transport-Security", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Strict-Transport-Security", "details" : [ { "description" : "The Strict-Transport-Security HTTP response header field (STS header field) indicates to a UA that it MUST enforce the HSTS Policy in regards to the host emitting the response message containing this header field.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc6797#section-6.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/6797", "spec-name" : "RFC 6797" } ] }, { "value" : "SubOK", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/SubOK", "details" : [ { "description" : "The SubOK request header field is used to provide directives from an end-client to a proxy cache regarding the possible substitution of an instance body from a cached response for one resource instance for the instance body of the resource instance specified by the client's request.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-mogul-http-dupsup#section-5.2.1", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/mogul-http-dupsup", "spec-name" : "Internet Draft mogul-http-dupsup" } ] }, { "value" : "Subst", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Subst", "details" : [ { "description" : "The Subst response-header field MUST be used by a proxy to supply the URI of the original source of an entity-body, if the source is different from the client's Request-URI, and if the client's request included the \"inform\" directive in a SubOK request header field.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/draft-mogul-http-dupsup#section-5.2.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/I-D\/mogul-http-dupsup", "spec-name" : "Internet Draft mogul-http-dupsup" } ] }, { "value" : "Sunset", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Sunset", "details" : [ { "description" : "The Sunset HTTP response header field allows a server to communicate the fact that a resource is expected to become unresponsive at a specific point in time. It provides information for clients which they can use to control their usage of the resource. The Sunset header contains a single timestamp which advertises the point in time when the resource is expected to become unresponsive.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8594#section-3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8594", "spec-name" : "RFC 8594" } ] }, { "value" : "Surrogate-Capability", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Surrogate-Capability", "details" : [ { "description" : "The Surrogate-Capabilities request header allows surrogates to advertise their capabilities with capability tokens. Capability tokens indicate sets of operations (e.g., caching, processing) that a surrogate is willing to perform. They follow the form of product tokens in HTTP.", "documentation" : "http:\/\/www.w3.org\/TR\/edge-arch\/", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/edge-arch", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/edge-arch" } ] }, { "value" : "Surrogate-Control", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Surrogate-Control", "details" : [ { "description" : "The Surrogate-Control response header allows origin servers to dictate how surrogates should handle response entities, with control directives. Currently defined directives control processing and cache behavior.", "documentation" : "http:\/\/www.w3.org\/TR\/edge-arch\/", "specification" : "http:\/\/webconcepts.info\/specs\/W3C\/TR\/edge-arch", "spec-name" : "W3C TR http:\/\/www.w3.org\/TR\/edge-arch" } ] }, { "value" : "TCN", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/TCN", "details" : [ { "description" : "The TCN response header is used by a server to signal that the resource is transparently negotiated.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc2295#section-8.5", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/2295", "spec-name" : "RFC 2295" } ] }, { "value" : "TE", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/TE", "details" : [ { "description" : "The \"TE\" header field in a request indicates what transfer codings, besides chunked, the client is willing to accept in response, and whether or not the client is willing to accept trailer fields in a chunked transfer coding.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc7230#section-4.3", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/7230", "spec-name" : "RFC 7230" } ] }, { "value" : "TTL", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/TTL", "details" : [ { "description" : "An application server MUST include the TTL (Time-To-Live) header field in its request for push message delivery. The TTL header field contains a value in seconds that suggests how long a push message is retained by the push service.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc8030#section-5.2", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/8030", "spec-name" : "RFC 8030" } ] }, { "value" : "Timeout", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Timeout", "details" : [ { "description" : "Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests.", "documentation" : "https:\/\/datatracker.ietf.org\/doc\/html\/rfc4918#section-10.7", "specification" : "http:\/\/webconcepts.info\/specs\/IETF\/RFC\/4918", "spec-name" : "RFC 4918" } ] }, { "value" : "Title", "concept" : "http:\/\/webconcepts.info\/concepts\/http-header\/", "id" : "http:\/\/webconcepts.info\/concepts\/http-header\/Title", "details" : [ { "description" : "The title of the document. Not part of the document. Isomorphic with the