kinlane
8/31/2016 - 7:17 AM
Web Concepts
Web Concepts
{
"HTTP Content Coding": {
"aesgcm": {
"details": "[Internet Draft ietf-httpbis-encryption-encoding: Encrypted Content-Encoding for HTTP](/specs/IETF/I-D/ietf-httpbis-encryption-encoding \"This memo introduces a content coding for HTTP that allows message payloads to be encrypted.\"):** [The \"aesgcm\" HTTP content coding indicates that a payload has been encrypted using Advanced Encryption Standard (AES) in Galois/Counter Mode (GCM) as identified as AEAD_AES_128_GCM in RFC 5116.](http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding#section-2 \"Read documentation for HTTP Content Coding "aesgcm"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/aesgcm"
},
"gzip": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".](http://tools.ietf.org/html/rfc7230#section-4.2.3 \"Read documentation for HTTP Content Coding "gzip"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/gzip"
},
"compress": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".](http://tools.ietf.org/html/rfc7230#section-4.2.1 \"Read documentation for HTTP Content Coding "compress"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/compress"
},
"x-compress": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".](http://tools.ietf.org/html/rfc7230#section-4.2.1 \"Read documentation for HTTP Content Coding "x-compress"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/x-compress"
},
"deflate": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"deflate\" coding is a \"zlib\" data format containing a \"deflate\" compressed data stream that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.](http://tools.ietf.org/html/rfc7230#section-4.2.2 \"Read documentation for HTTP Content Coding "deflate"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/deflate"
},
"x-gzip": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".](http://tools.ietf.org/html/rfc7230#section-4.2.3 \"Read documentation for HTTP Content Coding "x-gzip"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/x-gzip"
},
"identity": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [An \"identity\" token is used as a synonym for \"no encoding\" in order to communicate when no encoding is preferred.](http://tools.ietf.org/html/rfc7231#section-5.3.4 \"Read documentation for HTTP Content Coding "identity"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/identity"
},
"br": {
"details": "[RFC 7932: Brotli Compressed Data Format](/specs/IETF/RFC/7932 \"This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.\"):** [This specification defines a lossless compressed data format that compresses data using a combination of the LZ77 algorithm and Huffman coding, with efficiency comparable to the best currently available general-purpose compression methods.](http://tools.ietf.org/html/rfc7932 \"Read documentation for HTTP Content Coding "br"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/br"
},
"exi": {
"details": "[W3C TR http://www.w3.org/TR/exi: Efficient XML Interchange (EXI) Format 1.0](/specs/W3C/TR/exi \"This document is the specification of the Efficient XML Interchange (EXI) format. EXI is a very compact representation for the Extensible Markup Language (XML) Information Set that is intended to simultaneously optimize performance and the utilization of computational resources. The EXI format uses a hybrid approach drawn from the information and formal language theories, plus practical techniques verified by measurements, for entropy encoding XML information. Using a relatively simple algorithm, which is amenable to fast and compact implementation, and a small set of datatype representations, it reliably produces efficient encodings of XML event streams. The grammar production system and format definition of EXI are presented.\"):** [The content-coding value \"exi\" is registered with the Internet Assigned Numbers Authority (IANA) for use with EXI. Protocols that can identify and negotiate the content coding of XML information independent of its media type, SHOULD use the content coding \"exi\" (case-insensitive) to convey the acceptance or actual use of EXI encoding for XML information.](http://www.w3.org/TR/exi/#contentCoding \"Read documentation for HTTP Content Coding "exi"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/exi"
},
"pack200-gzip": {
"details": "[JSR 200: Pack200: A Packed Class Deployment Format For Java Applications](/specs/JCP/JSR/200 \"This document specifies an archive format called "Pack200". It is optimized for applications written in the Javatm programming language. Such applications are usually delivered as collections of classes, sometimes with associated resource files. This format allows any number (from one to hundreds of thousands) of Java classes to be encoded by a compressor, transmitted compactly in a single block of bytes, and decoded by a decompressor into equivalent Java class files. Because it can also represent class resources and other "side files", it can serve as an alternative to the JAR archive for some deployment tasks, notably downloading Java applications.\"):** [The Pack200 format can decrease the size of a Java application by a factor of seven to nine, compared with an equivalent JAR containing uncompressed (\"stored\") class files. By contrast, using the zip DEFLATE algorithm integral to JAR and ZIP archives gains a factor of two.](http://www.jcp.org/en/jsr/detail?id=200 \"Read documentation for HTTP Content Coding "pack200-gzip"\")",
"url": "http://webconcepts.info/concepts/http-content-coding/pack200-gzip"
}
},
"HTTP Status Code": {
"203 Non-Authoritative Information": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 203 (Non-Authoritative Information) status code indicates that the request was successful but the enclosed payload has been modified from that of the origin server's 200 (OK) response by a transforming proxy.](http://tools.ietf.org/html/rfc7231#section-6.3.4 \"Read documentation for HTTP Status Code "203"\")",
"url": "http://webconcepts.info/concepts/http-status-code/203"
},
"226 IM Used": {
"details": "[RFC 3229: Delta encoding in HTTP](/specs/IETF/RFC/3229 \"This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."\"):** [The server has fulfilled a GET request for the resource, and the response is a representation of the result of one or more instance-manipulations applied to the current instance. The actual current instance might not be available except by combining this response with other previous or future responses, as appropriate for the specific instance-manipulation(s).](http://tools.ietf.org/html/rfc3229#section-10.4.1 \"Read documentation for HTTP Status Code "226"\")",
"url": "http://webconcepts.info/concepts/http-status-code/226"
},
"424 Failed Dependency": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The 424 (Failed Dependency) status code means that the method could not be performed on the resource because the requested action depended on another action and that action failed. For example, if a command in a PROPPATCH method fails, then, at minimum, the rest of the commands will also fail with 424 (Failed Dependency).](http://tools.ietf.org/html/rfc4918#section-11.4 \"Read documentation for HTTP Status Code "424"\")",
"url": "http://webconcepts.info/concepts/http-status-code/424"
},
"302 Found": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 302 (Found) status code indicates that the target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client ought to continue to use the effective request URI for future requests.](http://tools.ietf.org/html/rfc7231#section-6.4.3 \"Read documentation for HTTP Status Code "302"\")",
"url": "http://webconcepts.info/concepts/http-status-code/302"
},
"411 Length Required": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 411 (Length Required) status code indicates that the server refuses to accept the request without a defined Content-Length. The client MAY repeat the request if it adds a valid Content-Length header field containing the length of the message body in the request message.](http://tools.ietf.org/html/rfc7231#section-6.5.10 \"Read documentation for HTTP Status Code "411"\")",
"url": "http://webconcepts.info/concepts/http-status-code/411"
},
"421 Misdirected Request": {
"details": "[RFC 7540: Hypertext Transfer Protocol Version 2](/specs/IETF/RFC/7540 \"This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.\"):** [The 421 (Misdirected Request) status code indicates that the request was directed at a server that is not able to produce a response. This can be sent by a server that is not configured to produce responses for the combination of scheme and authority that are included in the request URI.](http://tools.ietf.org/html/rfc7540#section-9.1.2 \"Read documentation for HTTP Status Code "421"\")",
"url": "http://webconcepts.info/concepts/http-status-code/421"
},
"428 Precondition Required": {
"details": "[RFC 6585: Additional HTTP Status Codes](/specs/IETF/RFC/6585 \"This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.\"):** [The 428 status code indicates that the origin server requires the request to be conditional.](http://tools.ietf.org/html/rfc6585#section-3 \"Read documentation for HTTP Status Code "428"\")",
"url": "http://webconcepts.info/concepts/http-status-code/428"
},
"307 Temporary Redirect": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 307 (Temporary Redirect) status code indicates that the target resource resides temporarily under a different URI and the user agent MUST NOT change the request method if it performs an automatic redirection to that URI. Since the redirection can change over time, the client ought to continue using the original effective request URI for future requests.](http://tools.ietf.org/html/rfc7231#section-6.4.7 \"Read documentation for HTTP Status Code "307"\")",
"url": "http://webconcepts.info/concepts/http-status-code/307"
},
"415 Unsupported Media Type": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 415 (Unsupported Media Type) status code indicates that the origin server is refusing to service the request because the payload is in a format not supported by this method on the target resource. The format problem might be due to the request's indicated Content-Type or Content-Encoding, or as a result of inspecting the data directly.](http://tools.ietf.org/html/rfc7231#section-6.5.13 \"Read documentation for HTTP Status Code "415"\")",
"url": "http://webconcepts.info/concepts/http-status-code/415"
},
"504 Gateway Timeout": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 504 (Gateway Timeout) status code indicates that the server, while acting as a gateway or proxy, did not receive a timely response from an upstream server it needed to access in order to complete the request.](http://tools.ietf.org/html/rfc7231#section-6.6.5 \"Read documentation for HTTP Status Code "504"\")",
"url": "http://webconcepts.info/concepts/http-status-code/504"
},
"416 Range Not Satisfiable": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [The 416 (Range Not Satisfiable) status code indicates that none of the ranges in the request's Range header field (Section 3.1) overlap the current extent of the selected resource or that the set of ranges requested has been rejected due to invalid ranges or an excessive request of small or overlapping ranges.](http://tools.ietf.org/html/rfc7233#section-4.4 \"Read documentation for HTTP Status Code "416"\")",
"url": "http://webconcepts.info/concepts/http-status-code/416"
},
"207 Multi-Status": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The 207 (Multi-Status) status code provides status for multiple independent operations.](http://tools.ietf.org/html/rfc4918#section-11.1 \"Read documentation for HTTP Status Code "207"\")",
"url": "http://webconcepts.info/concepts/http-status-code/207"
},
"300 Multiple Choices": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 300 (Multiple Choices) status code indicates that the target resource has more than one representation, each with its own more specific identifier, and information about the alternatives is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to one or more of those identifiers. In other words, the server desires that the user agent engage in reactive negotiation to select the most appropriate representation(s) for its needs.](http://tools.ietf.org/html/rfc7231#section-6.4.1 \"Read documentation for HTTP Status Code "300"\")",
"url": "http://webconcepts.info/concepts/http-status-code/300"
},
"101 Switching Protocols": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 101 (Switching Protocols) status code indicates that the server understands and is willing to comply with the client's request, via the Upgrade header field, for a change in the application protocol being used on this connection. The server MUST generate an Upgrade header field in the response that indicates which protocol(s) will be switched to immediately after the empty line that terminates the 101 response.](http://tools.ietf.org/html/rfc7231#section-6.2.2 \"Read documentation for HTTP Status Code "101"\")",
"url": "http://webconcepts.info/concepts/http-status-code/101"
},
"414 URI Too Long": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 414 (URI Too Long) status code indicates that the server is refusing to service the request because the request-target is longer than the server is willing to interpret.](http://tools.ietf.org/html/rfc7231#section-6.5.12 \"Read documentation for HTTP Status Code "414"\")",
"url": "http://webconcepts.info/concepts/http-status-code/414"
},
"426 Upgrade Required": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 426 (Upgrade Required) status code indicates that the server refuses to perform the request using the current protocol but might be willing to do so after the client upgrades to a different protocol. The server MUST send an Upgrade header field in a 426 response to indicate the required protocol(s).\n ](http://tools.ietf.org/html/rfc7231#section-6.5.15 \"Read documentation for HTTP Status Code "426"\")",
"url": "http://webconcepts.info/concepts/http-status-code/426"
},
"418 I'm a teapot": {
"details": "[RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)](/specs/IETF/RFC/2324 \"This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.\"):** [Any attempt to brew coffee with a teapot should result in the error code \"418 I'm a teapot\". The resulting entity body MAY be short and stout.](http://tools.ietf.org/html/rfc2324#section-2.3.2 \"Read documentation for HTTP Status Code "418"\")",
"url": "http://webconcepts.info/concepts/http-status-code/418"
},
"505 HTTP Version Not Supported": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 505 (HTTP Version Not Supported) status code indicates that the server does not support, or refuses to support, the major version of HTTP that was used in the request message. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. The server SHOULD generate a representation for the 505 response that describes why that version is not supported and what other protocols are supported by that server.](http://tools.ietf.org/html/rfc7231#section-6.6.6 \"Read documentation for HTTP Status Code "505"\")",
"url": "http://webconcepts.info/concepts/http-status-code/505"
},
"431 Request Header Fields Too Large": {
"details": "[RFC 6585: Additional HTTP Status Codes](/specs/IETF/RFC/6585 \"This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.\"):** [The 431 status code indicates that the server is unwilling to process the request because its header fields are too large. The request MAY be resubmitted after reducing the size of the request header fields.](http://tools.ietf.org/html/rfc6585#section-5 \"Read documentation for HTTP Status Code "431"\")",
"url": "http://webconcepts.info/concepts/http-status-code/431"
},
"502 Bad Gateway": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 502 (Bad Gateway) status code indicates that the server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request.](http://tools.ietf.org/html/rfc7231#section-6.6.3 \"Read documentation for HTTP Status Code "502"\")",
"url": "http://webconcepts.info/concepts/http-status-code/502"
},
"409 Conflict": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 409 (Conflict) status code indicates that the request could not be completed due to a conflict with the current state of the target resource. This code is used in situations where the user might be able to resolve the conflict and resubmit the request. The server SHOULD generate a payload that includes enough information for a user to recognize the source of the conflict.](http://tools.ietf.org/html/rfc7231#section-6.5.8 \"Read documentation for HTTP Status Code "409"\")",
"url": "http://webconcepts.info/concepts/http-status-code/409"
},
"102 Processing": {
"details": "[RFC 2518: HTTP Extensions for Distributed Authoring - WEBDAV](/specs/IETF/RFC/2518 \"This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).\"):** [The 102 (Processing) status code is an interim response used to inform the client that the server has accepted the complete request, but has not yet completed it. This status code SHOULD only be sent when the server has a reasonable expectation that the request will take significant time to complete. As guidance, if a method is taking longer than 20 seconds (a reasonable, but arbitrary value) to process the server SHOULD return a 102 (Processing) response. The server MUST send a final response after the request has been completed.](http://tools.ietf.org/html/rfc2518#section-10.1 \"Read documentation for HTTP Status Code "102"\")",
"url": "http://webconcepts.info/concepts/http-status-code/102"
},
"511 Network Authentication Required": {
"details": "[RFC 6585: Additional HTTP Status Codes](/specs/IETF/RFC/6585 \"This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.\"):** [The 511 status code indicates that the client needs to authenticate to gain network access.](http://tools.ietf.org/html/rfc6585#section-6 \"Read documentation for HTTP Status Code "511"\")",
"url": "http://webconcepts.info/concepts/http-status-code/511"
},
"451 Unavailable For Legal Reasons": {
"details": "[RFC 7725: An HTTP Status Code to Report Legal Obstacles](/specs/IETF/RFC/7725 \"This document specifies a Hypertext Transfer Protocol (HTTP) status code for use when resource access is denied as a consequence of legal demands.\"):** [This status code indicates that the server is denying access to the resource as a consequence of a legal demand. The server in question might not be an origin server. This type of legal demand typically most directly affects the operations of ISPs and search engines.](http://tools.ietf.org/html/rfc7725#section-3 \"Read documentation for HTTP Status Code "451"\")",
"url": "http://webconcepts.info/concepts/http-status-code/451"
},
"510 Not Extended": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [The policy for accessing the resource has not been met in the request. The server should send back all the information necessary for the client to issue an extended request. It is outside the scope of this specification to specify how the extensions inform the client.](http://tools.ietf.org/html/rfc2774#section-7 \"Read documentation for HTTP Status Code "510"\")",
"url": "http://webconcepts.info/concepts/http-status-code/510"
},
"306 Unused": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 306 status code was defined in a previous version of HTTP/1.1, is no longer used, and the code is reserved.\n ](http://tools.ietf.org/html/rfc7231#section-6.4.6 \"Read documentation for HTTP Status Code "306"\")",
"url": "http://webconcepts.info/concepts/http-status-code/306"
},
"100 Continue": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 100 (Continue) status code indicates that the initial part of a request has been received and has not yet been rejected by the server. The server intends to send a final response after the request has been fully received and acted upon.](http://tools.ietf.org/html/rfc7231#section-6.2.1 \"Read documentation for HTTP Status Code "100"\")",
"url": "http://webconcepts.info/concepts/http-status-code/100"
},
"412 Precondition Failed": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [The 412 (Precondition Failed) status code indicates that one or more conditions given in the request header fields evaluated to false when tested on the server. This response code allows the client to place preconditions on the current resource state (its current representations and metadata) and, thus, prevent the request method from being applied if the target resource is in an unexpected state.](http://tools.ietf.org/html/rfc7232#section-4.2 \"Read documentation for HTTP Status Code "412"\")",
"url": "http://webconcepts.info/concepts/http-status-code/412"
},
"201 Created": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 201 (Created) status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The primary resource created by the request is identified by either a Location header field in the response or, if no Location field is received, by the effective request URI.](http://tools.ietf.org/html/rfc7231#section-6.3.2 \"Read documentation for HTTP Status Code "201"\")",
"url": "http://webconcepts.info/concepts/http-status-code/201"
},
"500 Internal Server Error": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 500 (Internal Server Error) status code indicates that the server encountered an unexpected condition that prevented it from fulfilling the request.](http://tools.ietf.org/html/rfc7231#section-6.6.1 \"Read documentation for HTTP Status Code "500"\")",
"url": "http://webconcepts.info/concepts/http-status-code/500"
},
"402 Payment Required": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 402 (Payment Required) status code is reserved for future use.](http://tools.ietf.org/html/rfc7231#section-6.5.2 \"Read documentation for HTTP Status Code "402"\")",
"url": "http://webconcepts.info/concepts/http-status-code/402"
},
"404 Not Found": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 404 (Not Found) status code indicates that the origin server did not find a current representation for the target resource or is not willing to disclose that one exists. A 404 status code does not indicate whether this lack of representation is temporary or permanent; the 410 (Gone) status code is preferred over 404 if the origin server knows, presumably through some configurable means, that the condition is likely to be permanent.](http://tools.ietf.org/html/rfc7231#section-6.5.4 \"Read documentation for HTTP Status Code "404"\")",
"url": "http://webconcepts.info/concepts/http-status-code/404"
},
"401 Unauthorized": {
"details": "[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [The 401 (Unauthorized) status code indicates that the request has not been applied because it lacks valid authentication credentials for the target resource. The server generating a 401 response MUST send a WWW-Authenticate header field (Section 4.1) containing at least one challenge applicable to the target resource.](http://tools.ietf.org/html/rfc7235#section-3.1 \"Read documentation for HTTP Status Code "401"\")",
"url": "http://webconcepts.info/concepts/http-status-code/401"
},
"406 Not Acceptable": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 406 (Not Acceptable) status code indicates that the target resource does not have a current representation that would be acceptable to the user agent, according to the proactive negotiation header fields received in the request, and the server is unwilling to supply a default representation.](http://tools.ietf.org/html/rfc7231#section-6.5.6 \"Read documentation for HTTP Status Code "406"\")",
"url": "http://webconcepts.info/concepts/http-status-code/406"
},
"308 Permanent Redirect": {
"details": "[RFC 7538: The Hypertext Transfer Protocol Status Code 308 (Permanent Redirect)](/specs/IETF/RFC/7538 \"This document specifies the additional Hypertext Transfer Protocol (HTTP) status code 308 (Permanent Redirect).\"):** [The 308 (Permanent Redirect) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.](http://tools.ietf.org/html/rfc7538#section-3 \"Read documentation for HTTP Status Code "308"\")",
"url": "http://webconcepts.info/concepts/http-status-code/308"
},
"501 Not Implemented": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 501 (Not Implemented) status code indicates that the server does not support the functionality required to fulfill the request. This is the appropriate response when the server does not recognize the request method and is not capable of supporting it for any resource.](http://tools.ietf.org/html/rfc7231#section-6.6.2 \"Read documentation for HTTP Status Code "501"\")",
"url": "http://webconcepts.info/concepts/http-status-code/501"
},
"205 Reset Content": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 205 (Reset Content) status code indicates that the server has fulfilled the request and desires that the user agent reset the \"document view\", which caused the request to be sent, to its original state as received from the origin server.](http://tools.ietf.org/html/rfc7231#section-6.3.6 \"Read documentation for HTTP Status Code "205"\")",
"url": "http://webconcepts.info/concepts/http-status-code/205"
},
"400 Bad Request": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 400 (Bad Request) status code indicates that the server cannot or will not process the request due to something that is perceived to be a client error (e.g., malformed request syntax, invalid request message framing, or deceptive request routing).](http://tools.ietf.org/html/rfc7231#section-6.5.1 \"Read documentation for HTTP Status Code "400"\")",
"url": "http://webconcepts.info/concepts/http-status-code/400"
},
"208 Already Reported": {
"details": "[RFC 5842: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/5842 \"This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.\"):** [The 208 (Already Reported) status code can be used inside a DAV: propstat response element to avoid enumerating the internal members of multiple bindings to the same collection repeatedly. For each binding to a collection inside the request's scope, only one will be reported with a 200 status, while subsequent DAV:response elements for all other bindings will use the 208 status, and no DAV:response elements for their descendants are included.](http://tools.ietf.org/html/rfc5842#section-7.1 \"Read documentation for HTTP Status Code "208"\")",
"url": "http://webconcepts.info/concepts/http-status-code/208"
},
"413 Payload Too Large": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 413 (Payload Too Large) status code indicates that the server is refusing to process a request because the request payload is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request.](http://tools.ietf.org/html/rfc7231#section-6.5.11 \"Read documentation for HTTP Status Code "413"\")",
"url": "http://webconcepts.info/concepts/http-status-code/413"
},
"301 Moved Permanently": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 301 (Moved Permanently) status code indicates that the target resource has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs. Clients with link-editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible.](http://tools.ietf.org/html/rfc7231#section-6.4.2 \"Read documentation for HTTP Status Code "301"\")",
"url": "http://webconcepts.info/concepts/http-status-code/301"
},
"303 See Other": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.](http://tools.ietf.org/html/rfc7231#section-6.4.4 \"Read documentation for HTTP Status Code "303"\")",
"url": "http://webconcepts.info/concepts/http-status-code/303"
},
"508 Loop Detected": {
"details": "[RFC 5842: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/5842 \"This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.\"):** [The 508 (Loop Detected) status code indicates that the server terminated an operation because it encountered an infinite loop while processing a request with \"Depth: infinity\". This status indicates that the entire operation failed.](http://tools.ietf.org/html/rfc5842#section-7.1 \"Read documentation for HTTP Status Code "508"\")",
"url": "http://webconcepts.info/concepts/http-status-code/508"
},
"407 Proxy Authentication Required": {
"details": "[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [The 407 (Proxy Authentication Required) status code is similar to 401 (Unauthorized), but it indicates that the client needs to authenticate itself in order to use a proxy. The proxy MUST send a Proxy-Authenticate header field containing a challenge applicable to that proxy for the target resource. The client MAY repeat the request with a new or replaced Proxy-Authorization header field.](http://tools.ietf.org/html/rfc7235#section-3.2 \"Read documentation for HTTP Status Code "407"\")",
"url": "http://webconcepts.info/concepts/http-status-code/407"
},
"403 Forbidden": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 403 (Forbidden) status code indicates that the server understood the request but refuses to authorize it. A server that wishes to make public why the request has been forbidden can describe that reason in the response payload (if any).](http://tools.ietf.org/html/rfc7231#section-6.5.3 \"Read documentation for HTTP Status Code "403"\")",
"url": "http://webconcepts.info/concepts/http-status-code/403"
},
"202 Accepted": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 202 (Accepted) status code indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not eventually be acted upon, as it might be disallowed when processing actually takes place. There is no facility in HTTP for re-sending a status code from an asynchronous operation.](http://tools.ietf.org/html/rfc7231#section-6.3.3 \"Read documentation for HTTP Status Code "202"\")",
"url": "http://webconcepts.info/concepts/http-status-code/202"
},
"405 Method Not Allowed": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 405 (Method Not Allowed) status code indicates that the method received in the request-line is known by the origin server but not supported by the target resource. The origin server MUST generate an Allow header field in a 405 response containing a list of the target resource's currently supported methods.](http://tools.ietf.org/html/rfc7231#section-6.5.5 \"Read documentation for HTTP Status Code "405"\")",
"url": "http://webconcepts.info/concepts/http-status-code/405"
},
"200 OK": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 200 (OK) status code indicates that the request has succeeded. The payload sent in a 200 response depends on the request method.](http://tools.ietf.org/html/rfc7231#section-6.3.1 \"Read documentation for HTTP Status Code "200"\")",
"url": "http://webconcepts.info/concepts/http-status-code/200"
},
"423 Locked": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The 423 (Locked) status code means the source or destination resource of a method is locked. This response SHOULD contain an appropriate precondition or postcondition code, such as 'lock-token-submitted' or 'no-conflicting-lock'.](http://tools.ietf.org/html/rfc4918#section-11.3 \"Read documentation for HTTP Status Code "423"\")",
"url": "http://webconcepts.info/concepts/http-status-code/423"
},
"305 Use Proxy": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 305 (Use Proxy) status code was defined in a previous version of HTTP/1.1 and is now deprecated.](http://tools.ietf.org/html/rfc7231#section-6.4.5 \"Read documentation for HTTP Status Code "305"\")",
"url": "http://webconcepts.info/concepts/http-status-code/305"
},
"204 No Content": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 204 (No Content) status code indicates that the server has successfully fulfilled the request and that there is no additional content to send in the response payload body. Metadata in the response header fields refer to the target resource and its selected representation after the requested action was applied.](http://tools.ietf.org/html/rfc7231#section-6.3.5 \"Read documentation for HTTP Status Code "204"\")",
"url": "http://webconcepts.info/concepts/http-status-code/204"
},
"503 Service Unavailable": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 503 (Service Unavailable) status code indicates that the server is currently unable to handle the request due to a temporary overload or scheduled maintenance, which will likely be alleviated after some delay. The server MAY send a Retry-After header field to suggest an appropriate amount of time for the client to wait before retrying the request.](http://tools.ietf.org/html/rfc7231#section-6.6.4 \"Read documentation for HTTP Status Code "503"\")",
"url": "http://webconcepts.info/concepts/http-status-code/503"
},
"410 Gone": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 410 (Gone) status code indicates that access to the target resource is no longer available at the origin server and that this condition is likely to be permanent. If the origin server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) ought to be used instead.](http://tools.ietf.org/html/rfc7231#section-6.5.9 \"Read documentation for HTTP Status Code "410"\")",
"url": "http://webconcepts.info/concepts/http-status-code/410"
},
"422 Unprocessable Entity": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The 422 (Unprocessable Entity) status code means the server understands the content type of the request entity (hence a 415 (Unsupported Media Type) status code is inappropriate), and the syntax of the request entity is correct (thus a 400 (Bad Request) status code is inappropriate) but was unable to process the contained instructions. For example, this error condition may occur if an XML request body contains well-formed (i.e., syntactically correct), but semantically erroneous, XML instructions.](http://tools.ietf.org/html/rfc4918#section-11.2 \"Read documentation for HTTP Status Code "422"\")",
"url": "http://webconcepts.info/concepts/http-status-code/422"
},
"507 Insufficient Storage": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The 507 (Insufficient Storage) status code means the method could not be performed on the resource because the server is unable to store the representation needed to successfully complete the request. This condition is considered to be temporary. If the request that received this status code was the result of a user action, the request MUST NOT be repeated until it is requested by a separate user action.](http://tools.ietf.org/html/rfc4918#section-11.5 \"Read documentation for HTTP Status Code "507"\")",
"url": "http://webconcepts.info/concepts/http-status-code/507"
},
"304 Not Modified": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [The 304 (Not Modified) status code indicates that a conditional GET or HEAD request has been received and would have resulted in a 200 (OK) response if it were not for the fact that the condition evaluated to false. In other words, there is no need for the server to transfer a representation of the target resource because the request indicates that the client, which made the request conditional, already has a valid representation; the server is therefore redirecting the client to make use of that stored representation as if it were the payload of a 200 (OK) response.](http://tools.ietf.org/html/rfc7232#section-4.1 \"Read documentation for HTTP Status Code "304"\")",
"url": "http://webconcepts.info/concepts/http-status-code/304"
},
"429 Too Many Requests": {
"details": "[RFC 6585: Additional HTTP Status Codes](/specs/IETF/RFC/6585 \"This document specifies additional HyperText Transfer Protocol (HTTP) status codes for a variety of common situations.\"):** [The 429 status code indicates that the user has sent too many requests in a given amount of time (\"rate limiting\").](http://tools.ietf.org/html/rfc6585#section-4 \"Read documentation for HTTP Status Code "429"\")",
"url": "http://webconcepts.info/concepts/http-status-code/429"
},
"408 Request Timeout": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 408 (Request Timeout) status code indicates that the server did not receive a complete request message within the time that it was prepared to wait. A server SHOULD send the \"close\" connection option in the response, since 408 implies that the server has decided to close the connection rather than continue waiting. If the client has an outstanding request in transit, the client MAY repeat that request on a new connection.](http://tools.ietf.org/html/rfc7231#section-6.5.7 \"Read documentation for HTTP Status Code "408"\")",
"url": "http://webconcepts.info/concepts/http-status-code/408"
},
"506 Variant Also Negotiates": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [The 506 status code indicates that the server has an internal configuration error: the chosen variant resource is configured to engage in transparent content negotiation itself, and is therefore not a proper end point in the negotiation process.](http://tools.ietf.org/html/rfc7725#section-3 \"Read documentation for HTTP Status Code "506"\")",
"url": "http://webconcepts.info/concepts/http-status-code/506"
},
"417 Expectation Failed": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The 417 (Expectation Failed) status code indicates that the expectation given in the request's Expect header field could not be met by at least one of the inbound servers.](http://tools.ietf.org/html/rfc7231#section-6.5.14 \"Read documentation for HTTP Status Code "417"\")",
"url": "http://webconcepts.info/concepts/http-status-code/417"
},
"206 Partial Content": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource by transferring one or more parts of the selected representation that correspond to the satisfiable ranges found in the request's Range header field.](http://tools.ietf.org/html/rfc7233#section-4.1 \"Read documentation for HTTP Status Code "206"\")",
"url": "http://webconcepts.info/concepts/http-status-code/206"
}
},
"Link Relation": {
"preview": {
"details": "[RFC 6903: Additional Link Relation Types](/specs/IETF/RFC/6903 \"This specification defines a number of additional link relation types that can be used for a range of purposes in a variety of applications types.\"):** [The \"preview\" link relation can be used to refer to a resource that serves as a preview of the link's context, likely with reduced quality or limited content. For instance, the preview link might reference a screen capture of a video, a brief snippet of audio from a song, or a thumbnail representation of an image.](http://tools.ietf.org/html/rfc6903#section-3 \"Read documentation for Link Relation "preview"\")",
"url": "http://webconcepts.info/concepts/link-relation/preview"
},
"previous": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the immediately preceding document in a series of documents.](http://tools.ietf.org/html/rfc5005#section-3 \"Read documentation for Link Relation "previous"\")",
"url": "http://webconcepts.info/concepts/link-relation/previous"
},
"stylesheet": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to an external style sheet. See the section on external style sheets for details. This is used together with the link type \"Alternate\" for user-selectable alternate style sheets.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "stylesheet"\")",
"url": "http://webconcepts.info/concepts/link-relation/stylesheet"
},
"help": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document offering help (more information, links to other sources information, etc.)](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "help"\")",
"url": "http://webconcepts.info/concepts/link-relation/help"
},
"last": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the furthest following document in a series of documents.](http://tools.ietf.org/html/rfc5005#section-3 \"Read documentation for Link Relation "last"\")",
"url": "http://webconcepts.info/concepts/link-relation/last"
},
"successor-version": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a versioned resource, this link points to a resource containing the successor version in the version history.](http://tools.ietf.org/html/rfc5829#section-3.6 \"Read documentation for Link Relation "successor-version"\")",
"url": "http://webconcepts.info/concepts/link-relation/successor-version"
},
"create": {
"details": "[Internet Draft zyp-json-schema: A JSON Media Type for Describing the Structure and Meaning of JSON Documents](/specs/IETF/I-D/zyp-json-schema \"JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.\"):** [This indicates a target to use for creating new instances of a schema. This link definition SHOULD be a submission link with a non-safe method (like POST).](http://tools.ietf.org/html/draft-zyp-json-schema#section-6.1.1.2 \"Read documentation for Link Relation "create"\")",
"url": "http://webconcepts.info/concepts/link-relation/create"
},
"bcc": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is considered to be part of the private secondary audience of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "bcc"\")",
"url": "http://webconcepts.info/concepts/link-relation/bcc"
},
"type": {
"details": "[RFC 6903: Additional Link Relation Types](/specs/IETF/RFC/6903 \"This specification defines a number of additional link relation types that can be used for a range of purposes in a variety of applications types.\"):** [The \"type\" link relation can be used to indicate that the context resource is an instance of the resource identified by the target Internationalized Resource Identifier (IRI).](http://tools.ietf.org/html/rfc6903#section-6 \"Read documentation for Link Relation "type"\")",
"url": "http://webconcepts.info/concepts/link-relation/type"
},
"service-desc": {
"details": "[Internet Draft wilde-service-link-rel: Link Relation Types for Web Services](/specs/IETF/I-D/wilde-service-link-rel \"Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation or descriptions of the Web services. The difference between these concepts is that documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. It also defines a link relation to identify a status resource that is used to represent operational information about a service's status.\"):** [The \"service-desc\" link relation type is used to represent the fact that a resource is part of a bigger set of resources that are described at a specific URI. The target resource is expected to provide a service description that is intended for machine consumption. Very often, it is provided in a format that is consumed by tools, code libraries, or similar components.](http://tools.ietf.org/html/draft-wilde-service-link-rel#section-4.2 \"Read documentation for Link Relation "service-desc"\")",
"url": "http://webconcepts.info/concepts/link-relation/service-desc"
},
"preload": {
"details": "[W3C TR http://www.w3.org/TR/preload: Preload](/specs/W3C/TR/preload \"This specification defines the preload keyword that may be used with link elements. This keyword provides a declarative fetch primitive that initiates an early fetch and separates fetching from resource execution.\"):** [The preload keyword may be used with link elements. This keyword creates an external resource link (preload link) that is used to declare a resource and its fetch properties.](http://www.w3.org/TR/preload/#link-type-preload \"Read documentation for Link Relation "preload"\")",
"url": "http://webconcepts.info/concepts/link-relation/preload"
},
"chapter": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document serving as a chapter in a collection of documents.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "chapter"\")",
"url": "http://webconcepts.info/concepts/link-relation/chapter"
},
"prev-archive": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the immediately preceding archive document.](http://tools.ietf.org/html/rfc5005#section-4 \"Read documentation for Link Relation "prev-archive"\")",
"url": "http://webconcepts.info/concepts/link-relation/prev-archive"
},
"hosts": {
"details": "[RFC 6690: Constrained RESTful Environments (CoRE) Link Format](/specs/IETF/RFC/6690 \"This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server.\"):** [The \"hosts\" relation type (from the verb \"to host\") indicates that the target URI is a resource hosted by the server (i.e., server hosts resource) indicated by the context URI. The target URI MUST be a relative URI of the context URI for this relation type.](http://tools.ietf.org/html/rfc6690#section-2.2 \"Read documentation for Link Relation "hosts"\")",
"url": "http://webconcepts.info/concepts/link-relation/hosts"
},
"root": {
"details": "[Internet Draft zyp-json-schema: A JSON Media Type for Describing the Structure and Meaning of JSON Documents](/specs/IETF/I-D/zyp-json-schema \"JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.\"):** [This relation indicates that the target of the link SHOULD be treated as the root or the body of the representation for the purposes of user agent interaction or fragment resolution. All other properties of the instance objects can be regarded as meta-data descriptions for the data.](http://tools.ietf.org/html/draft-zyp-json-schema#section-6.1.1.2 \"Read documentation for Link Relation "root"\")",
"url": "http://webconcepts.info/concepts/link-relation/root"
},
"bookmark": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a bookmark. A bookmark is a link to a key entry point within an extended document. The title attribute may be used, for example, to label the bookmark. Note that several bookmarks may be defined in each document.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "bookmark"\")",
"url": "http://webconcepts.info/concepts/link-relation/bookmark"
},
"create-form": {
"details": "[RFC 6861: The \"create-form\" and \"edit-form\" Link Relations](/specs/IETF/RFC/6861 \"RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions.\"):** [When included in a response, the \"create-form\" link relation indicates a target resource that represents a form that can be used to append a new member to the link context.](http://tools.ietf.org/html/rfc6861#section-3.1 \"Read documentation for Link Relation "create-form"\")",
"url": "http://webconcepts.info/concepts/link-relation/create-form"
},
"collection": {
"details": "[RFC 6573: The Item and Collection Link Relations](/specs/IETF/RFC/6573 \"RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.\"):** [When included in a resource that represents a member of a collection, the 'collection' link relation identifies a target resource that represents a collection of which the context resource is a member.](http://tools.ietf.org/html/rfc6573#section-2.2 \"Read documentation for Link Relation "collection"\")",
"url": "http://webconcepts.info/concepts/link-relation/collection"
},
"describes": {
"details": "[RFC 6892: The 'describes' Link Relation Type](/specs/IETF/RFC/6892 \"This specification defines the 'describes' link relation type that allows resource representations to indicate that they are describing another resource. In contexts where applications want to associate described resources and description resources, and want to build services based on these associations, the 'describes' link relation type provides the opposite direction of the 'describedby' link relation type, which already is a registered link relation type.\"):** [The relationship A 'describes' B asserts that resource A provides a description of resource B. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.](http://tools.ietf.org/html/rfc6892#section-2 \"Read documentation for Link Relation "describes"\")",
"url": "http://webconcepts.info/concepts/link-relation/describes"
},
"dns-prefetch": {
"details": "[W3C TR http://www.w3.org/TR/resource-hints: Resource Hints](/specs/W3C/TR/resource-hints \"This specification defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTML Link Element (<link>). These primitives enable the developer, and the server generating or delivering the resources, to assist the user agent in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.\"):** [The dns-prefetch link relation type is used to indicate an origin that will be used to fetch required resources, and that the user agent SHOULD resolve as early as possible.](www.w3.org/TR/resource-hints/#dns-prefetch \"Read documentation for Link Relation "dns-prefetch"\")",
"url": "http://webconcepts.info/concepts/link-relation/dns-prefetch"
},
"disclosure": {
"details": "[RFC 6579: The 'disclosure' Link Relation Type](/specs/IETF/RFC/6579 \"This document specifies the 'disclosure' link relation type. It designates a list of IPR disclosures made with respect to the material for which such a relation type is specified.\"):** [Whenever the 'disclosure' relation type is used, the resource at the target Internationalized Resource Identifier (IRI) MUST represent a list of patent disclosures made with respect to the material referenced by context IRI.](http://tools.ietf.org/html/rfc6579#section-2 \"Read documentation for Link Relation "disclosure"\")",
"url": "http://webconcepts.info/concepts/link-relation/disclosure"
},
"mentionedby": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that mentions the context resource in some fashion. This, for example, would be used when an article mentions another article, or a social status update mentions a particular user, etc.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "mentionedby"\")",
"url": "http://webconcepts.info/concepts/link-relation/mentionedby"
},
"up": {
"details": "[Internet Draft divilly-atom-hierarchy: Hierarchy Relations for Atom](/specs/IETF/I-D/divilly-atom-hierarchy \"Many applications, besides blogs, provide their data in the form of syndicated Web feeds using formats such as Atom. Some such applications organize Atom Entries in a hierarchical fashion similar to a file system. This specification describes a means of communicating about Atom Entries that are hierarchically related to each other since resource identifiers are opaque to clients and cannot be directly manipulated for the purposes of representation exchange, i.e., navigation. This specification proposes new link relations for hierarchically related Atom resources.\"):** [An Atom link element with a rel attribute value of \"up\" may be used to reference a resource where parent entries of an entry or a feed may be found.](http://tools.ietf.org/html/draft-divilly-atom-hierarchy#section-2.3 \"Read documentation for Link Relation "up"\")",
"url": "http://webconcepts.info/concepts/link-relation/up"
},
"to": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is considered to be part of the public primary audience of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "to"\")",
"url": "http://webconcepts.info/concepts/link-relation/to"
},
"from": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is publicly considered to be the originator of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "from"\")",
"url": "http://webconcepts.info/concepts/link-relation/from"
},
"bfrom": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is privately considered to be the originator of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "bfrom"\")",
"url": "http://webconcepts.info/concepts/link-relation/bfrom"
},
"original": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [A link with an \"original\" Relation Type is used to point from a TimeGate or a Memento to its associated Original Resource.](http://tools.ietf.org/html/rfc7089#section-2.2.1 \"Read documentation for Link Relation "original"\")",
"url": "http://webconcepts.info/concepts/link-relation/original"
},
"full": {
"details": "[Internet Draft zyp-json-schema: A JSON Media Type for Describing the Structure and Meaning of JSON Documents](/specs/IETF/I-D/zyp-json-schema \"JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.\"):** [This indicates that the target of the link is the full representation for the instance object. The object that contains this link possibly may not be the full representation.](http://tools.ietf.org/html/draft-zyp-json-schema#section-6.1.1.2 \"Read documentation for Link Relation "full"\")",
"url": "http://webconcepts.info/concepts/link-relation/full"
},
"start": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to the first document in a collection of documents. This link type tells search engines which document is considered by the author to be the starting point of the collection.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "start"\")",
"url": "http://webconcepts.info/concepts/link-relation/start"
},
"privacy-policy": {
"details": "[RFC 6903: Additional Link Relation Types](/specs/IETF/RFC/6903 \"This specification defines a number of additional link relation types that can be used for a range of purposes in a variety of applications types.\"):** [The \"privacy-policy\" link relation can be used to refer to a resource describing the privacy policy associated with the link's context. The privacy policy can be any resource that discloses what personal information about the user is collected and how that personal information is stored, used, managed, and disclosed to other parties.](http://tools.ietf.org/html/rfc6903#section-4 \"Read documentation for Link Relation "privacy-policy"\")",
"url": "http://webconcepts.info/concepts/link-relation/privacy-policy"
},
"latest-version": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a versioned resource, this link points to a resource containing the latest (e.g., current) version.](http://tools.ietf.org/html/rfc5829#section-3.2 \"Read documentation for Link Relation "latest-version"\")",
"url": "http://webconcepts.info/concepts/link-relation/latest-version"
},
"edit-media": {
"details": "[RFC 5023: Atom Publishing Protocol (AtomPub)](/specs/IETF/RFC/5023 \"The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.\"):** [When appearing within an atom:entry, the value of the href attribute is an IRI that can be used to modify a Media Resource associated with that Entry.](http://tools.ietf.org/html/rfc5023#section-11.2 \"Read documentation for Link Relation "edit-media"\")",
"url": "http://webconcepts.info/concepts/link-relation/edit-media"
},
"bto": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is considered to be part of the private primary audience of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "bto"\")",
"url": "http://webconcepts.info/concepts/link-relation/bto"
},
"via": {
"details": "[RFC 4287: Atom Syndication Format](/specs/IETF/RFC/4287 \"Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.\"):** [The value \"via\" signifies that the IRI in the value of the href attribute identifies a resource that is the source of the information provided in the containing element.](http://tools.ietf.org/html/rfc4287#section-4.2.7.2 \"Read documentation for Link Relation "via"\")",
"url": "http://webconcepts.info/concepts/link-relation/via"
},
"enclosure": {
"details": "[RFC 4287: Atom Syndication Format](/specs/IETF/RFC/4287 \"Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.\"):** [The value \"enclosure\" signifies that the IRI in the value of the href attribute identifies a related resource that is potentially large in size and might require special handling. For atom:link elements with rel=\"enclosure\", the length attribute SHOULD be provided.](http://tools.ietf.org/html/rfc4287#section-4.2.7.2 \"Read documentation for Link Relation "enclosure"\")",
"url": "http://webconcepts.info/concepts/link-relation/enclosure"
},
"self": {
"details": "[RFC 4287: Atom Syndication Format](/specs/IETF/RFC/4287 \"Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.\"):** [The value \"self\" signifies that the IRI in the value of the href attribute identifies a resource equivalent to the containing element.](http://tools.ietf.org/html/rfc4287#section-4.2.7.2 \"Read documentation for Link Relation "self"\")",
"url": "http://webconcepts.info/concepts/link-relation/self"
},
"link": {
"details": "[RFC 5988: Web Linking](/specs/IETF/RFC/5988 \"This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.\"):** [In the simplest case, a link relation type identifies the semantics of a link. For example, a link with the relation type \"copyright\" indicates that the resource identified by the target IRI is a statement of the copyright terms applying to the current context IRI. Link relation types can also be used to indicate that the target resource has particular attributes, or exhibits particular behaviours; for example, a \"service\" link implies that the identified resource is part of a defined protocol (in this case, a service description).](http://tools.ietf.org/html/rfc5988#section-4 \"Read documentation for Link Relation "link"\")",
"url": "http://webconcepts.info/concepts/link-relation/link"
},
"current": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that, when dereferenced, returns a feed document containing the most recent entries in the feed.](http://tools.ietf.org/html/rfc5005#section-4 \"Read documentation for Link Relation "current"\")",
"url": "http://webconcepts.info/concepts/link-relation/current"
},
"contents": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document serving as a table of contents. Some user agents also support the synonym ToC (from \"Table of Contents\").](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "contents"\")",
"url": "http://webconcepts.info/concepts/link-relation/contents"
},
"location": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [References a URI/IRI that represents a physical or logical location with which the context resource is associated.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "location"\")",
"url": "http://webconcepts.info/concepts/link-relation/location"
},
"alternate": {
"details": "[RFC 4287: Atom Syndication Format](/specs/IETF/RFC/4287 \"Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.\"):** [The value \"alternate\" signifies that the IRI in the value of the href attribute identifies an alternate version of the resource described by the containing element.](http://tools.ietf.org/html/rfc4287#section-4.2.7.2 \"Read documentation for Link Relation "alternate"\")\n\n**[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Designates substitute versions for the document in which the link occurs. When used together with the lang attribute, it implies a translated version of the document. When used together with the media attribute, it implies a version designed for a different medium (or media).](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "alternate"\")",
"url": "http://webconcepts.info/concepts/link-relation/alternate"
},
"appendix": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document serving as an appendix in a collection of documents.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "appendix"\")",
"url": "http://webconcepts.info/concepts/link-relation/appendix"
},
"provider": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to the resource that provided the context resource. Typically, this would be used to identify the entity publishing the resource.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "provider"\")",
"url": "http://webconcepts.info/concepts/link-relation/provider"
},
"timemap": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [A link with a \"timemap\" Relation Type is used to point from a TimeGate or a Memento associated with an Original Resource, as well as from the Original Resource itself, to a TimeMap for the Original Resource.](http://tools.ietf.org/html/rfc7089#section-2.2.3 \"Read documentation for Link Relation "timemap"\")",
"url": "http://webconcepts.info/concepts/link-relation/timemap"
},
"about": {
"details": "[RFC 6903: Additional Link Relation Types](/specs/IETF/RFC/6903 \"This specification defines a number of additional link relation types that can be used for a range of purposes in a variety of applications types.\"):** [The \"about\" link relation can be used to refer to a resource that is the subject or topic of the link's context. Multiple subjects can be indicated through the use of multiple \"about\" link relations.](http://tools.ietf.org/html/rfc6903#section-2 \"Read documentation for Link Relation "about"\")",
"url": "http://webconcepts.info/concepts/link-relation/about"
},
"section": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document serving as a section in a collection of documents.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "section"\")",
"url": "http://webconcepts.info/concepts/link-relation/section"
},
"prev": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to the previous document in an ordered series of documents. Some user agents also support the synonym \"Previous\".](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "prev"\")",
"url": "http://webconcepts.info/concepts/link-relation/prev"
},
"source": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to the original source of information contained by the context resource.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "source"\")",
"url": "http://webconcepts.info/concepts/link-relation/source"
},
"cc": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to a resource that is considered to be part of the public secondary audience of the link's context.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "cc"\")",
"url": "http://webconcepts.info/concepts/link-relation/cc"
},
"webmention": {
"details": "[W3C TR http://www.w3.org/TR/webmention: Webmention](/specs/W3C/TR/webmention \"Webmention is a simple way to notify any URL when you link to it on your site. From the receiver's perspective, it's a way to request notifications when other sites link to it.\"):** [Identifies a target URI that supports the Webmention protocol. This allows clients that mention a resource in some form of publishing process to contact that endpoint and inform it that this resource has been mentioned.](http://www.w3.org/TR/webmention/#sender-discovers-receiver-webmention-endpoint \"Read documentation for Link Relation "webmention"\")",
"url": "http://webconcepts.info/concepts/link-relation/webmention"
},
"next-archive": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the immediately following archive document.](http://tools.ietf.org/html/rfc5005#section-4 \"Read documentation for Link Relation "next-archive"\")",
"url": "http://webconcepts.info/concepts/link-relation/next-archive"
},
"preconnect": {
"details": "[W3C TR http://www.w3.org/TR/resource-hints: Resource Hints](/specs/W3C/TR/resource-hints \"This specification defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTML Link Element (<link>). These primitives enable the developer, and the server generating or delivering the resources, to assist the user agent in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.\"):** [The preconnect link relation type is used to indicate an origin that will be used to fetch required resources. Initiating an early connection, which includes the DNS lookup, TCP handshake, and optional TLS negotiation, allows the user agent to mask the high latency costs of establishing a connection.](http://www.w3.org/TR/resource-hints/#preconnect \"Read documentation for Link Relation "preconnect"\")",
"url": "http://webconcepts.info/concepts/link-relation/preconnect"
},
"first": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the furthest preceding document in a series of documents.](http://tools.ietf.org/html/rfc5005#section-3 \"Read documentation for Link Relation "first"\")",
"url": "http://webconcepts.info/concepts/link-relation/first"
},
"version-history": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a versioned resource, this link points to a resource containing the version history for this resource.](http://tools.ietf.org/html/rfc5829#section-3.1 \"Read documentation for Link Relation "version-history"\")",
"url": "http://webconcepts.info/concepts/link-relation/version-history"
},
"derivedfrom": {
"details": "[Internet Draft hoffman-xml2rfc: The 'XML2RFC' version 3 Vocabulary](/specs/IETF/I-D/hoffman-xml2rfc \" This document defines the "XML2RFC" version 3 vocabulary; an XML-based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the v2 grammar described in RFC 2629 and its expected followup, draft-reschke-xml2rfc.\"):** [The document linked to was later converted to the document that contains this link relation. For example, an RFC can have a link to the Internet Draft that became the RFC; in that case, the link relation would be \"derivedfrom\".](https://tools.ietf.org/html/draft-hoffman-xml2rfc-15#section-6.2 \"Read documentation for Link Relation "derivedfrom"\")",
"url": "http://webconcepts.info/concepts/link-relation/derivedfrom"
},
"prefetch": {
"details": "[W3C TR http://www.w3.org/TR/resource-hints: Resource Hints](/specs/W3C/TR/resource-hints \"This specification defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTML Link Element (<link>). These primitives enable the developer, and the server generating or delivering the resources, to assist the user agent in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.\"):** [The prefetch link relation type is used to declare a resource that might be required by the next navigation, and that the user agent SHOULD fetch, such that the user agent can deliver a faster response once the resource is requested in the future.](http://www.w3.org/TR/resource-hints/#prefetch \"Read documentation for Link Relation "prefetch"\")",
"url": "http://webconcepts.info/concepts/link-relation/prefetch"
},
"instances": {
"details": "[Internet Draft zyp-json-schema: A JSON Media Type for Describing the Structure and Meaning of JSON Documents](/specs/IETF/I-D/zyp-json-schema \"JSON (JavaScript Object Notation) Schema defines the media type "application/schema+json", a JSON based format for defining the structure of JSON data. JSON Schema provides a contract for what JSON data is required for a given application and how to interact with it. JSON Schema is intended to define validation, documentation, hyperlink navigation, and interaction control of JSON data.\"):** [This indicates the target resource that represents collection of instances of a schema.](http://tools.ietf.org/html/draft-zyp-json-schema#section-6.1.1.2 \"Read documentation for Link Relation "instances"\")",
"url": "http://webconcepts.info/concepts/link-relation/instances"
},
"index": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document providing an index for the current document.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "index"\")",
"url": "http://webconcepts.info/concepts/link-relation/index"
},
"memento": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [A link with a \"memento\" Relation Type is used to point from a TimeGate or a Memento for an Original Resource, as well as from the Original Resource itself, to a Memento for the Original Resource.](http://tools.ietf.org/html/rfc7089#section-2.2.4 \"Read documentation for Link Relation "memento"\")",
"url": "http://webconcepts.info/concepts/link-relation/memento"
},
"prerender": {
"details": "[W3C TR http://www.w3.org/TR/resource-hints: Resource Hints](/specs/W3C/TR/resource-hints \"This specification defines the dns-prefetch, preconnect, prefetch, and prerender relationships of the HTML Link Element (<link>). These primitives enable the developer, and the server generating or delivering the resources, to assist the user agent in the decision process of which origins it should connect to, and which resources it should fetch and preprocess to improve page performance.\"):** [The prerender link relation type is used to declare an HTML resource that might be required by the next navigation, and that the user agent SHOULD fetch and execute, such that the user agent can deliver faster response and processing once the resource is requested in the future.](http://www.w3.org/TR/resource-hints/#prerender \"Read documentation for Link Relation "prerender"\")",
"url": "http://webconcepts.info/concepts/link-relation/prerender"
},
"canonical": {
"details": "[RFC 6596: The Canonical Link Relation](/specs/IETF/RFC/6596 \"RFC 5988 specifies a way to define relationships between links on the web. This document describes a new type of such a relationship, "canonical", to designate an Internationalized Resource Identifier (IRI) as preferred over resources with duplicative content.\"):** [The target (canonical) IRI MUST identify content that is either duplicative or a superset of the content at the context (referring) IRI.](http://tools.ietf.org/html/rfc6596#section-3 \"Read documentation for Link Relation "canonical"\")",
"url": "http://webconcepts.info/concepts/link-relation/canonical"
},
"service-doc": {
"details": "[Internet Draft wilde-service-link-rel: Link Relation Types for Web Services](/specs/IETF/I-D/wilde-service-link-rel \"Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation or descriptions of the Web services. The difference between these concepts is that documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. It also defines a link relation to identify a status resource that is used to represent operational information about a service's status.\"):** [The \"service-doc\" link relation type is used to represent the fact that a resource is part of a bigger set of resources that are documented at a specific URI. The target resource is expected to provide documentation that is intended for human consumption.](http://tools.ietf.org/html/draft-wilde-service-link-rel#section-4.1 \"Read documentation for Link Relation "service-doc"\")",
"url": "http://webconcepts.info/concepts/link-relation/service-doc"
},
"license": {
"details": "[RFC 4946: Atom License Extension](/specs/IETF/RFC/4946 \"This memo defines an Experimental Protocol for the Internet community. It does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited.\"):** [The \"license\" link relation can be used to associate licenses with a feed or entry. Feeds and entries can be dual-licensed by including multiple \"license\" link relations specifying different href attribute values. If multiple \"license\" link relations are specified, each SHOULD contain a title attribute specifying a human-readable label for the license.](http://tools.ietf.org/html/rfc4946#section-2 \"Read documentation for Link Relation "license"\")",
"url": "http://webconcepts.info/concepts/link-relation/license"
},
"working-copy": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a versioned resource, this link points to a working copy for this resource.](http://tools.ietf.org/html/rfc5829#section-3.3 \"Read documentation for Link Relation "working-copy"\")",
"url": "http://webconcepts.info/concepts/link-relation/working-copy"
},
"copyright": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a copyright statement for the current document.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "copyright"\")",
"url": "http://webconcepts.info/concepts/link-relation/copyright"
},
"subsection": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document serving as a subsection in a collection of documents.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "subsection"\")",
"url": "http://webconcepts.info/concepts/link-relation/subsection"
},
"item": {
"details": "[RFC 6573: The Item and Collection Link Relations](/specs/IETF/RFC/6573 \"RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members.\"):** [When included in a resource that represents a collection, the 'item' link relation identifies a target resource that represents a member of that collection.](http://tools.ietf.org/html/rfc6573#section-2.1 \"Read documentation for Link Relation "item"\")",
"url": "http://webconcepts.info/concepts/link-relation/item"
},
"edit-form": {
"details": "[RFC 6861: The \"create-form\" and \"edit-form\" Link Relations](/specs/IETF/RFC/6861 \"RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines link relation types that may be used to express the relationships between a resource and an input form for constructing data submissions.\"):** [When included in a response, the \"edit-form\" link relation indicates a target resource that represents a form that can be used for updating the context resource.](http://tools.ietf.org/html/rfc6861#section-3.2 \"Read documentation for Link Relation "edit-form"\")",
"url": "http://webconcepts.info/concepts/link-relation/edit-form"
},
"working-copy-of": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a working copy, this link points to the versioned resource from which this working copy was obtained.](http://tools.ietf.org/html/rfc5829#section-3.4 \"Read documentation for Link Relation "working-copy-of"\")",
"url": "http://webconcepts.info/concepts/link-relation/working-copy-of"
},
"edit": {
"details": "[RFC 5023: Atom Publishing Protocol (AtomPub)](/specs/IETF/RFC/5023 \"The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.\"):** [The value of \"edit\" specifies that the value of the href attribute is the IRI of an editable Member Entry. When appearing within an atom:entry, the href IRI can be used to retrieve, update, and delete the Resource represented by that Entry. An atom:entry MUST NOT contain more than one \"edit\" link relation.](http://tools.ietf.org/html/rfc5023#section-11.1 \"Read documentation for Link Relation "edit"\")",
"url": "http://webconcepts.info/concepts/link-relation/edit"
},
"describedby": {
"details": "[W3C TR http://www.w3.org/TR/ldp: Linked Data Platform 1.0 (LDP)](/specs/W3C/TR/ldp \"Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.\"):** [The relationship A describedby B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.](http://www.w3.org/TR/ldp/#link-relation-describedby \"Read documentation for Link Relation "describedby"\")\n\n**[W3C TR http://www.w3.org/TR/powder-dr: Protocol for Web Description Resources (POWDER): Description Resources](/specs/W3C/TR/powder-dr \"The purpose of the Protocol for Web Description Resources (POWDER) is to provide a means for individuals or organizations to describe a group of resources through the publication of machine-readable metadata, as motivated by the POWDER Use Cases. This document details the creation and lifecycle of Description Resources (DRs), which encapsulate such metadata. These are typically represented in a highly constrained XML dialect that is relatively human-readable. The meaning of such DRs are underpinned by formal semantics, accessible by performing a GRDDL Transform.\"):** [The relationship A 'describedby' B asserts that resource B provides a description of resource A. There are no constraints on the format or representation of either A or B, neither are there any further constraints on either resource.](http://www.w3.org/TR/powder-dr/#appD \"Read documentation for Link Relation "describedby"\")",
"url": "http://webconcepts.info/concepts/link-relation/describedby"
},
"micropub": {
"details": "[W3C TR http://www.w3.org/TR/micropub: Micropub](/specs/W3C/TR/micropub \"Micropub is an open API standard that is used to create posts on one's own domain using third-party clients. Web apps and native apps (e.g. iPhone, Android) can use Micropub to post short notes, photos, events or other posts to your own site.\"):** [Allows discovery of a Micropub endpoint which will be used to create posts.](https://www.w3.org/TR/micropub/#endpoint-discovery \"Read documentation for Link Relation "micropub"\")",
"url": "http://webconcepts.info/concepts/link-relation/micropub"
},
"next": {
"details": "[RFC 5005: Feed Paging and Archiving](/specs/IETF/RFC/5005 \"Syndicated Web feeds (using formats such as Atom) are often split into multiple documents to save bandwidth, allow "sliding window" access, or for other purposes. This specification formalizes two types of feeds that can span one or more feed documents; "paged" feeds and "archived" feeds. Additionally, it defines "complete" feeds to cover the case when a single feed document explicitly represents all of the feed's entries.\"):** [A URI that refers to the immediately following document in a series of documents.](http://tools.ietf.org/html/rfc5005#section-3 \"Read documentation for Link Relation "next"\")\n\n**[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to the next document in a linear sequence of documents. User agents may choose to preload the \"next\" document, to reduce the perceived load time.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "next"\")",
"url": "http://webconcepts.info/concepts/link-relation/next"
},
"manifest": {
"details": "[W3C TR http://www.w3.org/TR/appmanifest: Manifest for Web Application](/specs/W3C/TR/appmanifest \"This specification defines a JSON-based manifest that provides developers with a centralized place to put metadata associated with a web application. This includes, but is not limited to, the web application's name, links to icons, as well as the preferred URL to open when a user launches the web application. The manifest also allows developers to declare a default orientation for their web application, as well as providing the ability to set the display mode for the application (e.g., in fullscreen). Additionally, the manifest allows a developer to "scope" a web application to a URL. This restricts the URLs to which the application can be navigated and provides a means to "deep link" into a web application from other applications. Using this metadata, user agents can provide developers with means to create user experiences that are more comparable to that of a native application. In addition, this specification defines the manifest link type, which provides a declarative means for a document to be associated with a manifest.\"):** [Imports or links to a manifest.](http://www.w3.org/TR/appmanifest/#linking \"Read documentation for Link Relation "manifest"\")",
"url": "http://webconcepts.info/concepts/link-relation/manifest"
},
"related": {
"details": "[RFC 4287: Atom Syndication Format](/specs/IETF/RFC/4287 \"Atom is an XML-based document format that describes lists of related information known as "feeds". Feeds are composed of a number of items, known as "entries", each with an extensible set of attached metadata. For example, each entry has a title.\"):** [The value \"related\" signifies that the IRI in the value of the href attribute identifies a resource related to the resource described by the containing element. For example, the feed for a site that discusses the performance of the search engine at \"http://search.example.com\" might contain, as a child of atom:feed: <link rel=\"related\" href=\"http://search.example.com/\"/> An identical link might appear as a child of any atom:entry whose content contains a discussion of that same search engine.](http://tools.ietf.org/html/rfc4287#section-4.2.7.2 \"Read documentation for Link Relation "related"\")",
"url": "http://webconcepts.info/concepts/link-relation/related"
},
"timegate": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [A link with a \"timegate\" Relation Type is used to point from the Original Resource, as well as from a Memento associated with the Original Resource, to a TimeGate for the Original Resource.](http://tools.ietf.org/html/rfc7089#section-2.2.2 \"Read documentation for Link Relation "timegate"\")",
"url": "http://webconcepts.info/concepts/link-relation/timegate"
},
"lrdd": {
"details": "[RFC 6415: Web Host Metadata](/specs/IETF/RFC/6415 \"This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.\"):** [LRDD documents are linked to resources or host-meta documents using link templates with the \"lrdd\" relation type.](http://tools.ietf.org/html/rfc6415#section-1.1.1 \"Read documentation for Link Relation "lrdd"\")",
"url": "http://webconcepts.info/concepts/link-relation/lrdd"
},
"predecessor-version": {
"details": "[RFC 5829: Link Relation Types for Simple Version Navigation between Web Resources](/specs/IETF/RFC/5829 \"This specification defines a set of link relation types that may be used on Web resources for navigation between a resource and other resources related to version control, such as past versions and working copies.\"):** [When included on a versioned resource, this link points to a resource containing the predecessor version in the version history.](http://tools.ietf.org/html/rfc5829#section-3.5 \"Read documentation for Link Relation "predecessor-version"\")",
"url": "http://webconcepts.info/concepts/link-relation/predecessor-version"
},
"status": {
"details": "[Internet Draft wilde-service-link-rel: Link Relation Types for Web Services](/specs/IETF/I-D/wilde-service-link-rel \"Many resources provided on the Web are part of sets of resources that are provided in a context that is managed by one particular service provider. Often, these sets of resources are referred to as "Web Services" or "Web APIs". This specification defines link relations for representing relationships from those resources to ones that provide documentation or descriptions of the Web services. The difference between these concepts is that documentation is primarily intended for human consumers, whereas descriptions are primarily intended for automated consumers. It also defines a link relation to identify a status resource that is used to represent operational information about a service's status.\"):** [The \"status\" link relation type can be used to link to such a status resource, allowing service consumers to retrieve status information about a Web service's status. Such a link may not be available from all resources provided by a Web service, but from key resources such as a Web service's home resource.](http://tools.ietf.org/html/draft-wilde-service-link-rel#section-5 \"Read documentation for Link Relation "status"\")",
"url": "http://webconcepts.info/concepts/link-relation/status"
},
"terms-of-service": {
"details": "[RFC 6903: Additional Link Relation Types](/specs/IETF/RFC/6903 \"This specification defines a number of additional link relation types that can be used for a range of purposes in a variety of applications types.\"):** [The \"terms-of-service\" link relation can be used to refer to a resource describing the terms of service associated with the link's context. The terms of service can be any resource that describes the rules to which a consumer of the service must agree to follow when using the service provided by the link's context.](http://tools.ietf.org/html/rfc6903#section-5 \"Read documentation for Link Relation "terms-of-service"\")",
"url": "http://webconcepts.info/concepts/link-relation/terms-of-service"
},
"glossary": {
"details": "[W3C TR http://www.w3.org/TR/html4: Hypertext Markup Language (HTML)](/specs/W3C/TR/html4 \"This specification defines the HyperText Markup Language (HTML), the publishing language of the World Wide Web. This specification defines HTML 4.01, which is a subversion of HTML 4. In addition to the text, multimedia, and hyperlink features of the previous versions of HTML (HTML 3.2 and HTML 2.0), HTML 4 supports more multimedia options, scripting languages, style sheets, better printing facilities, and documents that are more accessible to users with disabilities. HTML 4 also takes great strides towards the internationalization of documents, with the goal of making the Web truly World Wide.\"):** [Refers to a document providing a glossary of terms that pertain to the current document.](http://www.w3.org/TR/html4/types.html#type-links \"Read documentation for Link Relation "glossary"\")",
"url": "http://webconcepts.info/concepts/link-relation/glossary"
},
"home": {
"details": "[Internet Draft wilde-home-xml: Home Documents for HTTP Services: XML Syntax](/specs/IETF/I-D/wilde-home-xml \"The specification for HTTP API Home Documents provides a JSON syntax only. This specification provides an XML syntax for the same data model, so that the concept of Home Documents can be consistently exposed in both JSON- and XML-based HTTP APIs. It also defines the link relation type "home" so that applications can identify links to home documents.\"):** [Identifies a resource that provides a \"home\" document for the context resource. Home documents often serve as starting points for a certain resource context, such as for Web APIs where the home resource provides access to a number of \"entry points\" to the Web API.](http://tools.ietf.org/html/draft-wilde-home-xml-04#section-4.3.1 \"Read documentation for Link Relation "home"\")",
"url": "http://webconcepts.info/concepts/link-relation/home"
},
"down": {
"details": "[Internet Draft divilly-atom-hierarchy: Hierarchy Relations for Atom](/specs/IETF/I-D/divilly-atom-hierarchy \"Many applications, besides blogs, provide their data in the form of syndicated Web feeds using formats such as Atom. Some such applications organize Atom Entries in a hierarchical fashion similar to a file system. This specification describes a means of communicating about Atom Entries that are hierarchically related to each other since resource identifiers are opaque to clients and cannot be directly manipulated for the purposes of representation exchange, i.e., navigation. This specification proposes new link relations for hierarchically related Atom resources.\"):** [An Atom link element with a rel attribute value of \"down\" may be used to reference a resource where child entries of an entry may be found.](http://tools.ietf.org/html/draft-divilly-atom-hierarchy#section-2.2 \"Read documentation for Link Relation "down"\")",
"url": "http://webconcepts.info/concepts/link-relation/down"
},
"generator": {
"details": "[Internet Draft snell-more-link-relations: Additional Link Relations and the urn:social Namespace](/specs/IETF/I-D/snell-more-link-relations \"This specification defines a number of additional Link Relation Types that can used for a variety of purposes.\"):** [Refers to the resource that generated the context resource. Typically, this would be used to identify the software application that created the context resource.](http://tools.ietf.org/html/draft-snell-more-link-relations#section-3 \"Read documentation for Link Relation "generator"\")",
"url": "http://webconcepts.info/concepts/link-relation/generator"
}
},
"HTTP Preference": {
"return": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [The \"return=representation\" preference indicates that the client prefers that the server include an entity representing the current state of the resource in the response to a successful request. The \"return=minimal\" preference, on the other hand, indicates that the client wishes the server to return only a minimal response to a successful request.](http://tools.ietf.org/html/rfc7240#section-4.2 \"Read documentation for HTTP Preference "return"\")",
"url": "http://webconcepts.info/concepts/http-preference/return"
},
"handling": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [The \"handling=strict\" and \"handling=lenient\" preferences indicate, at the server's discretion, how the client wishes the server to handle potential error conditions that can arise in the processing of a request.](http://tools.ietf.org/html/rfc7240#section-4.4 \"Read documentation for HTTP Preference "handling"\")",
"url": "http://webconcepts.info/concepts/http-preference/handling"
},
"wait": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [The \"wait\" preference can be used to establish an upper bound on the length of time, in seconds, the client expects it will take the server to process the request once it has been received.](http://tools.ietf.org/html/rfc7240#section-4.3 \"Read documentation for HTTP Preference "wait"\")",
"url": "http://webconcepts.info/concepts/http-preference/wait"
},
"respond-async": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [The \"respond-async\" preference indicates that the client prefers the server to respond asynchronously to a response.](http://tools.ietf.org/html/rfc7240#section-4.1 \"Read documentation for HTTP Preference "respond-async"\")",
"url": "http://webconcepts.info/concepts/http-preference/respond-async"
}
},
"HTTP Request Method": {
"REPORT": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A REPORT request is an extensible mechanism for obtaining information about a resource. Unlike a resource property, which has a single value, the value of a report can depend on additional information specified in the REPORT request body and in the REPORT request headers.](http://tools.ietf.org/html/rfc3253#section-3.6 \"Read documentation for HTTP Request Method "REPORT"\")",
"url": "http://webconcepts.info/concepts/http-method/REPORT"
},
"CHECKIN": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A CHECKIN request can be applied to a checked-out version-controlled resource to produce a new version whose content and dead properties are copied from the checked-out resource.](http://tools.ietf.org/html/rfc3253#section-4.4 \"Read documentation for HTTP Request Method "CHECKIN"\")",
"url": "http://webconcepts.info/concepts/http-method/CHECKIN"
},
"PROPFIND": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The PROPFIND method retrieves properties defined on the resource identified by the Request-URI, if the resource does not have any internal members, or on the resource identified by the Request-URI and potentially its member resources, if the resource is a collection that has internal member URLs.](http://tools.ietf.org/html/rfc4918#section-9.1 \"Read documentation for HTTP Request Method "PROPFIND"\")",
"url": "http://webconcepts.info/concepts/http-method/PROPFIND"
},
"UPDATE": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [The UPDATE method modifies the content and dead properties of a checked-in version-controlled resource (the \"update target\") to be those of a specified version (the \"update source\") from the version history of that version-controlled resource.](http://tools.ietf.org/html/rfc3253#section-7.1 \"Read documentation for HTTP Request Method "UPDATE"\")",
"url": "http://webconcepts.info/concepts/http-method/UPDATE"
},
"UNLOCK": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The UNLOCK method removes the lock identified by the lock token in the Lock-Token request header. The Request-URI MUST identify a resource within the scope of the lock.](http://tools.ietf.org/html/rfc4918#section-9.11 \"Read documentation for HTTP Request Method "UNLOCK"\")",
"url": "http://webconcepts.info/concepts/http-method/UNLOCK"
},
"UPDATEREDIRECTREF": {
"details": "[RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 \"This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.\"):** [The UPDATEREDIRECTREF method requests the update of a redirect reference resource.](http://tools.ietf.org/html/rfc4437#section-7 \"Read documentation for HTTP Request Method "UPDATEREDIRECTREF"\")",
"url": "http://webconcepts.info/concepts/http-method/UPDATEREDIRECTREF"
},
"HEAD": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The HEAD method is identical to GET except that the server MUST NOT send a message body in the response (i.e., the response terminates at the end of the header section). The server SHOULD send the same header fields in response to a HEAD request as it would have sent if the request had been a GET, except that the payload header fields MAY be omitted. This method can be used for obtaining metadata about the selected representation without transferring the representation data and is often used for testing hypertext links for validity, accessibility, and recent modification.](http://tools.ietf.org/html/rfc7231#section-4.3.2 \"Read documentation for HTTP Request Method "HEAD"\")",
"url": "http://webconcepts.info/concepts/http-method/HEAD"
},
"UNCHECKOUT": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [An UNCHECKOUT request can be applied to a checked-out version-controlled resource to cancel the CHECKOUT and restore the pre-CHECKOUT state of the version-controlled resource.](http://tools.ietf.org/html/rfc3253#section-4.5 \"Read documentation for HTTP Request Method "UNCHECKOUT"\")",
"url": "http://webconcepts.info/concepts/http-method/UNCHECKOUT"
},
"MKREDIRECTREF": {
"details": "[RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 \"This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.\"):** [The MKREDIRECTREF method requests the creation of a redirect reference resource.](http://tools.ietf.org/html/rfc4437#section-6 \"Read documentation for HTTP Request Method "MKREDIRECTREF"\")",
"url": "http://webconcepts.info/concepts/http-method/MKREDIRECTREF"
},
"DELETE": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The DELETE method requests that the origin server remove the association between the target resource and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.](http://tools.ietf.org/html/rfc7231#section-4.3.5 \"Read documentation for HTTP Request Method "DELETE"\")",
"url": "http://webconcepts.info/concepts/http-method/DELETE"
},
"CONNECT": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The CONNECT method requests that the recipient establish a tunnel to the destination origin server identified by the request-target and, if successful, thereafter restrict its behavior to blind forwarding of packets, in both directions, until the tunnel is closed. Tunnels are commonly used to create an end-to-end virtual connection, through one or more proxies, which can then be secured using TLS (Transport Layer Security).](http://tools.ietf.org/html/rfc7231#section-4.3.6 \"Read documentation for HTTP Request Method "CONNECT"\")",
"url": "http://webconcepts.info/concepts/http-method/CONNECT"
},
"ORDERPATCH": {
"details": "[RFC 3648: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol](/specs/IETF/RFC/3648 \"This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.\"):** [The ORDERPATCH method is used to change the ordering semantics of a collection, to change the order of the collection's members in the ordering, or both.](http://tools.ietf.org/html/rfc3648#section-7 \"Read documentation for HTTP Request Method "ORDERPATCH"\")",
"url": "http://webconcepts.info/concepts/http-method/ORDERPATCH"
},
"VERSION-CONTROL": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A VERSION-CONTROL request can be used to create a version-controlled resource at the request-URL. It can be applied to a versionable resource or to a version-controlled resource.](http://tools.ietf.org/html/rfc3253#section-3.5 \"Read documentation for HTTP Request Method "VERSION-CONTROL"\")",
"url": "http://webconcepts.info/concepts/http-method/VERSION-CONTROL"
},
"UNBIND": {
"details": "[RFC 5842: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/5842 \"This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.\"):** [The UNBIND method modifies the collection identified by the Request-URI by removing the binding identified by the segment specified in the UNBIND body.](http://tools.ietf.org/html/rfc5842#section-5 \"Read documentation for HTTP Request Method "UNBIND"\")",
"url": "http://webconcepts.info/concepts/http-method/UNBIND"
},
"PRI": {
"details": "[RFC 7540: Hypertext Transfer Protocol Version 2](/specs/IETF/RFC/7540 \"This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.\"):** [This method is never used by an actual client. This method will appear to be used when an HTTP/1.1 server or intermediary attempts to parse an HTTP/2 connection preface.](http://tools.ietf.org/html/rfc7540#section-3.5 \"Read documentation for HTTP Request Method "PRI"\")",
"url": "http://webconcepts.info/concepts/http-method/PRI"
},
"PROPPATCH": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The PROPPATCH method processes instructions specified in the request body to set and/or remove properties defined on the resource identified by the Request-URI.](http://tools.ietf.org/html/rfc4918#section-9.2 \"Read documentation for HTTP Request Method "PROPPATCH"\")",
"url": "http://webconcepts.info/concepts/http-method/PROPPATCH"
},
"LOCK": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The LOCK method is used to take out a lock of any access type and to refresh an existing lock.](http://tools.ietf.org/html/rfc4918#section-9.10 \"Read documentation for HTTP Request Method "LOCK"\")",
"url": "http://webconcepts.info/concepts/http-method/LOCK"
},
"POST": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The POST method requests that the target resource process the representation enclosed in the request according to the resource's own specific semantics.](http://tools.ietf.org/html/rfc7231#section-4.3.3 \"Read documentation for HTTP Request Method "POST"\")",
"url": "http://webconcepts.info/concepts/http-method/POST"
},
"GET": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The GET method requests transfer of a current selected representation for the target resource. GET is the primary mechanism of information retrieval and the focus of almost all performance optimizations. Hence, when people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.](http://tools.ietf.org/html/rfc7231#section-4.3.1 \"Read documentation for HTTP Request Method "GET"\")",
"url": "http://webconcepts.info/concepts/http-method/GET"
},
"PUT": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The PUT method requests that the state of the target resource be created or replaced with the state defined by the representation enclosed in the request message payload. A successful PUT of a given representation would suggest that a subsequent GET on that same target resource will result in an equivalent representation being sent in a 200 (OK) response. However, there is no guarantee that such a state change will be observable, since the target resource might be acted upon by other user agents in parallel, or might be subject to dynamic processing by the origin server, before any subsequent GET is received. A successful response only implies that the user agent's intent was achieved at the time of its processing by the origin server.](http://tools.ietf.org/html/rfc7231#section-4.3.4 \"Read documentation for HTTP Request Method "PUT"\")",
"url": "http://webconcepts.info/concepts/http-method/PUT"
},
"MKACTIVITY": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A MKACTIVITY request creates a new activity resource. A server MAY restrict activity creation to particular collections, but a client can determine the location of these collections from a DAV:activity-collection-set OPTIONS request.](http://tools.ietf.org/html/rfc3253#section-13.5 \"Read documentation for HTTP Request Method "MKACTIVITY"\")",
"url": "http://webconcepts.info/concepts/http-method/MKACTIVITY"
},
"SEARCH": {
"details": "[RFC 5323: Web Distributed Authoring and Versioning (WebDAV) SEARCH](/specs/IETF/RFC/5323 \"This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria.\"):** [The client invokes the SEARCH method to initiate a server-side search. The body of the request defines the query. The server MUST emit an entity matching the WebDAV multistatus format.](http://tools.ietf.org/html/rfc5323#section-2 \"Read documentation for HTTP Request Method "SEARCH"\")",
"url": "http://webconcepts.info/concepts/http-method/SEARCH"
},
"BIND": {
"details": "[RFC 5842: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/5842 \"This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.\"):** [The BIND method modifies the collection identified by the Request-URI, by adding a new binding from the segment specified in the BIND body to the resource identified in the BIND body.](http://tools.ietf.org/html/rfc5842#section-4 \"Read documentation for HTTP Request Method "BIND"\")",
"url": "http://webconcepts.info/concepts/http-method/BIND"
},
"MOVE": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The MOVE operation on a non-collection resource is the logical equivalent of a copy (COPY), followed by consistency maintenance processing, followed by a delete of the source, where all three actions are performed in a single operation. The consistency maintenance step allows the server to perform updates caused by the move, such as updating all URLs, other than the Request-URI that identifies the source resource, to point to the new destination resource.](http://tools.ietf.org/html/rfc4918#section-9.9 \"Read documentation for HTTP Request Method "MOVE"\")",
"url": "http://webconcepts.info/concepts/http-method/MOVE"
},
"TRACE": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The TRACE method requests a remote, application-level loop-back of the request message. The final recipient of the request SHOULD reflect the message received, excluding some fields described below, back to the client as the message body of a 200 (OK) response with a Content-Type of \"message/http\". The final recipient is either the origin server or the first server to receive a Max-Forwards value of zero (0) in the request.](http://tools.ietf.org/html/rfc7231#section-4.3.8 \"Read documentation for HTTP Request Method "TRACE"\")",
"url": "http://webconcepts.info/concepts/http-method/TRACE"
},
"PATCH": {
"details": "[RFC 5789: PATCH Method for HTTP](/specs/IETF/RFC/5789 \"Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.\"):** [The PATCH method requests that a set of changes described in the request entity be applied to the resource identified by the Request-URI. The set of changes is represented in a format called a \"patch document\" identified by a media type. If the Request-URI does not point to an existing resource, the server MAY create a new resource, depending on the patch document type (whether it can logically modify a null resource) and permissions, etc.](http://tools.ietf.org/html/rfc5789#section-2 \"Read documentation for HTTP Request Method "PATCH"\")",
"url": "http://webconcepts.info/concepts/http-method/PATCH"
},
"CHECKOUT": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A CHECKOUT request can be applied to a checked-in version-controlled resource to allow modifications to the content and dead properties of that version-controlled resource.](http://tools.ietf.org/html/rfc3253#section-4.3 \"Read documentation for HTTP Request Method "CHECKOUT"\")",
"url": "http://webconcepts.info/concepts/http-method/CHECKOUT"
},
"OPTIONS": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The OPTIONS method requests information about the communication options available for the target resource, at either the origin server or an intervening intermediary. This method allows a client to determine the options and/or requirements associated with a resource, or the capabilities of a server, without implying a resource action.](http://tools.ietf.org/html/rfc7231#section-4.3.7 \"Read documentation for HTTP Request Method "OPTIONS"\")",
"url": "http://webconcepts.info/concepts/http-method/OPTIONS"
},
"ACL": {
"details": "[RFC 3744: Web Distributed Authoring and Versioning (WebDAV) Access Control Protocol](/specs/IETF/RFC/3744 \"This document specifies a set of methods, headers, message bodies, properties, and reports that define Access Control extensions to the WebDAV Distributed Authoring Protocol. This protocol permits a client to read and modify access control lists that instruct a server whether to allow or deny operations upon a resource (such as HyperText Transfer Protocol (HTTP) method invocations) by a given principal. A lightweight representation of principals as Web resources supports integration of a wide range of user management repositories. Search operations allow discovery and manipulation of principals using human names.\"):** [The ACL method modifies the access control list (which can be read via the DAV:acl property) of a resource. Specifically, the ACL method only permits modification to ACEs that are not inherited, and are not protected.](http://tools.ietf.org/html/rfc3744#section-8.1 \"Read documentation for HTTP Request Method "ACL"\")",
"url": "http://webconcepts.info/concepts/http-method/ACL"
},
"MKCOL": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [MKCOL creates a new collection resource at the location specified by the Request-URI. If the Request-URI is already mapped to a resource, then the MKCOL MUST fail. During MKCOL processing, a server MUST make the Request-URI an internal member of its parent collection, unless the Request-URI is \"/\". If no such ancestor exists, the method MUST fail. When the MKCOL operation creates a new collection resource, all ancestors MUST already exist, or the method MUST fail with a 409 (Conflict) status code.](http://tools.ietf.org/html/rfc4918#section-9.3 \"Read documentation for HTTP Request Method "MKCOL"\")",
"url": "http://webconcepts.info/concepts/http-method/MKCOL"
},
"COPY": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The COPY method creates a duplicate of the source resource identified by the Request-URI, in the destination resource identified by the URI in the Destination header. The Destination header MUST be present. The exact behavior of the COPY method depends on the type of the source resource.](http://tools.ietf.org/html/rfc4918#section-9.8 \"Read documentation for HTTP Request Method "COPY"\")",
"url": "http://webconcepts.info/concepts/http-method/COPY"
},
"MKWORKSPACE": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A MKWORKSPACE request creates a new workspace resource. A server MAY restrict workspace creation to particular collections, but a client can determine the location of these collections from a DAV:workspace-collection-set OPTIONS request.](http://tools.ietf.org/html/rfc3253#section-6.3 \"Read documentation for HTTP Request Method "MKWORKSPACE"\")",
"url": "http://webconcepts.info/concepts/http-method/MKWORKSPACE"
},
"REBIND": {
"details": "[RFC 5842: Binding Extensions to Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/5842 \"This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to ensure the integrity of any bindings that they allow to be created.\"):** [The REBIND method removes a binding to a resource from a collection, and adds a binding to that resource into the collection identified by the Request-URI. The request body specifies the binding to be added (segment) and the old binding to be removed (href). It is effectively an atomic form of a MOVE request, and MUST be treated the same way as MOVE for the purpose of determining access permissions.](http://tools.ietf.org/html/rfc5842#section-6 \"Read documentation for HTTP Request Method "REBIND"\")",
"url": "http://webconcepts.info/concepts/http-method/REBIND"
},
"MKCALENDAR": {
"details": "[RFC 4791: Calendaring Extensions to WebDAV (CalDAV)](/specs/IETF/RFC/4791 \"This document defines extensions to the Web Distributed Authoring and Versioning (WebDAV) protocol to specify a standard way of accessing, managing, and sharing calendaring and scheduling information based on the iCalendar format. This document defines the "calendar-access" feature of CalDAV.\"):** [An HTTP request using the MKCALENDAR method creates a new calendar collection resource. A server MAY restrict calendar collection creation to particular collections.](http://tools.ietf.org/html/rfc4791#section-5.3.1 \"Read documentation for HTTP Request Method "MKCALENDAR"\")",
"url": "http://webconcepts.info/concepts/http-method/MKCALENDAR"
},
"BASELINE-CONTROL": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A collection can be placed under baseline control with a BASELINE-CONTROL request. When a collection is placed under baseline control, the DAV:version-controlled-configuration property of the collection is set to identify a new version-controlled configuration. This version-controlled configuration can be checked out and then checked in to create a new baseline for that collection.](http://tools.ietf.org/html/rfc3253#section-12.6 \"Read documentation for HTTP Request Method "BASELINE-CONTROL"\")",
"url": "http://webconcepts.info/concepts/http-method/BASELINE-CONTROL"
},
"LABEL": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [A LABEL request can be applied to a version to modify the labels that select that version. The case of a label name MUST be preserved when it is stored and retrieved. When comparing two label names to decide if they match or not, a server SHOULD use a case-sensitive URL-escaped UTF-8 encoded comparison of the two label names.](http://tools.ietf.org/html/rfc3253#section-8.2 \"Read documentation for HTTP Request Method "LABEL"\")",
"url": "http://webconcepts.info/concepts/http-method/LABEL"
},
"MERGE": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [The MERGE method performs the logical merge of a specified version (the \"merge source\") into a specified version-controlled resource (the \"merge target\"). If the merge source is neither an ancestor nor a descendant of the DAV:checked-in or DAV:checked-out version of the merge target, the MERGE checks out the merge target (if it is not already checked out) and adds the URL of the merge source to the DAV:merge-set of the merge target.](http://tools.ietf.org/html/rfc3253#section-11.2 \"Read documentation for HTTP Request Method "MERGE"\")",
"url": "http://webconcepts.info/concepts/http-method/MERGE"
}
},
"HTTP Header Field": {
"Pragma": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [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.](http://tools.ietf.org/html/rfc7234#section-5.4 \"Read documentation for HTTP Header Field "Pragma"\")",
"url": "http://webconcepts.info/concepts/http-header/Pragma"
},
"Apply-To-Redirect-Ref": {
"details": "[RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 \"This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.\"):** [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.](http://tools.ietf.org/html/rfc4437#section-12.2 \"Read documentation for HTTP Header Field "Apply-To-Redirect-Ref"\")",
"url": "http://webconcepts.info/concepts/http-header/Apply-To-Redirect-Ref"
},
"HTTP2-Settings": {
"details": "[RFC 7540: Hypertext Transfer Protocol Version 2](/specs/IETF/RFC/7540 \"This specification describes an optimized expression of the semantics of the Hypertext Transfer Protocol (HTTP). HTTP/2 enables a more efficient use of network resources and a reduced perception of latency by introducing header field compression and allowing multiple concurrent exchanges on the same connection. It also introduces unsolicited push of representations from servers to clients. This specification is an alternative to, but does not obsolete, the HTTP/1.1 message syntax. HTTP's existing semantics remain unchanged.\"):** [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.](http://tools.ietf.org/html/rfc7540#section-3.2.1 \"Read documentation for HTTP Header Field "HTTP2-Settings"\")",
"url": "http://webconcepts.info/concepts/http-header/HTTP2-Settings"
},
"If-None-Match": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-3.2 \"Read documentation for HTTP Header Field "If-None-Match"\")",
"url": "http://webconcepts.info/concepts/http-header/If-None-Match"
},
"SOAPAction": {
"details": "[W3C TR http://www.w3.org/TR/SOAP: Simple Object Access Protocol (SOAP) 1.1](/specs/W3C/TR/SOAP \"SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined datatypes, and a convention for representing remote procedure calls and responses. SOAP can potentially be used in combination with a variety of other protocols; however, the only bindings defined in this document describe how to use SOAP in combination with HTTP and HTTP Extension Framework.\"):** [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.](http://www.w3.org/TR/2000/NOTE-SOAP-20000508/#_Toc478383528 \"Read documentation for HTTP Header Field "SOAPAction"\")",
"url": "http://webconcepts.info/concepts/http-header/SOAPAction"
},
"Man": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [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.](http://tools.ietf.org/html/rfc2774#section-4.1 \"Read documentation for HTTP Header Field "Man"\")",
"url": "http://webconcepts.info/concepts/http-header/Man"
},
"Forwarded": {
"details": "[RFC 7239: Forwarded HTTP Extension](/specs/IETF/RFC/7239 \"This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.\"):** [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.](http://tools.ietf.org/html/rfc7239#section-4 \"Read documentation for HTTP Header Field "Forwarded"\")",
"url": "http://webconcepts.info/concepts/http-header/Forwarded"
},
"Slug": {
"details": "[RFC 5023: Atom Publishing Protocol (AtomPub)](/specs/IETF/RFC/5023 \"The Atom Publishing Protocol (AtomPub) is an application-level protocol for publishing and editing Web resources. The protocol is based on HTTP transfer of Atom-formatted representations. The Atom format is documented in the Atom Syndication Format.\"):** [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.](http://tools.ietf.org/html/rfc5023#section-9.7 \"Read documentation for HTTP Header Field "Slug"\")",
"url": "http://webconcepts.info/concepts/http-header/Slug"
},
"Tk": {
"details": "[W3C TR http://www.w3.org/TR/tracking-dnt: Tracking Preference Expression (DNT)](/specs/W3C/TR/tracking-dnt \"This specification defines the technical mechanisms for expressing a tracking preference via the DNT request header field in HTTP, via an HTML DOM property readable by embedded scripts, and via properties accessible to various user agent plug-in or extension APIs. It also defines mechanisms for sites to signal whether and how they honor this preference, both in the form of a machine-readable tracking status resource at a well-known location and via a "Tk" response header field, and a mechanism for allowing the user to approve exceptions to DNT as desired.\"):** [The Tk response header field is defined as an OPTIONAL means for indicating the tracking status that applied to the corresponding request, and as a REQUIRED means for indicating that a state-changing request has resulted in an interactive change to the tracking status.](http://www.w3.org/TR/tracking-dnt/#response-header-field \"Read documentation for HTTP Header Field "Tk"\")",
"url": "http://webconcepts.info/concepts/http-header/Tk"
},
"WWW-Authenticate": {
"details": "[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [The \"WWW-Authenticate\" header field consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the effective request URI. It MUST be included in 401 (Unauthorized) response messages and MAY be included in other response messages to indicate that supplying credentials (or different credentials) might affect the response.](http://tools.ietf.org/html/rfc7235#section-4.4 \"Read documentation for HTTP Header Field "WWW-Authenticate"\")\n\n**[RFC 7616: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 \"The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.\"):** [If a server receives a request for an access-protected object, and an acceptable Authorization header is not sent, the server responds with a \"401 Unauthorized\" status code, and a WWW-Authenticate header as per the framework defined above.](http://tools.ietf.org/html/rfc7616#section-3.3 \"Read documentation for HTTP Header Field "WWW-Authenticate"\")",
"url": "http://webconcepts.info/concepts/http-header/WWW-Authenticate"
},
"Schedule-Tag": {
"details": "[RFC 6638: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 \"This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.\"):** [The Schedule-Tag response header provides the current value of the CALDAV:schedule-tag property value.](http://tools.ietf.org/html/rfc6638#section-8.2 \"Read documentation for HTTP Header Field "Schedule-Tag"\")",
"url": "http://webconcepts.info/concepts/http-header/Schedule-Tag"
},
"Accept": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-5.3.2 \"Read documentation for HTTP Header Field "Accept"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept"
},
"Last-Modified": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-2.2 \"Read documentation for HTTP Header Field "Last-Modified"\")",
"url": "http://webconcepts.info/concepts/http-header/Last-Modified"
},
"DNT": {
"details": "[W3C TR http://www.w3.org/TR/tracking-dnt: Tracking Preference Expression (DNT)](/specs/W3C/TR/tracking-dnt \"This specification defines the technical mechanisms for expressing a tracking preference via the DNT request header field in HTTP, via an HTML DOM property readable by embedded scripts, and via properties accessible to various user agent plug-in or extension APIs. It also defines mechanisms for sites to signal whether and how they honor this preference, both in the form of a machine-readable tracking status resource at a well-known location and via a "Tk" response header field, and a mechanism for allowing the user to approve exceptions to DNT as desired.\"):** [The DNT header field is defined as the means for expressing a user's tracking preference via HTTP.](http://www.w3.org/TR/tracking-dnt/#dnt-header-field \"Read documentation for HTTP Header Field "DNT"\")",
"url": "http://webconcepts.info/concepts/http-header/DNT"
},
"DAV": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [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.](http://tools.ietf.org/html/rfc4918#section-10.1 \"Read documentation for HTTP Header Field "DAV"\")",
"url": "http://webconcepts.info/concepts/http-header/DAV"
},
"Prefer": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [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.](http://tools.ietf.org/html/rfc7240#section-2 \"Read documentation for HTTP Header Field "Prefer"\")",
"url": "http://webconcepts.info/concepts/http-header/Prefer"
},
"Content-Range": {
"details": "[Internet Draft combs-http-indeterminate-range: HTTP/1.1: Range Responses of Indeterminate Length](/specs/IETF/I-D/combs-http-indeterminate-range \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document updates RFC 7233 Part 5 of the eight-part specification that defines the protocol referred to as "HTTP/1.1". Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. This document improves support for responding to range requests for resources of indeterminate size.\"):** [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.](http://tools.ietf.org/html/draft-combs-http-indeterminate-range#section-2.2 \"Read documentation for HTTP Header Field "Content-Range"\")\n\n**[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [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.](http://tools.ietf.org/html/rfc7233#section-4.2 \"Read documentation for HTTP Header Field "Content-Range"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Range"
},
"Content-Security-Policy": {
"details": "[W3C TR http://www.w3.org/TR/CSP2: Content Security Policy Level 2](/specs/W3C/TR/CSP2 \"This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.\"):** [The Content-Security-Policy header field is the preferred mechanism for delivering a policy.](http://www.w3.org/TR/CSP2/#content-security-policy-header-field \"Read documentation for HTTP Header Field "Content-Security-Policy"\")\n\n**[W3C TR http://www.w3.org/TR/CSP3: Content Security Policy Level 3](/specs/W3C/TR/CSP3 \"This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.\"):** [The Content-Security-Policy HTTP response header field is the preferred mechanism for delivering a policy from a server to a client.](http://www.w3.org/TR/CSP3/#csp-header \"Read documentation for HTTP Header Field "Content-Security-Policy"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Security-Policy"
},
"Destination": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [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.](http://tools.ietf.org/html/rfc4918#section-10.3 \"Read documentation for HTTP Header Field "Destination"\")",
"url": "http://webconcepts.info/concepts/http-header/Destination"
},
"Authentication-Info": {
"details": "[RFC 7615: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields](/specs/IETF/RFC/7615 \"This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted.\"):** [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).](http://tools.ietf.org/html/rfc7615#section-3 \"Read documentation for HTTP Header Field "Authentication-Info"\")",
"url": "http://webconcepts.info/concepts/http-header/Authentication-Info"
},
"Access-Control-Expose-Headers": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [The Access-Control-Expose-Headers header indicates which headers are safe to expose to the API of a CORS API specification.](http://www.w3.org/TR/cors/#access-control-expose-headers-response-header \"Read documentation for HTTP Header Field "Access-Control-Expose-Headers"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Expose-Headers"
},
"Origin-Cookie": {
"details": "[Internet Draft west-origin-cookies: Origin Cookies](/specs/IETF/I-D/west-origin-cookies \"This document updates RFC 6265, defining the "origin" attribute for cookies and the "Origin-Cookie" header field, which together allow servers to choose to harmonize the security policy of their cookies with the same-origin policy which governs other available client-side storage mechanisms.\"):** [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.](http://tools.ietf.org/html/draft-west-origin-cookies#section-4.4 \"Read documentation for HTTP Header Field "Origin-Cookie"\")",
"url": "http://webconcepts.info/concepts/http-header/Origin-Cookie"
},
"SubOK": {
"details": "[Internet Draft mogul-http-dupsup: Duplicate Suppression in HTTP](/specs/IETF/I-D/mogul-http-dupsup \"A significant fraction of Web content is often exactly duplicated under several different URIs. This duplication can lead to suboptimal use of network bandwidth, and unnecessary latency for users. Much of this duplication can be avoided through the use of a simple mechanism, described here, which allows a cache to efficiently substitute one byte-for-byte identical value for another. By doing so, the cache avoids some or all of the network costs associated with retrieving the duplicate value.\"):** [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.](http://tools.ietf.org/html/draft-mogul-http-dupsup#section-5.2.1 \"Read documentation for HTTP Header Field "SubOK"\")",
"url": "http://webconcepts.info/concepts/http-header/SubOK"
},
"Overwrite": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE.](http://tools.ietf.org/html/rfc4918#section-10.6 \"Read documentation for HTTP Header Field "Overwrite"\")",
"url": "http://webconcepts.info/concepts/http-header/Overwrite"
},
"Accept-Features": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [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.](http://tools.ietf.org/html/rfc2295#section-8.2 \"Read documentation for HTTP Header Field "Accept-Features"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Features"
},
"Link-Template": {
"details": "[Internet Draft nottingham-link-template: The Link-Template HTTP Header Field](/specs/IETF/I-D/nottingham-link-template \"This specification defines the Link-Template HTTP header field, providing a means for describing the structure of a link between two resources, so that new links can be generated.\"):** [The Link-Template entity-header field provides a means for serialising one or more links into HTTP headers. It is semantically equivalent to the Link header field, except that it uses URI Templates to convey the structure of links.](http://tools.ietf.org/html/draft-nottingham-link-template#section-4 \"Read documentation for HTTP Header Field "Link-Template"\")",
"url": "http://webconcepts.info/concepts/http-header/Link-Template"
},
"Redirect-Ref": {
"details": "[RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources](/specs/IETF/RFC/4437 \"This specification defines an extension to Web Distributed Authoring and Versioning (WebDAV) to allow clients to author HTTP redirect reference resources whose default response is an HTTP/1.1 3xx (Redirection) status code. A redirect reference makes it possible to access the target resourced indirectly through any URI mapped to the redirect reference resource. This specification does not address remapping of trees of resources or regular expression based redirections. There are no integrity guarantees associated with redirect reference resources. Other mechanisms can also be used to achieve the same functionality as this specification. This specification allows operators to experiment with this mechanism and develop experience on what is the best approach to the problem.\"):** [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.](http://tools.ietf.org/html/rfc4437#section-12.1 \"Read documentation for HTTP Header Field "Redirect-Ref"\")",
"url": "http://webconcepts.info/concepts/http-header/Redirect-Ref"
},
"Allow": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-7.4.1 \"Read documentation for HTTP Header Field "Allow"\")",
"url": "http://webconcepts.info/concepts/http-header/Allow"
},
"Content-Security-Policy-Pin": {
"details": "[W3C TR http://www.w3.org/TR/csp-pinning: Content Security Policy Pinning](/specs/W3C/TR/csp-pinning \"This document defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.\"):** [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).](http://www.w3.org/TR/csp-pinning/#content-security-policy-pin-header-field \"Read documentation for HTTP Header Field "Content-Security-Policy-Pin"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Security-Policy-Pin"
},
"Proxy-Features": {
"details": "[W3C TR http://www.w3.org/TR/WD-proxy: Notification for Proxy Caches](/specs/W3C/TR/WD-proxy \"A mechanism to enable better functioning of proxies is proposed. This mechanism allows proxies to inform a remote server about transactions performed using the cache and for servers to inform proxies when data becomes stale.\"):** [The proxy features header is used by a proxy sending data to a server. It specifies the features supported by the specified proxy.](http://www.w3.org/TR/WD-proxy \"Read documentation for HTTP Header Field "Proxy-Features"\")",
"url": "http://webconcepts.info/concepts/http-header/Proxy-Features"
},
"C-PEP-Info": {
"details": "[W3C TR http://www.w3.org/TR/WD-http-pep: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep \" HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.\"):** [PEP 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.](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743954 \"Read documentation for HTTP Header Field "C-PEP-Info"\")",
"url": "http://webconcepts.info/concepts/http-header/C-PEP-Info"
},
"X-Frame-Options": {
"details": "[RFC 7034: HTTP Header Field X-Frame-Options](/specs/IETF/RFC/7034 \"To improve the protection of web applications against clickjacking, this document describes the X-Frame-Options HTTP header field, which declares a policy, communicated from the server to the client browser, regarding whether the browser may display the transmitted content in frames that are part of other web pages.\"):** [The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a <frame> or an <iframe>. Servers can declare this policy in the header of their HTTP responses to prevent clickjacking attacks, which ensures that their content is not embedded into other pages or frames.](http://tools.ietf.org/html/rfc7034#section-2 \"Read documentation for HTTP Header Field "X-Frame-Options"\")",
"url": "http://webconcepts.info/concepts/http-header/X-Frame-Options"
},
"Memento-Datetime": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [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.](http://tools.ietf.org/html/rfc7089#section-2.1.1 \"Read documentation for HTTP Header Field "Memento-Datetime"\")",
"url": "http://webconcepts.info/concepts/http-header/Memento-Datetime"
},
"Alt-Used": {
"details": "[RFC 7838: HTTP Alternate Services](/specs/IETF/RFC/7838 \"This document specifies "alternative services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.\"):** [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.](http://tools.ietf.org/html/rfc7838#section-5 \"Read documentation for HTTP Header Field "Alt-Used"\")",
"url": "http://webconcepts.info/concepts/http-header/Alt-Used"
},
"PEP": {
"details": "[W3C TR http://www.w3.org/TR/WD-http-pep: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep \" HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.\"):** [PEP 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.](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743947 \"Read documentation for HTTP Header Field "PEP"\")",
"url": "http://webconcepts.info/concepts/http-header/PEP"
},
"Accept-Indefinite-Ranges": {
"details": "[Internet Draft combs-http-indeterminate-range: HTTP/1.1: Range Responses of Indeterminate Length](/specs/IETF/I-D/combs-http-indeterminate-range \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document updates RFC 7233 Part 5 of the eight-part specification that defines the protocol referred to as "HTTP/1.1". Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests. This document improves support for responding to range requests for resources of indeterminate size.\"):** [The Accept-Indefinite-Ranges request-header field allows the client to indicate its acceptance of indefinite-sized range requests for a resource.](http://tools.ietf.org/html/draft-combs-http-indeterminate-range#section-2.1 \"Read documentation for HTTP Header Field "Accept-Indefinite-Ranges"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Indefinite-Ranges"
},
"Schedule-Reply": {
"details": "[RFC 6638: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 \"This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.\"):** [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.](http://tools.ietf.org/html/rfc6638#section-8.1 \"Read documentation for HTTP Header Field "Schedule-Reply"\")",
"url": "http://webconcepts.info/concepts/http-header/Schedule-Reply"
},
"Downlink": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"Downlink\" header field is a number that, in requests, indicates the client's maximum downlink speed in megabits per second (Mbps), as defined by the \"downlinkMax\" attribute in the W3C Network Information API.](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-6 \"Read documentation for HTTP Header Field "Downlink"\")",
"url": "http://webconcepts.info/concepts/http-header/Downlink"
},
"If-Range": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [If 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.](http://tools.ietf.org/html/rfc7233#section-3.2 \"Read documentation for HTTP Header Field "If-Range"\")",
"url": "http://webconcepts.info/concepts/http-header/If-Range"
},
"Accept-Language": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The \"Accept-Language\" header field can be used by user agents to indicate the set of natural languages that are preferred in the response.](http://tools.ietf.org/html/rfc7231#section-5.3.5 \"Read documentation for HTTP Header Field "Accept-Language"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Language"
},
"DPR": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"DPR\" header field is a number that, in requests, indicates the client's current Device Pixel Ratio (DPR), which is the ratio of physical pixels over CSS px of the layout viewport on the device.](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-3 \"Read documentation for HTTP Header Field "DPR"\")",
"url": "http://webconcepts.info/concepts/http-header/DPR"
},
"Location": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-7.1.2 \"Read documentation for HTTP Header Field "Location"\")",
"url": "http://webconcepts.info/concepts/http-header/Location"
},
"Negotiate": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [The Negotiate request header can contain directives for any content negotiation process initiated by the request.](http://tools.ietf.org/html/rfc2295#section-8.4 \"Read documentation for HTTP Header Field "Negotiate"\")",
"url": "http://webconcepts.info/concepts/http-header/Negotiate"
},
"If-Match": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-3.1 \"Read documentation for HTTP Header Field "If-Match"\")",
"url": "http://webconcepts.info/concepts/http-header/If-Match"
},
"Public": {
"details": "[RFC 2068: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".\"):** [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.](http://tools.ietf.org/html/rfc2068#section-14.35 \"Read documentation for HTTP Header Field "Public"\")",
"url": "http://webconcepts.info/concepts/http-header/Public"
},
"Strict-Transport-Security": {
"details": "[RFC 6797: HTTP Strict Transport Security (HSTS)](/specs/IETF/RFC/6797 \"This specification defines a mechanism enabling web sites to declare themselves accessible only via secure connections and/or for users to be able to direct their user agent(s) to interact with given sites only over secure connections. This overall policy is referred to as HTTP Strict Transport Security (HSTS). The policy is declared by web sites via the Strict-Transport-Security HTTP response header field and/or by other means, such as user agent configuration, for example.\"):** [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.](http://tools.ietf.org/html/rfc6797#section-6.1 \"Read documentation for HTTP Header Field "Strict-Transport-Security"\")",
"url": "http://webconcepts.info/concepts/http-header/Strict-Transport-Security"
},
"Timeout": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests.](http://tools.ietf.org/html/rfc4918#section-10.7 \"Read documentation for HTTP Header Field "Timeout"\")",
"url": "http://webconcepts.info/concepts/http-header/Timeout"
},
"Cookie2": {
"details": "[RFC 2965: HTTP State Management Mechanism](/specs/IETF/RFC/2965 \"This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method.\"):** [The Cookie2 request header facilitates interoperation between clients and servers that understand different versions of the cookie specification.](http://tools.ietf.org/html/rfc2965#section-3.3 \"Read documentation for HTTP Header Field "Cookie2"\")",
"url": "http://webconcepts.info/concepts/http-header/Cookie2"
},
"Close": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [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.](http://tools.ietf.org/html/rfc7230#section-8.1 \"Read documentation for HTTP Header Field "Close"\")",
"url": "http://webconcepts.info/concepts/http-header/Close"
},
"User-Agent": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The \"User-Agent\" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use.](http://tools.ietf.org/html/rfc7231#section-5.5.3 \"Read documentation for HTTP Header Field "User-Agent"\")",
"url": "http://webconcepts.info/concepts/http-header/User-Agent"
},
"Sec-WebSocket-Accept": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [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.](http://tools.ietf.org/html/rfc6455#section-11.3.3 \"Read documentation for HTTP Header Field "Sec-WebSocket-Accept"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-WebSocket-Accept"
},
"Referer": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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).](http://tools.ietf.org/html/rfc7231#section-5.5.2 \"Read documentation for HTTP Header Field "Referer"\")",
"url": "http://webconcepts.info/concepts/http-header/Referer"
},
"Cookie": {
"details": "[RFC 6265: HTTP State Management Mechanism](/specs/IETF/RFC/6265 \"This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.\"):** [The user agent sends stored cookies to the origin server in the Cookie header.](http://tools.ietf.org/html/rfc6265#section-4.2 \"Read documentation for HTTP Header Field "Cookie"\")",
"url": "http://webconcepts.info/concepts/http-header/Cookie"
},
"Access-Control-Request-Method": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [The Access-Control-Request-Method header indicates which method will be used in the actual request as part of the preflight request.](http://www.w3.org/TR/cors/#access-control-request-method-request-header \"Read documentation for HTTP Header Field "Access-Control-Request-Method"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Request-Method"
},
"CH": {
"details": "[Internet Draft grigorik-http-client-hints: HTTP Client Hints](/specs/IETF/I-D/grigorik-http-client-hints \"An increasing diversity of connected device form factors and software capabilities has created a need to deliver varying, or optimized content for each device. Client Hints can be used as input to proactive content negotiation; just as the Accept header allowed clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"CH\" request header field describes an example list of client preferences that the server can use to adapt and optimize the resource to satisfy a given request. The CH field-value is a comma-delimited list of header fields, and the field-name values are case insensitive.](http://tools.ietf.org/html/draft-grigorik-http-client-hints#section-2 \"Read documentation for HTTP Header Field "CH"\")",
"url": "http://webconcepts.info/concepts/http-header/CH"
},
"Accept-Ranges": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [The \"Accept-Ranges\" header field allows a server to indicate that it supports range requests for the target resource.](http://tools.ietf.org/html/rfc7233#section-2.3 \"Read documentation for HTTP Header Field "Accept-Ranges"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Ranges"
},
"ETag": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-2.3 \"Read documentation for HTTP Header Field "ETag"\")",
"url": "http://webconcepts.info/concepts/http-header/ETag"
},
"TE": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [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.](http://tools.ietf.org/html/rfc7230#section-4.3 \"Read documentation for HTTP Header Field "TE"\")",
"url": "http://webconcepts.info/concepts/http-header/TE"
},
"Access-Control-Allow-Headers": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [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.](http://www.w3.org/TR/cors/#access-control-allow-headers-response-header \"Read documentation for HTTP Header Field "Access-Control-Allow-Headers"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Allow-Headers"
},
"C-PEP": {
"details": "[W3C TR http://www.w3.org/TR/WD-http-pep: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep \" HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.\"):** [PEP 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.](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743948 \"Read documentation for HTTP Header Field "C-PEP"\")",
"url": "http://webconcepts.info/concepts/http-header/C-PEP"
},
"Cache-NT": {
"details": "[Internet Draft drechsler-httpbis-improved-caching: Hypertext Transfer Protocol: Improved HTTP Caching](/specs/IETF/I-D/drechsler-httpbis-improved-caching \"This document describes an improved HTTP caching method which can be applied in addition to the standard caching behavior for HTTP. It defines the associated header field that controls this improved caching mechanism and a modified caching operation which is slightly different to standard caching operation for HTTP.\"):** [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.](http://tools.ietf.org/html/draft-drechsler-httpbis-improved-caching#section-2.1 \"Read documentation for HTTP Header Field "Cache-NT"\")",
"url": "http://webconcepts.info/concepts/http-header/Cache-NT"
},
"Retry-After": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-7.1.3 \"Read documentation for HTTP Header Field "Retry-After"\")",
"url": "http://webconcepts.info/concepts/http-header/Retry-After"
},
"Key": {
"details": "[Internet Draft ietf-httpbis-key: The Key HTTP Response Header Field](/specs/IETF/I-D/ietf-httpbis-key \"The 'Key' header field for HTTP responses allows an origin server to describe the cache key for a negotiated response: a short algorithm that can be used upon later requests to determine if the same response is reusable. Key has the advantage of avoiding an additional round trip for validation whenever a new request differs slightly, but not significantly, from prior requests. Key also informs user agents of the request characteristics that might result in different content, which can be useful if the user agent is not sending Accept* fields in order to reduce the risk of fingerprinting.\"):** [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\".](http://tools.ietf.org/html/draft-ietf-httpbis-key#section-2 \"Read documentation for HTTP Header Field "Key"\")",
"url": "http://webconcepts.info/concepts/http-header/Key"
},
"C-Opt": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [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.](http://tools.ietf.org/html/rfc2774#section-4.2 \"Read documentation for HTTP Header Field "C-Opt"\")",
"url": "http://webconcepts.info/concepts/http-header/C-Opt"
},
"Want-Digest": {
"details": "[RFC 3230: Instance Digests in HTTP](/specs/IETF/RFC/3230 \"HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.\"):** [The Want-Digest message header field indicates the sender's desire to receive an instance digest on messages associated with the Request-URI.](http://tools.ietf.org/html/rfc3230#section-4.3.1 \"Read documentation for HTTP Header Field "Want-Digest"\")",
"url": "http://webconcepts.info/concepts/http-header/Want-Digest"
},
"Sec-WebSocket-Key": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [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.](http://tools.ietf.org/html/rfc6455#section-11.3.1 \"Read documentation for HTTP Header Field "Sec-WebSocket-Key"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-WebSocket-Key"
},
"Push-Policy": {
"details": "[Internet Draft ruellan-http-accept-push-policy: Accept-Push-Policy Header Field](/specs/IETF/I-D/ruellan-http-accept-push-policy \"The "Accept-Push-Policy" and "Push-Policy" header fields enable a client and a server to negotiate the behaviour of the server regarding the usage of push on a per-request basis.\"):** [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.](http://tools.ietf.org/html/draft-ruellan-http-accept-push-policy#section-3.2 \"Read documentation for HTTP Header Field "Push-Policy"\")",
"url": "http://webconcepts.info/concepts/http-header/Push-Policy"
},
"Cache-Control": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [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.](http://tools.ietf.org/html/rfc7234#section-5.2 \"Read documentation for HTTP Header Field "Cache-Control"\")",
"url": "http://webconcepts.info/concepts/http-header/Cache-Control"
},
"Set-Cookie": {
"details": "[RFC 6265: HTTP State Management Mechanism](/specs/IETF/RFC/6265 \"This document defines the HTTP Cookie and Set-Cookie header fields. These header fields can be used by HTTP servers to store state (called cookies) at HTTP user agents, letting the servers maintain a stateful session over the mostly stateless HTTP protocol. Although cookies have many historical infelicities that degrade their security and privacy, the Cookie and Set-Cookie header fields are widely used on the Internet.\"):** [The Set-Cookie HTTP response header is used to send cookies from the server to the user agent.](http://tools.ietf.org/html/rfc6265#section-4.1 \"Read documentation for HTTP Header Field "Set-Cookie"\")",
"url": "http://webconcepts.info/concepts/http-header/Set-Cookie"
},
"Content-Security-Policy-Report-Only-Pin": {
"details": "[W3C TR http://www.w3.org/TR/csp-pinning: Content Security Policy Pinning](/specs/W3C/TR/csp-pinning \"This document defines a new HTTP header that allows authors to instruct user agents to remember ("pin") and enforce a Content Security Policy for a set of hosts for a period of time.\"):** [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).](http://www.w3.org/TR/csp-pinning/#content-security-policy-report-only-pin-header-field \"Read documentation for HTTP Header Field "Content-Security-Policy-Report-Only-Pin"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Security-Policy-Report-Only-Pin"
},
"Lock-Token": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed.](http://tools.ietf.org/html/rfc4918#section-10.5 \"Read documentation for HTTP Header Field "Lock-Token"\")",
"url": "http://webconcepts.info/concepts/http-header/Lock-Token"
},
"Clear-Site-Data": {
"details": "[W3C TR http://www.w3.org/TR/clear-site-data: Clear Site Data](/specs/W3C/TR/clear-site-data \"This document defines an imperative mechanism which allows web developers to instruct a user agent to clear a user's locally stored data related to a host and its subdomains.\"):** [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.](http://www.w3.org/TR/clear-site-data/#header \"Read documentation for HTTP Header Field "Clear-Site-Data"\")",
"url": "http://webconcepts.info/concepts/http-header/Clear-Site-Data"
},
"Signature": {
"details": "[Internet Draft cavage-http-signatures: Signing HTTP Messages](/specs/IETF/I-D/cavage-http-signatures \"When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.\"):** [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.](http://tools.ietf.org/html/draft-cavage-http-signatures#section-4 \"Read documentation for HTTP Header Field "Signature"\")",
"url": "http://webconcepts.info/concepts/http-header/Signature"
},
"Content-Language": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-3.1.3.2 \"Read documentation for HTTP Header Field "Content-Language"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Language"
},
"Date": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-7.1.1.2 \"Read documentation for HTTP Header Field "Date"\")",
"url": "http://webconcepts.info/concepts/http-header/Date"
},
"Authorization": {
"details": "[RFC 5849: The OAuth 1.0 Protocol](/specs/IETF/RFC/5849 \"OAuth provides a method for clients to access server resources on behalf of a resource owner (such as a different client or an end-user). It also provides a process for end-users to authorize third-party access to their server resources without sharing their credentials (typically, a username and password pair), using user-agent redirections.\"):** [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).](http://tools.ietf.org/html/rfc5849#section-3.5.1 \"Read documentation for HTTP Header Field "Authorization"\")\n\n**[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [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.](http://tools.ietf.org/html/rfc7235#section-4.1 \"Read documentation for HTTP Header Field "Authorization"\")\n\n**[RFC 7616: HTTP Digest Access Authentication](/specs/IETF/RFC/7616 \"The Hypertext Transfer Protocol (HTTP) provides a simple challenge-response authentication mechanism that may be used by a server to challenge a client request and by a client to provide authentication information. This document defines the HTTP Digest Authentication scheme that can be used with the HTTP authentication mechanism.\"):** [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.](http://tools.ietf.org/html/rfc7616#section-3.4 \"Read documentation for HTTP Header Field "Authorization"\")",
"url": "http://webconcepts.info/concepts/http-header/Authorization"
},
"Set-Cookie2": {
"details": "[RFC 2965: HTTP State Management Mechanism](/specs/IETF/RFC/2965 \"This document specifies a way to create a stateful session with Hypertext Transfer Protocol (HTTP) requests and responses. It describes three new headers, Cookie, Cookie2, and Set-Cookie2, which carry state information between participating origin servers and user agents. The method described here differs from Netscape's Cookie proposal [Netscape], but it can interoperate with HTTP/1.0 user agents that use Netscape's method.\"):** [The origin server initiates a session, if it so desires. To do so, it returns an extra response header to the client, Set-Cookie2.](http://tools.ietf.org/html/rfc2965#section-3.2 \"Read documentation for HTTP Header Field "Set-Cookie2"\")",
"url": "http://webconcepts.info/concepts/http-header/Set-Cookie2"
},
"Variant-Vary": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [The Variant-Vary response header can be used in a choice response to record any vary information which applies to the variant data (the entity body combined with some of the entity headers) contained in the response, rather than to the response as a whole.](http://tools.ietf.org/html/rfc2295#section-8.6 \"Read documentation for HTTP Header Field "Variant-Vary"\")",
"url": "http://webconcepts.info/concepts/http-header/Variant-Vary"
},
"Trailer": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [When a message includes a message body encoded with the chunked transfer coding and the sender desires to send metadata in the form of trailer fields at the end of the message, the sender SHOULD generate a Trailer header field before the message body to indicate which fields will be present in the trailers.](http://tools.ietf.org/html/rfc7230#section-4.4 \"Read documentation for HTTP Header Field "Trailer"\")",
"url": "http://webconcepts.info/concepts/http-header/Trailer"
},
"Content-Version": {
"details": "[RFC 2068: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".\"):** [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.](http://tools.ietf.org/html/rfc2068#section-19.6.2.2 \"Read documentation for HTTP Header Field "Content-Version"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Version"
},
"Surrogate-Capability": {
"details": "[W3C TR http://www.w3.org/TR/edge-arch: Edge Architecture Specification](/specs/W3C/TR/edge-arch \"This document defines the Edge Architecture, which extend the Web infrastructure through the use of HTTP surrogates - intermediaries that act on behalf of an origin server.\"):** [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.](http://www.w3.org/TR/edge-arch/ \"Read documentation for HTTP Header Field "Surrogate-Capability"\")",
"url": "http://webconcepts.info/concepts/http-header/Surrogate-Capability"
},
"Proxy-Authenticate": {
"details": "[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [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.](http://tools.ietf.org/html/rfc7235#section-4.2 \"Read documentation for HTTP Header Field "Proxy-Authenticate"\")",
"url": "http://webconcepts.info/concepts/http-header/Proxy-Authenticate"
},
"Access-Control-Allow-Methods": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [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.](http://www.w3.org/TR/cors/#access-control-allow-methods-response-header \"Read documentation for HTTP Header Field "Access-Control-Allow-Methods"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Allow-Methods"
},
"Range": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [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.](http://tools.ietf.org/html/rfc7233#section-3.1 \"Read documentation for HTTP Header Field "Range"\")",
"url": "http://webconcepts.info/concepts/http-header/Range"
},
"POE": {
"details": "[Internet Draft nottingham-http-poe: POST Once Exactly (POE)](/specs/IETF/I-D/nottingham-http-poe \"This specification describes a pattern of use that allows HTTP clients to automatically retry POST requests in a manner that assures no unintended side effects will take place, and defines mechanisms to allow implementations to automatically determine when such patterns are supported.\"):** [The POE HTTP header is a request-header field whose field-value indicates the version of POE that a client supports.](https://tools.ietf.org/html/draft-nottingham-http-poe-00#section-4 \"Read documentation for HTTP Header Field "POE"\")",
"url": "http://webconcepts.info/concepts/http-header/POE"
},
"Access-Control-Max-Age": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached in a preflight result cache.](http://www.w3.org/TR/cors/#access-control-max-age-response-header \"Read documentation for HTTP Header Field "Access-Control-Max-Age"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Max-Age"
},
"Connection": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [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.](http://tools.ietf.org/html/rfc7230#section-6.1 \"Read documentation for HTTP Header Field "Connection"\")",
"url": "http://webconcepts.info/concepts/http-header/Connection"
},
"Content-Encoding": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-3.1.2.2 \"Read documentation for HTTP Header Field "Content-Encoding"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Encoding"
},
"Position": {
"details": "[RFC 3648: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol](/specs/IETF/RFC/3648 \"This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.\"):** [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.](http://tools.ietf.org/html/rfc3648#section-6.1 \"Read documentation for HTTP Header Field "Position"\")",
"url": "http://webconcepts.info/concepts/http-header/Position"
},
"If": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [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.](http://tools.ietf.org/html/rfc4918#section-10.4 \"Read documentation for HTTP Header Field "If"\")",
"url": "http://webconcepts.info/concepts/http-header/If"
},
"Tunnel-Protocol": {
"details": "[Internet Draft ietf-httpbis-tunnel-protocol: The Tunnel-Protocol HTTP Header Field](/specs/IETF/I-D/ietf-httpbis-tunnel-protocol \"This specification allows HTTP CONNECT requests to indicate what protocol will be used within the tunnel once established, using the Tunnel-Protocol header field.\"):** [Clients include the Tunnel-Protocol header field in an HTTP CONNECT request to indicate the application layer protocol that will be used within the tunnel, or the set of protocols that might be used within the tunnel.](http://tools.ietf.org/html/draft-ietf-httpbis-tunnel-protocol#section-2 \"Read documentation for HTTP Header Field "Tunnel-Protocol"\")",
"url": "http://webconcepts.info/concepts/http-header/Tunnel-Protocol"
},
"Sec-COWL": {
"details": "[W3C TR http://www.w3.org/TR/COWL: Confinement with Origin Web Labels](/specs/W3C/TR/COWL \"This specification defines an API for specifying privacy and integrity policies on data, in the form of origin labels, and a mechanism for confining code according to such policies. This allows Web application authors and server operators to share data with untrusted—buggy but not malicious—code (e.g., in a mashup scenario) yet impose restrictions on how the code can share the data further.\"):** [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.](http://www.w3.org/TR/COWL/#header \"Read documentation for HTTP Header Field "Sec-COWL"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-COWL"
},
"Label": {
"details": "[RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)](/specs/IETF/RFC/3253 \"This document specifies a set of methods, headers, and resource types that define the WebDAV (Web Distributed Authoring and Versioning) versioning extensions to the HTTP/1.1 protocol. WebDAV versioning will minimize the complexity of clients that are capable of interoperating with a variety of versioning repository managers, to facilitate widespread deployment of applications capable of utilizing the WebDAV Versioning services. WebDAV versioning includes automatic versioning for versioning-unaware clients, version history management, workspace management, baseline management, activity management, and URL namespace versioning.\"):** [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.](http://tools.ietf.org/html/rfc3253#section-8.3 \"Read documentation for HTTP Header Field "Label"\")",
"url": "http://webconcepts.info/concepts/http-header/Label"
},
"Ordering-Type": {
"details": "[RFC 3648: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol](/specs/IETF/RFC/3648 \"This specification extends the Web Distributed Authoring and Versioning (WebDAV) Protocol to support the server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering.\"):** [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.](http://tools.ietf.org/html/rfc3648#section-5.1 \"Read documentation for HTTP Header Field "Ordering-Type"\")",
"url": "http://webconcepts.info/concepts/http-header/Ordering-Type"
},
"Accept-Charset": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-5.3.3 \"Read documentation for HTTP Header Field "Accept-Charset"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Charset"
},
"IM": {
"details": "[RFC 3229: Delta encoding in HTTP](/specs/IETF/RFC/3229 \"This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."\"):** [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.](http://tools.ietf.org/html/rfc3229#section-10.5.2 \"Read documentation for HTTP Header Field "IM"\")",
"url": "http://webconcepts.info/concepts/http-header/IM"
},
"Age": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [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.](http://tools.ietf.org/html/rfc7234#section-5.1 \"Read documentation for HTTP Header Field "Age"\")",
"url": "http://webconcepts.info/concepts/http-header/Age"
},
"Safe": {
"details": "[RFC 2310: The Safe Response Header Field](/specs/IETF/RFC/2310 \"This document defines a HTTP response header field called Safe, which can be used to indicate that repeating a HTTP request is safe. Such an indication will allow user agents to handle retries of some safe requests, in particular safe POST requests, in a more user-friendly way.\"):** [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.](http://tools.ietf.org/html/rfc2310#section-4 \"Read documentation for HTTP Header Field "Safe"\")",
"url": "http://webconcepts.info/concepts/http-header/Safe"
},
"Accept-Post": {
"details": "[W3C TR http://www.w3.org/TR/ldp: Linked Data Platform 1.0 (LDP)](/specs/W3C/TR/ldp \"Linked Data Platform (LDP) defines a set of rules for HTTP operations on web resources, some based on RDF, to provide an architecture for read-write Linked Data on the web.\"):** [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.](http://www.w3.org/TR/ldp/#header-accept-post \"Read documentation for HTTP Header Field "Accept-Post"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Post"
},
"Origin": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [The Origin header indicates where the cross-origin request or preflight request originates from.](http://www.w3.org/TR/cors/#origin-request-header \"Read documentation for HTTP Header Field "Origin"\")",
"url": "http://webconcepts.info/concepts/http-header/Origin"
},
"P3P": {
"details": "[W3C TR http://www.w3.org/TR/P3P: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification](/specs/W3C/TR/P3P \"This is the specification of the Platform for Privacy Preferences (P3P). This document, along with its normative references, includes all the specification necessary for the implementation of interoperable P3P applications.\"):** [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.](http://www.w3.org/TR/P3P/#syntax_ext \"Read documentation for HTTP Header Field "P3P"\")",
"url": "http://webconcepts.info/concepts/http-header/P3P"
},
"Max-Forwards": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-5.1.2 \"Read documentation for HTTP Header Field "Max-Forwards"\")",
"url": "http://webconcepts.info/concepts/http-header/Max-Forwards"
},
"Ext": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled.](http://tools.ietf.org/html/rfc2774#section-4.3 \"Read documentation for HTTP Header Field "Ext"\")",
"url": "http://webconcepts.info/concepts/http-header/Ext"
},
"Content-Security-Policy-Report-Only": {
"details": "[W3C TR http://www.w3.org/TR/CSP2: Content Security Policy Level 2](/specs/W3C/TR/CSP2 \"This document defines a policy language used to declare a set of content restrictions for a web resource, and a mechanism for transmitting the policy from a server to a client where the policy is enforced.\"):** [The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy.](http://www.w3.org/TR/CSP2/#content-security-policy-report-only-header-field \"Read documentation for HTTP Header Field "Content-Security-Policy-Report-Only"\")\n\n**[W3C TR http://www.w3.org/TR/CSP3: Content Security Policy Level 3](/specs/W3C/TR/CSP3 \"This document defines a mechanism by which web developers can control the resources which a particular page can fetch or execute, as well as a number of security-relevant policy decisions.\"):** [The Content-Security-Policy-Report-Only HTTP response header field allows web developers to experiment with policies by monitoring (but not enforcing) their effects.](http://www.w3.org/TR/CSP3/#cspro-header \"Read documentation for HTTP Header Field "Content-Security-Policy-Report-Only"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Security-Policy-Report-Only"
},
"Surrogate-Control": {
"details": "[W3C TR http://www.w3.org/TR/edge-arch: Edge Architecture Specification](/specs/W3C/TR/edge-arch \"This document defines the Edge Architecture, which extend the Web infrastructure through the use of HTTP surrogates - intermediaries that act on behalf of an origin server.\"):** [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.](http://www.w3.org/TR/edge-arch/ \"Read documentation for HTTP Header Field "Surrogate-Control"\")",
"url": "http://webconcepts.info/concepts/http-header/Surrogate-Control"
},
"Nice": {
"details": "[Internet Draft thomson-http-nice: Marking HTTP Requests as Unimportant](/specs/IETF/I-D/thomson-http-nice \"An HTTP "Nice" header field is defined that marks a request as low priority. Intermediaries can choose to discard the request or serve it from cache rather than forwarding it to an origin server. This enables constrained origin servers, such as those that rely on battery power, to avoid expending limited resources on serving requests.\"):** [The \"Nice\" header field indicates that a request is less important than a request that doesn't bear this header.](http://tools.ietf.org/html/draft-thomson-http-nice#section-2 \"Read documentation for HTTP Header Field "Nice"\")",
"url": "http://webconcepts.info/concepts/http-header/Nice"
},
"Warning": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"Warning\" header field is used to carry additional information about the status or transformation of a message that might not be reflected in the status code. This information is typically used to warn about possible incorrectness introduced by caching operations or transformations applied to the payload of the message.](http://tools.ietf.org/html/rfc7234#section-5.5 \"Read documentation for HTTP Header Field "Warning"\")",
"url": "http://webconcepts.info/concepts/http-header/Warning"
},
"URI": {
"details": "[RFC 2068: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".\"):** [The URI header field has, in past versions of this specification, been used as a combination of the existing Location, Content-Location, and Vary header fields as well as the future Alternates field. Its primary purpose has been to include a list of additional URIs for the resource, including names and mirror locations. However, it has become clear that the combination of many different functions within this single field has been a barrier to consistently and correctly implementing any of those functions. Furthermore, we believe that the identification of names and mirror locations would be better performed via the Link header field. The URI header field is therefore deprecated in favor of those other fields.](http://tools.ietf.org/html/rfc2068#section-19.6.2.5 \"Read documentation for HTTP Header Field "URI"\")",
"url": "http://webconcepts.info/concepts/http-header/URI"
},
"Crypto-Key": {
"details": "[Internet Draft ietf-httpbis-encryption-encoding: Encrypted Content-Encoding for HTTP](/specs/IETF/I-D/ietf-httpbis-encryption-encoding \"This memo introduces a content coding for HTTP that allows message payloads to be encrypted.\"):** [A Crypto-Key header field can be used to describe the input keying material used in the Encryption header field.](http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding#section-4 \"Read documentation for HTTP Header Field "Crypto-Key"\")",
"url": "http://webconcepts.info/concepts/http-header/Crypto-Key"
},
"Content-Type": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-3.1.1.5 \"Read documentation for HTTP Header Field "Content-Type"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Type"
},
"Security-Scheme": {
"details": "[RFC 2660: The Secure HyperText Transfer Protocol (S-HTTP)](/specs/IETF/RFC/2660 \"This memo describes a syntax for securing messages sent using the Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web. Secure HTTP (S-HTTP) provides independently applicable security services for transaction confidentiality, authenticity/integrity and non-repudiability of origin. The protocol emphasizes maximum flexibility in choice of key management mechanisms, security policies and cryptographic algorithms by supporting option negotiation between parties for each transaction.\"):** [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.](http://tools.ietf.org/html/rfc2660#section-4.1 \"Read documentation for HTTP Header Field "Security-Scheme"\")",
"url": "http://webconcepts.info/concepts/http-header/Security-Scheme"
},
"Accept-Encoding": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-5.3.4 \"Read documentation for HTTP Header Field "Accept-Encoding"\")\n\n**[RFC 7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding](/specs/IETF/RFC/7694 \"In HTTP, content codings allow for payload encodings such as for compression or integrity checks. In particular, the "gzip" content coding is widely used for payload data sent in response messages. Content codings can be used in request messages as well, however discoverability is not on par with response messages. This document extends the HTTP "Accept-Encoding" header field for use in responses, to indicate that content codings are supported in requests.\"):** [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.](http://tools.ietf.org/html/rfc7694#section-3 \"Read documentation for HTTP Header Field "Accept-Encoding"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Encoding"
},
"Sunset": {
"details": "[Internet Draft wilde-sunset-header: The Sunset HTTP Header](/specs/IETF/I-D/wilde-sunset-header \"This specification defines the Sunset HTTP response header field, which indicates that a URI is likely to become unresponsive at a specified point in the future.\"):** [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.](http://tools.ietf.org/html/draft-wilde-sunset-header#section-3 \"Read documentation for HTTP Header Field "Sunset"\")",
"url": "http://webconcepts.info/concepts/http-header/Sunset"
},
"Proxy-Instruction": {
"details": "[W3C TR http://www.w3.org/TR/WD-proxy: Notification for Proxy Caches](/specs/W3C/TR/WD-proxy \"A mechanism to enable better functioning of proxies is proposed. This mechanism allows proxies to inform a remote server about transactions performed using the cache and for servers to inform proxies when data becomes stale.\"):** [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.](http://www.w3.org/TR/WD-proxy \"Read documentation for HTTP Header Field "Proxy-Instruction"\")",
"url": "http://webconcepts.info/concepts/http-header/Proxy-Instruction"
},
"Public-Key-Pins": {
"details": "[RFC 7469: Public Key Pinning Extension for HTTP](/specs/IETF/RFC/7469 \"This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.\"):** [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.](http://tools.ietf.org/html/rfc7469#section-2.5 \"Read documentation for HTTP Header Field "Public-Key-Pins"\")",
"url": "http://webconcepts.info/concepts/http-header/Public-Key-Pins"
},
"HTTPS": {
"details": "[W3C TR http://www.w3.org/TR/upgrade-insecure-requests: Upgrade Insecure Requests](/specs/W3C/TR/upgrade-insecure-requests \"This document defines a mechanism which allows authors to instruct a user agent to upgrade a priori insecure resource requests to secure transport before fetching them.\"):** [The HTTPS HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.](http://www.w3.org/TR/upgrade-insecure-requests/#preference \"Read documentation for HTTP Header Field "HTTPS"\")",
"url": "http://webconcepts.info/concepts/http-header/HTTPS"
},
"Transfer-Encoding": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The Transfer-Encoding header field lists the transfer coding names corresponding to the sequence of transfer codings that have been (or will be) applied to the payload body in order to form the message body.](http://tools.ietf.org/html/rfc7230#section-3.3.1 \"Read documentation for HTTP Header Field "Transfer-Encoding"\")",
"url": "http://webconcepts.info/concepts/http-header/Transfer-Encoding"
},
"From": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The \"From\" header field contains an Internet email address for a human user who controls the requesting user agent.](http://tools.ietf.org/html/rfc7231#section-5.5.1 \"Read documentation for HTTP Header Field "From"\")",
"url": "http://webconcepts.info/concepts/http-header/From"
},
"Public-Key-Pins-Report-Only": {
"details": "[RFC 7469: Public Key Pinning Extension for HTTP](/specs/IETF/RFC/7469 \"This document defines a new HTTP header that allows web host operators to instruct user agents to remember ("pin") the hosts' cryptographic identities over a period of time. During that time, user agents (UAs) will require that the host presents a certificate chain including at least one Subject Public Key Info structure whose fingerprint matches one of the pinned fingerprints for that host. By effectively reducing the number of trusted authorities who can authenticate the domain during the lifetime of the pin, pinning may reduce the incidence of man-in-the-middle attacks due to compromised Certification Authorities.\"):** [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.](http://tools.ietf.org/html/rfc7469#section-2.5 \"Read documentation for HTTP Header Field "Public-Key-Pins-Report-Only"\")",
"url": "http://webconcepts.info/concepts/http-header/Public-Key-Pins-Report-Only"
},
"Alternates": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [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.](http://tools.ietf.org/html/rfc2295#section-8.3 \"Read documentation for HTTP Header Field "Alternates"\")",
"url": "http://webconcepts.info/concepts/http-header/Alternates"
},
"Digest": {
"details": "[RFC 3230: Instance Digests in HTTP](/specs/IETF/RFC/3230 \"HTTP/1.1 defines a Content-MD5 header that allows a server to include a digest of the response body. However, this is specifically defined to cover the body of the actual message, not the contents of the full file (which might be quite different, if the response is a Content-Range, or uses a delta encoding). Also, the Content-MD5 is limited to one specific digest algorithm; other algorithms, such as SHA-1 (Secure Hash Standard), may be more appropriate in some circumstances. Finally, HTTP/1.1 provides no explicit mechanism by which a client may request a digest. This document proposes HTTP extensions that solve these problems.\"):** [The Digest message header field provides a message digest of the instance described by the message.](http://tools.ietf.org/html/rfc3230#section-4.3.2 \"Read documentation for HTTP Header Field "Digest"\")",
"url": "http://webconcepts.info/concepts/http-header/Digest"
},
"Access-Control-Allow-Credentials": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [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.](http://www.w3.org/TR/cors/#access-control-allow-credentials-response-header \"Read documentation for HTTP Header Field "Access-Control-Allow-Credentials"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Allow-Credentials"
},
"Depth": {
"details": "[RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)](/specs/IETF/RFC/4918 \"Web Distributed Authoring and Versioning (WebDAV) consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, URL namespace manipulation, and resource locking (collision avoidance).\"):** [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\").](http://tools.ietf.org/html/rfc4918#section-10.2 \"Read documentation for HTTP Header Field "Depth"\")",
"url": "http://webconcepts.info/concepts/http-header/Depth"
},
"Via": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"Via\" header field indicates the presence of intermediate protocols and recipients between the user agent and the server (on requests) or between the origin server and the client (on responses), similar to the \"Received\" header field in email (Section 3.6.7 of RFC 5322). Via can be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of senders along the request/response chain.](http://tools.ietf.org/html/rfc7230#section-5.7.1 \"Read documentation for HTTP Header Field "Via"\")",
"url": "http://webconcepts.info/concepts/http-header/Via"
},
"Access-Control-Request-Headers": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [The Access-Control-Request-Headers header indicates which headers will be used in the actual request as part of the preflight request.](http://www.w3.org/TR/cors/#access-control-request-headers-request-header \"Read documentation for HTTP Header Field "Access-Control-Request-Headers"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Request-Headers"
},
"Vary": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [The \"Vary\" header field in a response describes what parts of a request message, aside from the method, Host header field, and request target, might influence the origin server's process for selecting and representing this response. The value consists of either a single asterisk (\"*\") or a list of header field names (case-insensitive).](http://tools.ietf.org/html/rfc7231#section-7.1.4 \"Read documentation for HTTP Header Field "Vary"\")",
"url": "http://webconcepts.info/concepts/http-header/Vary"
},
"C-Man": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [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.](http://tools.ietf.org/html/rfc2774#section-4.2 \"Read documentation for HTTP Header Field "C-Man"\")",
"url": "http://webconcepts.info/concepts/http-header/C-Man"
},
"Accept-Patch": {
"details": "[RFC 5789: PATCH Method for HTTP](/specs/IETF/RFC/5789 \"Several applications extending the Hypertext Transfer Protocol (HTTP) require a feature to do partial resource modification. The existing HTTP PUT method only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.\"):** [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.](http://tools.ietf.org/html/rfc5789#section-3.1 \"Read documentation for HTTP Header Field "Accept-Patch"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Patch"
},
"Accept-Push-Policy": {
"details": "[Internet Draft ruellan-http-accept-push-policy: Accept-Push-Policy Header Field](/specs/IETF/I-D/ruellan-http-accept-push-policy \"The "Accept-Push-Policy" and "Push-Policy" header fields enable a client and a server to negotiate the behaviour of the server regarding the usage of push on a per-request basis.\"):** [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.](http://tools.ietf.org/html/draft-ruellan-http-accept-push-policy#section-3.1 \"Read documentation for HTTP Header Field "Accept-Push-Policy"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Push-Policy"
},
"Viewport-Width": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"Viewport-Width\" header field is a number that, in requests, indicates the layout viewport width in CSS px.](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-5 \"Read documentation for HTTP Header Field "Viewport-Width"\")",
"url": "http://webconcepts.info/concepts/http-header/Viewport-Width"
},
"Sec-WebSocket-Version": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [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.](http://tools.ietf.org/html/rfc6455#section-11.3.5 \"Read documentation for HTTP Header Field "Sec-WebSocket-Version"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-WebSocket-Version"
},
"Subst": {
"details": "[Internet Draft mogul-http-dupsup: Duplicate Suppression in HTTP](/specs/IETF/I-D/mogul-http-dupsup \"A significant fraction of Web content is often exactly duplicated under several different URIs. This duplication can lead to suboptimal use of network bandwidth, and unnecessary latency for users. Much of this duplication can be avoided through the use of a simple mechanism, described here, which allows a cache to efficiently substitute one byte-for-byte identical value for another. By doing so, the cache avoids some or all of the network costs associated with retrieving the duplicate value.\"):** [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.](http://tools.ietf.org/html/draft-mogul-http-dupsup#section-5.2.2 \"Read documentation for HTTP Header Field "Subst"\")",
"url": "http://webconcepts.info/concepts/http-header/Subst"
},
"If-Unmodified-Since": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-3.4 \"Read documentation for HTTP Header Field "If-Unmodified-Since"\")",
"url": "http://webconcepts.info/concepts/http-header/If-Unmodified-Since"
},
"If-Schedule-Tag-Match": {
"details": "[RFC 6638: Scheduling Extensions to CalDAV](/specs/IETF/RFC/6638 \"This document defines extensions to the Calendaring Extensions to WebDAV (CalDAV) "calendar-access" feature to specify a standard way of performing scheduling operations with iCalendar-based calendar components. This document defines the "calendar-auto-schedule" feature of CalDAV.\"):** [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.](http://tools.ietf.org/html/rfc6638#section-8.3 \"Read documentation for HTTP Header Field "If-Schedule-Tag-Match"\")",
"url": "http://webconcepts.info/concepts/http-header/If-Schedule-Tag-Match"
},
"Last-Event-ID": {
"details": "[W3C TR http://www.w3.org/TR/eventsource: Server-Sent Events](/specs/W3C/TR/eventsource \" specification defines an API for opening an HTTP connection for receiving push notifications from a server in the form of DOM events. The API is designed such that it can be extended to work with other push notification schemes such as Push SMS.\"):** [The Last-Event-ID HTTP header specifies the value of the event source's last event ID string, encoded as UTF-8.](http://www.w3.org/TR/eventsource/#last-event-id \"Read documentation for HTTP Header Field "Last-Event-ID"\")",
"url": "http://webconcepts.info/concepts/http-header/Last-Event-ID"
},
"Content-Signature": {
"details": "[Internet Draft thomson-http-content-signature: Content-Signature Header Field for HTTP](/specs/IETF/I-D/thomson-http-content-signature \"A Content-Signature header field is defined for use in HTTP. This header field carries a signature of the payload body of a message.\"):** [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.](http://tools.ietf.org/html/draft-thomson-http-content-signature#section-2 \"Read documentation for HTTP Header Field "Content-Signature"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Signature"
},
"PEP-Info": {
"details": "[W3C TR http://www.w3.org/TR/WD-http-pep: PEP - An Extension Mechanism for HTTP](/specs/W3C/TR/WD-http-pep \" HTTP is used increasingly in applications that need more facilities than the standard version of the protocol provides, ranging from distributed authoring, collaboration, and printing, to various remote procedure call mechanisms. The Protocol Extension Protocol (PEP) is an extension mechanism designed to address the tension between private agreement and public specification and to accommodate extension of applications such as HTTP clients, servers, and proxies. The PEP mechanism is designed to associate each extension with a URI, and use a few new RFC 822 derived header fields to carry the extension identifier and related information between the parties involved in an extended transaction. This document defines PEP and describes the interactions between PEP and HTTP/1.1. PEP is intended to be compatible with HTTP/1.0 inasmuch as HTTP/1.1 is compatible with HTTP/1.0. It is proposed that the PEP extension mechanism be included in future versions of HTTP. The PEP extension mechanism may be applicable to other information exchange not mentioned in this document. It is recommended that readers get acquainted with section 1.4 for a suggested reading of this specification and a list of sections specific for HTTP based applications.\"):** [PEP end-to-end policies MUST be transmitted to the ultimate recipient of a message.](http://www.w3.org/TR/WD-http-pep-971121.html#_Toc404743953 \"Read documentation for HTTP Header Field "PEP-Info"\")",
"url": "http://webconcepts.info/concepts/http-header/PEP-Info"
},
"TCN": {
"details": "[RFC 2295: Transparent Content Negotiation in HTTP](/specs/IETF/RFC/2295 \"HTTP allows web site authors to put multiple versions of the same information under a single URL. Transparent content negotiation is an extensible negotiation mechanism, layered on top of HTTP, for automatically selecting the best version when the URL is accessed. This enables the smooth deployment of new web data formats and markup tags.\"):** [The TCN response header is used by a server to signal that the resource is transparently negotiated.](http://tools.ietf.org/html/rfc2295#section-8.5 \"Read documentation for HTTP Header Field "TCN"\")",
"url": "http://webconcepts.info/concepts/http-header/TCN"
},
"Expires": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [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.](http://tools.ietf.org/html/rfc7234#section-5.3 \"Read documentation for HTTP Header Field "Expires"\")",
"url": "http://webconcepts.info/concepts/http-header/Expires"
},
"Content-Length": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [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]).](http://tools.ietf.org/html/rfc7230#section-3.3.2 \"Read documentation for HTTP Header Field "Content-Length"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Length"
},
"Sec-WebSocket-Protocol": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [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.](http://tools.ietf.org/html/rfc6455#section-11.3.4 \"Read documentation for HTTP Header Field "Sec-WebSocket-Protocol"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-WebSocket-Protocol"
},
"Encryption": {
"details": "[Internet Draft ietf-httpbis-encryption-encoding: Encrypted Content-Encoding for HTTP](/specs/IETF/I-D/ietf-httpbis-encryption-encoding \"This memo introduces a content coding for HTTP that allows message payloads to be encrypted.\"):** [The \"Encryption\" HTTP header field describes the encrypted content encoding(s) that have been applied to a message payload, and therefore how those content encoding(s) can be removed.](http://tools.ietf.org/html/draft-ietf-httpbis-encryption-encoding#section-3 \"Read documentation for HTTP Header Field "Encryption"\")",
"url": "http://webconcepts.info/concepts/http-header/Encryption"
},
"Report-To": {
"details": "[W3C TR http://www.w3.org/TR/reporting-1: Reporting API 1](/specs/W3C/TR/reporting-1 \"This document defines a generic reporting framework which allows web developers to associate a set of named reporting endpoints with an origin. Various platform features (like Content Security Policy, Network Error Reporting, and others) will use these endpoints to deliver feature-specific reports in a consistent manner.\"):** [The Report-To HTTP response header field instructs the user agent to store reporting endpoints for an origin.](http://www.w3.org/TR/reporting-1/#header \"Read documentation for HTTP Header Field "Report-To"\")",
"url": "http://webconcepts.info/concepts/http-header/Report-To"
},
"Host": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [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.](http://tools.ietf.org/html/rfc7230#section-5.4 \"Read documentation for HTTP Header Field "Host"\")",
"url": "http://webconcepts.info/concepts/http-header/Host"
},
"A-IM": {
"details": "[RFC 3229: Delta encoding in HTTP](/specs/IETF/RFC/3229 \"This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."\"):** [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.](http://tools.ietf.org/html/rfc3229#section-10.5.3 \"Read documentation for HTTP Header Field "A-IM"\")",
"url": "http://webconcepts.info/concepts/http-header/A-IM"
},
"Proxy-Authentication-Info": {
"details": "[RFC 7615: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields](/specs/IETF/RFC/7615 \"This specification defines the "Authentication-Info" and "Proxy-Authentication-Info" response header fields for use in HTTP authentication schemes which need to return information once the client's authentication credentials have been accepted.\"):** [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.](http://tools.ietf.org/html/rfc7615#section-4 \"Read documentation for HTTP Header Field "Proxy-Authentication-Info"\")",
"url": "http://webconcepts.info/concepts/http-header/Proxy-Authentication-Info"
},
"If-Modified-Since": {
"details": "[RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests](/specs/IETF/RFC/7232 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.\"):** [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.](http://tools.ietf.org/html/rfc7232#section-3.3 \"Read documentation for HTTP Header Field "If-Modified-Since"\")",
"url": "http://webconcepts.info/concepts/http-header/If-Modified-Since"
},
"Content-Base": {
"details": "[RFC 2068: Hypertext Transfer Protocol - HTTP/1.1](/specs/IETF/RFC/2068 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".\"):** [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.](http://tools.ietf.org/html/rfc2068#section-14.11 \"Read documentation for HTTP Header Field "Content-Base"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Base"
},
"MIME-Version": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#appendix-A.1 \"Read documentation for HTTP Header Field "MIME-Version"\")",
"url": "http://webconcepts.info/concepts/http-header/MIME-Version"
},
"EDIINT-Features": {
"details": "[RFC 6017: Electronic Data Interchange - Internet Integration (EDIINT) Features Header Field](/specs/IETF/RFC/6017 \"With the maturity of the Electronic Data Interchange - Internet Integration (EDIINT) standards of AS1, AS2, and AS3, applications and additional features are being built upon the basic secure transport functionality. These features are not necessarily supported by all EDIINT applications and could cause potential problems with implementations. The EDIINT-Features header field provides a means to resolve these problems and support new functionality.\"):** [The EDIINT-Features header field indicates the originating user agent is capable of supporting the features listed.](http://tools.ietf.org/html/rfc6017#section-3 \"Read documentation for HTTP Header Field "EDIINT-Features"\")",
"url": "http://webconcepts.info/concepts/http-header/EDIINT-Features"
},
"Expect": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-5.1.1 \"Read documentation for HTTP Header Field "Expect"\")",
"url": "http://webconcepts.info/concepts/http-header/Expect"
},
"Status-URI": {
"details": "[RFC 2518: HTTP Extensions for Distributed Authoring - WEBDAV](/specs/IETF/RFC/2518 \"This document specifies a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance).\"):** [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.](http://tools.ietf.org/html/rfc2518#section-9.7 \"Read documentation for HTTP Header Field "Status-URI"\")",
"url": "http://webconcepts.info/concepts/http-header/Status-URI"
},
"Hobareg": {
"details": "[RFC 7486: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 \"HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.\"):** [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\".](http://tools.ietf.org/html/rfc7486#section-6.1.1 \"Read documentation for HTTP Header Field "Hobareg"\")",
"url": "http://webconcepts.info/concepts/http-header/Hobareg"
},
"Upgrade": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"Upgrade\" header field is intended to provide a simple mechanism for transitioning from HTTP/1.1 to some other protocol on the same connection. A client MAY send a list of protocols in the Upgrade header field of a request to invite the server to switch to one or more of those protocols, in order of descending preference, before sending the final response.](http://tools.ietf.org/html/rfc7230#section-6.7 \"Read documentation for HTTP Header Field "Upgrade"\")",
"url": "http://webconcepts.info/concepts/http-header/Upgrade"
},
"Delta-Base": {
"details": "[RFC 3229: Delta encoding in HTTP](/specs/IETF/RFC/3229 \"This document describes how delta encoding can be supported as a compatible extension to HTTP/1.1. Many HTTP (Hypertext Transport Protocol) requests cause the retrieval of slightly modified instances of resources for which the client already has a cache entry. Research has shown that such modifying updates are frequent, and that the modifications are typically much smaller than the actual entity. In such cases, HTTP would make more efficient use of network bandwidth if it could transfer a minimal description of the changes, rather than the entire new instance of the resource. This is called "delta encoding."\"):** [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.](http://tools.ietf.org/html/rfc3229#section-10.5.1 \"Read documentation for HTTP Header Field "Delta-Base"\")",
"url": "http://webconcepts.info/concepts/http-header/Delta-Base"
},
"Save-Data": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"Save-Data\" header field is a token that, in requests, indicates client's preference for reduced data usage, due to high transfer costs, slow connection speeds, or other reasons.](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-7 \"Read documentation for HTTP Header Field "Save-Data"\")",
"url": "http://webconcepts.info/concepts/http-header/Save-Data"
},
"ALPN": {
"details": "[RFC 7639: The ALPN HTTP Header Field](/specs/IETF/RFC/7639 \"This specification allows HTTP CONNECT requests to indicate what protocol is intended to be used within the tunnel once established, using the ALPN header field.\"):** [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.](http://tools.ietf.org/html/rfc7639#section-2 \"Read documentation for HTTP Header Field "ALPN"\")",
"url": "http://webconcepts.info/concepts/http-header/ALPN"
},
"Width": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"Width\" header field is a number that, in requests, indicates the resource width in physical px (i.e. intrinsic size of an image).](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-4 \"Read documentation for HTTP Header Field "Width"\")",
"url": "http://webconcepts.info/concepts/http-header/Width"
},
"POE-Links": {
"details": "[Internet Draft nottingham-http-poe: POST Once Exactly (POE)](/specs/IETF/I-D/nottingham-http-poe \"This specification describes a pattern of use that allows HTTP clients to automatically retry POST requests in a manner that assures no unintended side effects will take place, and defines mechanisms to allow implementations to automatically determine when such patterns are supported.\"):** [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.](https://tools.ietf.org/html/draft-nottingham-http-poe-00#section-3 \"Read documentation for HTTP Header Field "POE-Links"\")",
"url": "http://webconcepts.info/concepts/http-header/POE-Links"
},
"Link": {
"details": "[RFC 5988: Web Linking](/specs/IETF/RFC/5988 \"This document specifies relation types for Web links, and defines a registry for them. It also defines the use of such links in HTTP headers with the Link header field.\"):** [The Link entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the <LINK> element in HTML, as well as the atom:link feed-level element in Atom.](http://tools.ietf.org/html/rfc5988#section-5 \"Read documentation for HTTP Header Field "Link"\")",
"url": "http://webconcepts.info/concepts/http-header/Link"
},
"Preference-Applied": {
"details": "[RFC 7240: Prefer Header for HTTP](/specs/IETF/RFC/7240 \"This specification defines an HTTP header field that can be used by a client to request that certain behaviors be employed by a server while processing a request.\"):** [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.](http://tools.ietf.org/html/rfc7240#section-3 \"Read documentation for HTTP Header Field "Preference-Applied"\")",
"url": "http://webconcepts.info/concepts/http-header/Preference-Applied"
},
"Sec-WebSocket-Extensions": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [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.](http://tools.ietf.org/html/rfc6455#section-11.3.2 \"Read documentation for HTTP Header Field "Sec-WebSocket-Extensions"\")",
"url": "http://webconcepts.info/concepts/http-header/Sec-WebSocket-Extensions"
},
"Accept-Datetime": {
"details": "[RFC 7089: HTTP framework for time-based access to resource states - Memento](/specs/IETF/RFC/7089 \"The HTTP-based Memento framework bridges the present and past Web. It facilitates obtaining representations of prior states of a given resource by introducing datetime negotiation and TimeMaps. Datetime negotiation is a variation on content negotiation that leverages the given resource's URI and a user agent's preferred datetime. TimeMaps are lists that enumerate URIs of resources that encapsulate prior states of the given resource. The framework also facilitates recognizing a resource that encapsulates a frozen prior state of another resource.\"):** [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.](http://tools.ietf.org/html/rfc7089#section-2.1.1 \"Read documentation for HTTP Header Field "Accept-Datetime"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Datetime"
},
"Content-DPR": {
"details": "[Internet Draft ietf-httpbis-client-hints: HTTP Client Hints](/specs/IETF/I-D/ietf-httpbis-client-hints \"An increasing diversity of Web-connected devices and software capabilities has created a need to deliver optimized content for each device. This specification defines a set of HTTP request header fields, colloquially known as Client Hints, to address this. They are intended to be used as input to proactive content negotiation; just as the Accept header allows clients to indicate what formats they prefer, Client Hints allow clients to indicate a list of device and agent specific preferences.\"):** [The \"Content-DPR\" header field is a number that indicates the ratio between physical pixels over CSS px of the selected image response.](http://tools.ietf.org/html/draft-ietf-httpbis-client-hints#section-3.1 \"Read documentation for HTTP Header Field "Content-DPR"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-DPR"
},
"Server": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-7.4.2 \"Read documentation for HTTP Header Field "Server"\")",
"url": "http://webconcepts.info/concepts/http-header/Server"
},
"Accept-Additions": {
"details": "[RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)](/specs/IETF/RFC/2324 \"This document describes HTCPCP, a protocol for controlling, monitoring, and diagnosing coffee pots.\"):** [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\".](http://tools.ietf.org/html/rfc2324#section-2.2.2.1 \"Read documentation for HTTP Header Field "Accept-Additions"\")\n\n**[RFC 7168: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)](/specs/IETF/RFC/7168 \"The Hyper Text Coffee Pot Control Protocol (HTCPCP) specification does not allow for the brewing of tea, in all its variety and complexity. This paper outlines an extension to HTCPCP to allow for pots to provide networked tea-brewing facilities.\"):** [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.](http://tools.ietf.org/html/rfc7168#section-2.2.1 \"Read documentation for HTTP Header Field "Accept-Additions"\")",
"url": "http://webconcepts.info/concepts/http-header/Accept-Additions"
},
"Content-Location": {
"details": "[RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content](/specs/IETF/RFC/7231 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.\"):** [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.](http://tools.ietf.org/html/rfc7231#section-3.1.4.2 \"Read documentation for HTTP Header Field "Content-Location"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Location"
},
"Proxy-Authorization": {
"details": "[RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication](/specs/IETF/RFC/7235 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework.\"):** [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.](http://tools.ietf.org/html/rfc7235#section-4.3 \"Read documentation for HTTP Header Field "Proxy-Authorization"\")",
"url": "http://webconcepts.info/concepts/http-header/Proxy-Authorization"
},
"C-Ext": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [The C-Ext response header field is used to indicate that all hop-by-hop mandatory extension declarations in the request were fulfilled.](http://tools.ietf.org/html/rfc2774#section-4.3 \"Read documentation for HTTP Header Field "C-Ext"\")",
"url": "http://webconcepts.info/concepts/http-header/C-Ext"
},
"Opt": {
"details": "[RFC 2774: An HTTP Extension Framework](/specs/IETF/RFC/2774 \"A wide range of applications have proposed various extensions of the HTTP protocol. Current efforts span an enormous range, including distributed authoring, collaboration, printing, and remote procedure call mechanisms. These HTTP extensions are not coordinated, since there has been no standard framework for defining extensions and thus, separation of concerns. This document describes a generic extension mechanism for HTTP, which is designed to address the tension between private agreement and public specification and to accommodate extension of applications using HTTP clients, servers, and proxies. The proposal associates each extension with a globally unique identifier, and uses HTTP header fields to carry the extension identifier and related information between the parties involved in the extended communication.\"):** [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.](http://tools.ietf.org/html/rfc2774#section-4.1 \"Read documentation for HTTP Header Field "Opt"\")",
"url": "http://webconcepts.info/concepts/http-header/Opt"
},
"Access-Control-Allow-Origin": {
"details": "[W3C TR http://www.w3.org/TR/cors: Cross-Origin Resource Sharing (CORS)](/specs/W3C/TR/cors \"This document defines a mechanism to enable client-side cross-origin requests. Specifications that enable an API to make cross-origin requests to resources can use the algorithms defined by this specification. If such an API is used on http://example.org resources, a resource on http://hello-world.example can opt in using the mechanism described by this specification (e.g., specifying Access-Control-Allow-Origin: http://example.org as response header), which would allow that resource to be fetched cross-origin from http://example.org.\"):** [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.](http://www.w3.org/TR/cors/#access-control-allow-origin-response-header \"Read documentation for HTTP Header Field "Access-Control-Allow-Origin"\")",
"url": "http://webconcepts.info/concepts/http-header/Access-Control-Allow-Origin"
},
"Content-Disposition": {
"details": "[RFC 6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)](/specs/IETF/RFC/6266 \"RFC 2616 defines the Content-Disposition response header field, but points out that it is not part of the HTTP/1.1 Standard. This specification takes over the definition and registration of Content-Disposition, as used in HTTP, and clarifies internationalization aspects.\"):** [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.](http://tools.ietf.org/html/rfc6266#section-4 \"Read documentation for HTTP Header Field "Content-Disposition"\")",
"url": "http://webconcepts.info/concepts/http-header/Content-Disposition"
},
"DASL": {
"details": "[RFC 5323: Web Distributed Authoring and Versioning (WebDAV) SEARCH](/specs/IETF/RFC/5323 \"This document specifies a set of methods, headers, and properties composing Web Distributed Authoring and Versioning (WebDAV) SEARCH, an application of the HTTP/1.1 protocol to efficiently search for DAV resources based upon a set of client-supplied criteria.\"):** [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).](http://tools.ietf.org/html/rfc5323#section-9.1.1 \"Read documentation for HTTP Header Field "DASL"\")",
"url": "http://webconcepts.info/concepts/http-header/DASL"
},
"Alt-Svc": {
"details": "[RFC 7838: HTTP Alternate Services](/specs/IETF/RFC/7838 \"This document specifies "alternative services" for HTTP, which allow an origin's resources to be authoritatively available at a separate network location, possibly accessed with a different protocol configuration.\"):** [An HTTP(S) origin server can advertise the availability of alternative services to clients by adding an Alt-Svc header field to responses.](http://tools.ietf.org/html/rfc7838#section-3 \"Read documentation for HTTP Header Field "Alt-Svc"\")",
"url": "http://webconcepts.info/concepts/http-header/Alt-Svc"
},
"EPR": {
"details": "[W3C TR http://www.w3.org/TR/epr: Entry Point Regulation (EPR)](/specs/W3C/TR/epr \"Entry Point Regulation aims to mitigate the risk of reflected cross-site scripting (XSS), cross-site script inclusion (XSSI), and cross-site request forgery (CSRF) attacks by demarcating the areas of an application which are intended to be externally referencable. A specified policy is applied on external requests for all non-demarcated resources.\"):** [Servers may request the protections outlined by Entry Point Regulation (EPR) by sending an EPR HTTP response header field along with a response.](http://www.w3.org/TR/epr/#epr-header \"Read documentation for HTTP Header Field "EPR"\")",
"url": "http://webconcepts.info/concepts/http-header/EPR"
}
},
"HTTP Transfer Coding": {
"gzip": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".](http://tools.ietf.org/html/rfc7230#section-4.2.3 \"Read documentation for HTTP Transfer Coding "gzip"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/gzip"
},
"compress": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".](http://tools.ietf.org/html/rfc7230#section-4.2.1 \"Read documentation for HTTP Transfer Coding "compress"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/compress"
},
"x-compress": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"compress\" coding is an adaptive Lempel-Ziv-Welch (LZW) coding that is commonly produced by the UNIX file compression program \"compress\". A recipient SHOULD consider \"x-compress\" to be equivalent to \"compress\".](http://tools.ietf.org/html/rfc7230#section-4.2.1 \"Read documentation for HTTP Transfer Coding "x-compress"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/x-compress"
},
"deflate": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"deflate\" coding is a \"zlib\" data format containing a \"deflate\" compressed data stream that uses a combination of the Lempel-Ziv (LZ77) compression algorithm and Huffman coding.](http://tools.ietf.org/html/rfc7230#section-4.2.2 \"Read documentation for HTTP Transfer Coding "deflate"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/deflate"
},
"x-gzip": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"gzip\" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly produced by the gzip file compression program. A recipient SHOULD consider \"x-gzip\" to be equivalent to \"gzip\".](http://tools.ietf.org/html/rfc7230#section-4.2.3 \"Read documentation for HTTP Transfer Coding "x-gzip"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/x-gzip"
},
"chunked": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer containing header fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to retain connection persistence and the recipient to know when it has received the entire message.](http://tools.ietf.org/html/rfc7230#section-4.1 \"Read documentation for HTTP Transfer Coding "chunked"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/chunked"
},
"identity": {
"details": "[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1](/specs/IETF/RFC/2616 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext, such as name servers and distributed object management systems, through extension of its request methods, error codes and headers. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred. HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1", and is an update to RFC 2068.\"):** [The default (identity) encoding; the use of no transformation whatsoever. This content-coding is used only in the Accept-Encoding header, and SHOULD NOT be used in the Content-Encoding header.](http://tools.ietf.org/html/rfc2616#section-3.6 \"Read documentation for HTTP Transfer Coding "identity"\")",
"url": "http://webconcepts.info/concepts/http-transfer-coding/identity"
}
},
"HTTP Forwarded Parameter": {
"proto": {
"details": "[RFC 7239: Forwarded HTTP Extension](/specs/IETF/RFC/7239 \"This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.\"):** [The \"proto\" parameter has the value of the used protocol type.](http://tools.ietf.org/html/rfc7239#section-5.4 \"Read documentation for HTTP Forwarded Parameter "proto"\")",
"url": "http://webconcepts.info/concepts/http-forwarded-parameter/proto"
},
"by": {
"details": "[RFC 7239: Forwarded HTTP Extension](/specs/IETF/RFC/7239 \"This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.\"):** [The \"by\" parameter is used to disclose the interface where the request came in to the proxy server.](http://tools.ietf.org/html/rfc7239#section-5.1 \"Read documentation for HTTP Forwarded Parameter "by"\")",
"url": "http://webconcepts.info/concepts/http-forwarded-parameter/by"
},
"for": {
"details": "[RFC 7239: Forwarded HTTP Extension](/specs/IETF/RFC/7239 \"This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.\"):** [The \"for\" parameter is used to disclose information about the client that initiated the request and subsequent proxies in a chain of proxies.](http://tools.ietf.org/html/rfc7239#section-5.2 \"Read documentation for HTTP Forwarded Parameter "for"\")",
"url": "http://webconcepts.info/concepts/http-forwarded-parameter/for"
},
"host": {
"details": "[RFC 7239: Forwarded HTTP Extension](/specs/IETF/RFC/7239 \"This document defines an HTTP extension header field that allows proxy components to disclose information lost in the proxying process, for example, the originating IP address of a request or IP address of the proxy on the user-agent-facing interface. In a path of proxying components, this makes it possible to arrange it so that each subsequent component will have access to, for example, all IP addresses used in the chain of proxied HTTP requests. This document also specifies guidelines for a proxy administrator to anonymize the origin of a request.\"):** [The \"host\" parameter is used to forward the original value of the \"Host\" header field.](http://tools.ietf.org/html/rfc7239#section-5.3 \"Read documentation for HTTP Forwarded Parameter "host"\")",
"url": "http://webconcepts.info/concepts/http-forwarded-parameter/host"
}
},
"Well-Known URI": {
"carddav": {
"details": "[RFC 6764: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)](/specs/IETF/RFC/6764 \"This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.\"):** [\"caldav\" and \"carddav\" \".well-known\" URIs point to a resource that the client can use as the initial \"context path\" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual \"context path\" using one of the available mechanisms provided by HTTP (e.g., using a 301, 303, or 307 response). Clients MUST handle HTTP redirects on the \".well-known\" URI. Servers MUST NOT locate the actual CalDAV or CardDAV service endpoint at the \".well-known\" URI.](http://tools.ietf.org/html/rfc6764#section-5 \"Read documentation for Well-Known URI "carddav"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/carddav"
},
"stun-key": {
"details": "[RFC 7635: Session Traversal Utilities for NAT (STUN) Extension](/specs/IETF/RFC/7635 \"This document proposes the use of OAuth 2.0 to obtain and validate ephemeral tokens that can be used for Session Traversal Utilities for NAT (STUN) authentication. The usage of ephemeral tokens ensures that access to a STUN server can be controlled even if the tokens are compromised.\"):** [The STUN and AS servers could choose to use Representational State Transfer (REST) API over HTTPS to establish a long-term symmetric key. HTTPS MUST be used for data confidentiality, and TLS based on a client certificate MUST be used for mutual authentication. To retrieve a new long-term symmetric key, the STUN server makes an HTTP GET request to the authorization server, specifying STUN as the service to allocate the long-term symmetric keys for and specifying the name of the STUN server.](http://tools.ietf.org/html/rfc7635#section-4.1.1 \"Read documentation for Well-Known URI "stun-key"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/stun-key"
},
"timezone": {
"details": "[RFC 7808: Time Zone Data Distribution Service](/specs/IETF/RFC/7808 \"This document defines a time zone data distribution service that allows reliable, secure, and fast delivery of time zone data and leap-second rules to client systems such as calendaring and scheduling applications or operating systems.\"):** [A \"well-known\" URI is registered by this specification for the Time Zone Data Distribution service, \"timezone\". This URI points to a resource that the client can use as the initial \"context path\" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual \"context path\" using one of the available mechanisms provided by HTTP.](http://tools.ietf.org/html/rfc7808#section-4.2.1.3 \"Read documentation for Well-Known URI "timezone"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/timezone"
},
"est": {
"details": "[RFC 7030: Enrollment over Secure Transport](/specs/IETF/RFC/7030 \"This document profiles certificate enrollment for clients using Certificate Management over CMS (CMC) messages over a secure transport. This profile, called Enrollment over Secure Transport (EST), describes a simple, yet functional, certificate management protocol targeting Public Key Infrastructure (PKI) clients that need to acquire client certificates and associated Certification Authority (CA) certificates. It also supports client-generated public/private key pairs as well as key pairs generated by the CA.\"):** [The EST server MUST support the use of the path-prefix of \"/.well-known/\" and the registered name of \"est\". Thus, a valid EST server URI path begins with \"https://www.example.com/.well-known/est\". Each EST operation is indicated by a path-suffix that indicates the intended operation:](http://tools.ietf.org/html/rfc7030#section-3.2.2 \"Read documentation for Well-Known URI "est"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/est"
},
"void": {
"details": "[W3C TR http://www.w3.org/TR/void: Describing Linked Datasets with the VoID Vocabulary](/specs/W3C/TR/void \"VoID is an RDF Schema vocabulary for expressing metadata about RDF datasets. It is intended as a bridge between the publishers and users of RDF data, with applications ranging from data discovery to cataloging and archiving of datasets. This document is a detailed guide to the VoID vocabulary. It describes how VoID can be used to express general metadata based on Dublin Core, access metadata, structural metadata, and links between datasets. It also provides deployment advice and discusses the discovery of VoID descriptions.\"):** [The URI /.well-known/void on any Web server is registered by this specification for a VoID description of any datasets hosted on that server. This URI may be an HTTP redirect to the location of the actual VoID file.](http://www.w3.org/TR/void/#well-known \"Read documentation for Well-Known URI "void"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/void"
},
"hoba": {
"details": "[RFC 7486: HTTP Origin-Bound Authentication (HOBA)](/specs/IETF/RFC/7486 \"HTTP Origin-Bound Authentication (HOBA) is a digital-signature-based design for an HTTP authentication method. The design can also be used in JavaScript-based authentication embedded in HTML. HOBA is an alternative to HTTP authentication schemes that require passwords and therefore avoids all problems related to passwords, such as leakage of server-side password databases.\"):** [HOBA-http uses a well-known URI \"hoba\" as a base URI for performing many tasks: \"https://www.example.com/.well-known/hoba\". These URIs are based on the name of the host that the HTTP client is accessing.](http://tools.ietf.org/html/rfc7486#section-6 \"Read documentation for Well-Known URI "hoba"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/hoba"
},
"reload-config": {
"details": "[RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol](/specs/IETF/RFC/6940 \"This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.\"):** [If a URL for the configuration server is not provided, the node MUST do a DNS SRV query using a Service name of \"reload-config\" and a protocol of TCP to find a configuration server and form the URL by appending a path of \"/.well-known/reload-config\" to the overlay name.](https://tools.ietf.org/html/rfc6940#section-11.2 \"Read documentation for Well-Known URI "reload-config"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/reload-config"
},
"genid": {
"details": "[W3C TR http://www.w3.org/TR/rdf11-concepts: RDF 1.1 Concepts and Abstract Syntax](/specs/W3C/TR/rdf11-concepts \"The Resource Description Framework (RDF) is a framework for representing information in the Web. This document defines an abstract syntax (a data model) which serves to link all RDF-based languages and specifications. The abstract syntax has two key data structures: RDF graphs are sets of subject-predicate-object triples, where the elements may be IRIs, blank nodes, or datatyped literals. They are used to express descriptions of resources. RDF datasets are used to organize collections of RDF graphs, and comprise a default graph and zero or more named graphs. RDF 1.1 Concepts and Abstract Syntax also introduces key concepts and terminology, and discusses datatyping and the handling of fragment identifiers in IRIs within RDF graphs.\"):** [Systems that want Skolem IRIs to be recognizable outside of the system boundaries should use a well-known IRI with the registered name genid. This is an IRI that uses the HTTP or HTTPS scheme, or another scheme that has been specified to use well-known IRIs; and whose path component starts with /.well-known/genid/.](http://www.w3.org/TR/rdf11-concepts/#section-skolemization \"Read documentation for Well-Known URI "genid"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/genid"
},
"csvm": {
"details": "[W3C TR http://www.w3.org/TR/tabular-data-model: Model for Tabular Data and Metadata on the Web](/specs/W3C/TR/tabular-data-model \"Tabular data is routinely transferred on the web in a variety of formats, including variants on CSV, tab-delimited files, fixed field formats, spreadsheets, HTML tables, and SQL dumps. This document outlines a data model, or infoset, for tabular data and metadata about that tabular data that can be used as a basis for validation, display, or creating other formats. It also contains some non-normative guidance for publishing tabular data as CSV and how that maps into the tabular data model. An annotated model of tabular data can be supplemented by separate metadata about the table. This specification defines how implementations should locate that metadata, given a file containing tabular data. The standard syntax for that metadata is defined in tabular metadata. Note, however, that applications may have other means to create annotated tables, e.g., through some application specific APIs; this model does not depend on the specificities described in tabular-metadata.\"):** [If the user has not supplied a metadata file as overriding metadata and no applicable metadata file has been discovered through a Link header, processors must attempt to locate a metadata documents through site-wide configuration. In this case, processors must retrieve the file from the well-known URI /.well-known/csvm.](http://www.w3.org/TR/tabular-data-model/#site-wide-location-configuration \"Read documentation for Well-Known URI "csvm"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/csvm"
},
"core": {
"details": "[RFC 6690: Constrained RESTful Environments (CoRE) Link Format](/specs/IETF/RFC/6690 \"This specification defines Web Linking using a link format for use by constrained web servers to describe hosted resources, their attributes, and other relationships between links. Based on the HTTP Link Header field defined in RFC 5988, the Constrained RESTful Environments (CoRE) Link Format is carried as a payload and is assigned an Internet media type. "RESTful" refers to the Representational State Transfer (REST) architecture. A well-known URI is defined as a default entry point for requesting the links hosted by a server.\"):** [Resource discovery in CoRE is accomplished through the use of a well-known resource URI that returns a list of links about resources hosted by that server and other link relations. Well-known resources have a path component that begins with \"/.well-known/\" as specified in RFC 5785. This specification defines a new well-known resource for CoRE Resource Discovery: \"/.well-known/core\".](http://tools.ietf.org/html/rfc6690#section-4 \"Read documentation for Well-Known URI "core"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/core"
},
"dnt": {
"details": "[W3C TR http://www.w3.org/TR/tracking-dnt: Tracking Preference Expression (DNT)](/specs/W3C/TR/tracking-dnt \"This specification defines the technical mechanisms for expressing a tracking preference via the DNT request header field in HTTP, via an HTML DOM property readable by embedded scripts, and via properties accessible to various user agent plug-in or extension APIs. It also defines mechanisms for sites to signal whether and how they honor this preference, both in the form of a machine-readable tracking status resource at a well-known location and via a "Tk" response header field, and a mechanism for allowing the user to approve exceptions to DNT as desired.\"):** [A site-wide tracking status resource provides information about the potential tracking behavior of resources located at that origin server. A site-wide tracking status resource has the well-known identifier /.well-known/dnt/ relative to the origin server's URI.](http://www.w3.org/TR/tracking-dnt/#status-resource \"Read documentation for Well-Known URI "dnt"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/dnt"
},
"posh": {
"details": "[RFC 7711: PKIX over Secure HTTP (POSH)](/specs/IETF/RFC/7711 \"Experience has shown that it is difficult to deploy proper PKIX certificates for Transport Layer Security (TLS) in multi-tenanted environments. As a result, domains hosted in such environments often deploy applications using certificates that identify the hosting service, not the hosted domain. Such deployments force end users and peer services to accept a certificate with an improper identifier, resulting in degraded security. This document defines methods that make it easier to deploy certificates for proper server identity checking in non-HTTP application protocols. Although these methods were developed for use in the Extensible Messaging and Presence Protocol (XMPP) as a Domain Name Association (DNA) prooftype, they might also be usable in other non-HTTP application protocols.\"):** [The suffix \"posh\" is expected to be followed by an additional path component consisting of a service name (say, \"spice\") and a file extension of \".json\", resulting in a full path of, for instance, \"/.well-known/posh/spice.json\". Registration of service names shall be requested by developers of the relevant application protocols.](http://tools.ietf.org/html/rfc7711#section-9.1 \"Read documentation for Well-Known URI "posh"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/posh"
},
"repute-template": {
"details": "[RFC 7072: A Reputation Query Protocol](/specs/IETF/RFC/7072 \"This document defines a mechanism to conduct queries for reputation information over the HyperText Transfer Protocol (HTTP) using JavaScript Object Notation (JSON) as the payload meta-format.\"):** [A reputation query made via HTTP encodes the question being asked in an HTTP GET method. The specific syntax of the query itself is specified by retrieving a URI template from the reputation service, completing the template, and then issuing the query. The template file is retrieved by requesting the well-known URI \"repute-template\" from the host providing reputation service, using HTTP.](http://tools.ietf.org/html/rfc7072#section-3 \"Read documentation for Well-Known URI "repute-template"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/repute-template"
},
"webfinger": {
"details": "[RFC 7033: WebFinger](/specs/IETF/RFC/7033 \"This specification defines the WebFinger protocol, which can be used to discover information about people or other entities on the Internet using standard HTTP methods. WebFinger discovers information for a URI that might not be usable as a locator otherwise, such as account or email URIs.\"):** [A WebFinger request is an HTTPS request to a WebFinger resource. A WebFinger resource is a well-known URI [3] using the HTTPS scheme constructed along with the required query target and optional link relation types. The path component of a WebFinger URI MUST be the well-known path \"/.well-known/webfinger\". A WebFinger URI MUST contain a query component that encodes the query target and optional link relation types.](http://tools.ietf.org/html/rfc7033#section-4 \"Read documentation for Well-Known URI "webfinger"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/webfinger"
},
"host-meta": {
"details": "[RFC 6415: Web Host Metadata](/specs/IETF/RFC/6415 \"This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.\"):** [The client obtains the host-meta document for a given host by sending an HTTP or an HTTPS GET request to the host for the \"/.well-known/host-meta\" path.](http://tools.ietf.org/html/rfc6415#section-2 \"Read documentation for Well-Known URI "host-meta"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/host-meta"
},
"ni": {
"details": "[RFC 6920: Naming Things with Hashes](/specs/IETF/RFC/6920 \"This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.\"):** [We define a mapping between URIs following the ni URI scheme and HTTP or HTTPS URLs that makes use of the .well-known URI by defining an \"ni\" suffix.](http://tools.ietf.org/html/rfc6920#section-4 \"Read documentation for Well-Known URI "ni"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/ni"
},
"host-meta.json": {
"details": "[RFC 6415: Web Host Metadata](/specs/IETF/RFC/6415 \"This specification describes a method for locating host metadata as well as information about individual resources controlled by the host.\"):** [Alternatively, the client MAY request a JRD representation by requesting the \"host-meta.json\" well-known document, by making a GET request for \"/.well-known/host-meta.json\", following the same process used for \"/.well-known/host-meta\".](http://tools.ietf.org/html/rfc6415#section-2 \"Read documentation for Well-Known URI "host-meta.json"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/host-meta.json"
},
"caldav": {
"details": "[RFC 6764: Locating Services for Calendaring Extensions to WebDAV (CalDAV) and vCard Extensions to WebDAV (CardDAV)](/specs/IETF/RFC/6764 \"This specification describes how DNS SRV records, DNS TXT records, and well-known URIs can be used together or separately to locate CalDAV (Calendaring Extensions to Web Distributed Authoring and Versioning (WebDAV)) or CardDAV (vCard Extensions to WebDAV) services.\"):** [\"caldav\" and \"carddav\" \".well-known\" URIs point to a resource that the client can use as the initial \"context path\" for the service they are trying to connect to. The server MUST redirect HTTP requests for that resource to the actual \"context path\" using one of the available mechanisms provided by HTTP (e.g., using a 301, 303, or 307 response). Clients MUST handle HTTP redirects on the \".well-known\" URI. Servers MUST NOT locate the actual CalDAV or CardDAV service endpoint at the \".well-known\" URI.](http://tools.ietf.org/html/rfc6764#section-5 \"Read documentation for Well-Known URI "caldav"\")",
"url": "http://webconcepts.info/concepts/well-known-uri/caldav"
}
},
"URI Scheme": {
"geo": {
"details": "[RFC 5870: A Uniform Resource Identifier for Geographic Locations ('geo' URI)](/specs/IETF/RFC/5870 \"This document specifies a Uniform Resource Identifier (URI) for geographic locations using the 'geo' scheme name. A 'geo' URI identifies a physical location in a two- or three-dimensional coordinate reference system in a compact, simple, human-readable, and protocol-independent way. The default coordinate reference system used is the World Geodetic System 1984 (WGS-84).\"):** [The 'geo' URI scheme provides the textual representation of the location's spatial coordinates in either two or three dimensions (latitude, longitude, and optionally altitude for the default CRS of WGS-84).](http://tools.ietf.org/html/rfc5870#section-3 \"Read documentation for URI Scheme "geo"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/geo"
},
"wss": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [The only operation for this scheme is to open a connection using the WebSocket Protocol, encrypted using TLS.](http://tools.ietf.org/html/rfc6455#section-3 \"Read documentation for URI Scheme "wss"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/wss"
},
"session": {
"details": "[RFC 6768: Media Resource Control Protocol Version 2 (MRCPv2)](/specs/IETF/RFC/6768 \"The Media Resource Control Protocol Version 2 (MRCPv2) allows client hosts to control media service resources such as speech synthesizers, recognizers, verifiers, and identifiers residing in servers on the network. MRCPv2 is not a "stand-alone" protocol -- it relies on other protocols, such as the Session Initiation Protocol (SIP), to coordinate MRCPv2 clients and servers and manage sessions between them, and the Session Description Protocol (SDP) to describe, discover, and exchange capabilities. It also depends on SIP and SDP to establish the media sessions and associated parameters between the media source or sink and the media server. Once this is done, the MRCPv2 exchange operates over the control session established above, allowing the client to control the media processing resources on the speech resource server.\"):** [The URI is intended to identify a data resource previously given to the network computing resource. The purpose of this scheme is to permit access to the specific resource for the lifetime of the session with the entity storing the resource.](http://tools.ietf.org/html/rfc6787#section-13.6 \"Read documentation for URI Scheme "session"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/session"
},
"ws": {
"details": "[RFC 6455: The WebSocket Protocol](/specs/IETF/RFC/6455 \"The WebSocket Protocol enables two-way communication between a client running untrusted code in a controlled environment to a remote host that has opted-in to communications from that code. The security model used for this is the origin-based security model commonly used by web browsers. The protocol consists of an opening handshake followed by basic message framing, layered over TCP. The goal of this technology is to provide a mechanism for browser-based applications that need two-way communication with servers that does not rely on opening multiple HTTP connections (e.g., using XMLHttpRequest or <iframe>s and long polling).\"):** [The only operation for this scheme is to open a connection using the WebSocket Protocol.](http://tools.ietf.org/html/rfc6455#section-3 \"Read documentation for URI Scheme "ws"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/ws"
},
"mailto": {
"details": "[RFC 6068: The 'mailto' URI Scheme](/specs/IETF/RFC/6068 \"This document defines the format of Uniform Resource Identifiers (URIs) to identify resources that are reached using Internet mail. It adds better internationalization and compatibility with Internationalized Resource Identifiers to the previous syntax of 'mailto' URIs.\"):** [A 'mailto' URI designates an \"Internet resource\", which is the mailbox specified in the address.](http://tools.ietf.org/html/rfc6068#section-3 \"Read documentation for URI Scheme "mailto"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/mailto"
},
"example": {
"details": "[RFC 7595: Guidelines and Registration Procedures for URI Schemes](/specs/IETF/RFC/7595 \"This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes.\"):** [There is a need for a scheme name that can be used for examples in documentation without fear of conflicts with current or future actual schemes. The scheme \"example\" is hereby registered as a 'permanent' scheme for that purpose.](http://tools.ietf.org/html/rfc7595#section-8 \"Read documentation for URI Scheme "example"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/example"
},
"ftp": {
"details": "[RFC 1738: Uniform Resource Locators (URL)](/specs/IETF/RFC/1738 \"This document specifies a Uniform Resource Locator (URL), the syntax and semantics of formalized information for location and access of resources via the Internet.\"):** [The FTP URL scheme is used to designate files and directories on Internet hosts accessible using the FTP protocol.](http://tools.ietf.org/html/rfc1738#section-3.2 \"Read documentation for URI Scheme "ftp"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/ftp"
},
"http": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"http\" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening for TCP connections on a given port.](http://tools.ietf.org/html/rfc7230#section-2.7.1 \"Read documentation for URI Scheme "http"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/http"
},
"telnet": {
"details": "[RFC 4248: The telnet URI Scheme](/specs/IETF/RFC/4248 \"This document specifies the telnet Uniform Resource Identifier (URI) scheme that was originally specified in RFC 1738. The purpose of this document is to allow RFC 1738 to be made obsolete while keeping the information about the scheme on standards track.\"):** [The Telnet URL scheme is used to designate interactive services that may be accessed by the Telnet protocol [STD8].](http://tools.ietf.org/html/rfc4248#section-2 \"Read documentation for URI Scheme "telnet"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/telnet"
},
"data": {
"details": "[RFC 2397: The \"data\" URL scheme](/specs/IETF/RFC/2397 \"A new URL scheme, "data", is defined. It allows inclusion of small data items as "immediate" data, as if it had been included externally.\"):** [Some applications that use URLs also have a need to embed (small) media type data directly inline. This document defines a new URL scheme that would work like 'immediate addressing'.](http://tools.ietf.org/html/rfc2397#section-2 \"Read documentation for URI Scheme "data"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/data"
},
"sms": {
"details": "[RFC 5724: URI Scheme for Global System for Mobile Communications (GSM) Short Message Service (SMS)](/specs/IETF/RFC/5724 \"This memo specifies the Uniform Resource Identifier (URI) scheme "sms" for specifying one or more recipients for an SMS message. SMS messages are two-way paging messages that can be sent from and received by a mobile phone or a suitably equipped networked device.\"):** [This URI scheme provides information that can be used for sending SMS message(s) to specified recipient(s). The functionality is comparable to that of the \"mailto\" URI, which can also be used with a comma-separated list of email addresses.](http://tools.ietf.org/html/rfc5724#section-2 \"Read documentation for URI Scheme "sms"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/sms"
},
"nih": {
"details": "[RFC 6920: Naming Things with Hashes](/specs/IETF/RFC/6920 \"This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.\"):** [Fields in nih URIs are separated by a semicolon (;) character. The first field is a hash algorithm string, as in the ni URI format.](http://tools.ietf.org/html/rfc6920#section-7 \"Read documentation for URI Scheme "nih"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/nih"
},
"reload": {
"details": "[RFC 6940: REsource LOcation And Discovery (RELOAD) Base Protocol](/specs/IETF/RFC/6940 \"This specification defines REsource LOcation And Discovery (RELOAD), a peer-to-peer (P2P) signaling protocol for use on the Internet. A P2P signaling protocol provides its clients with an abstract storage and messaging service between a set of cooperating peers that form the overlay network. RELOAD is designed to support a P2P Session Initiation Protocol (P2PSIP) network, but can be utilized by other applications with similar requirements by defining new usages that specify the Kinds of data that need to be stored for a particular application. RELOAD defines a security model based on a certificate enrollment service that provides unique identities. NAT traversal is a fundamental service of the protocol. RELOAD also allows access from "client" nodes that do not need to route traffic or store data for others.\"):** [This section describes the scheme for a reload URI, which can be used to refer to either a peer (e.g., as used in a certificate), or a resource inside a peer.](http://tools.ietf.org/html/rfc6940#section-14.15 \"Read documentation for URI Scheme "reload"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/reload"
},
"cap": {
"details": "[RFC 4324: Calendar Access Protocol (CAP)](/specs/IETF/RFC/4324 \"The Calendar Access Protocol (CAP) described in this memo permits a Calendar User (CU) to utilize a Calendar User Agent (CUA) to access an iCAL-based Calendar Store (CS). At the time of this writing, three vendors are implementing CAP, but it has already been determined that some changes are needed. In order to get implementation experience, the participants felt that a CAP specification is needed to preserve many years of work. Many properties in CAP which have had many years of debate, can be used by other iCalendar protocols.\"):** [The CAP URL scheme is used to designate both calendar stores and calendars accessible using the CAP protocol.](http://tools.ietf.org/html/rfc4324#section-5 \"Read documentation for URI Scheme "cap"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/cap"
},
"ni": {
"details": "[RFC 6920: Naming Things with Hashes](/specs/IETF/RFC/6920 \"This document defines a set of ways to identify a thing (a digital object in this case) using the output from a hash function. It specifies a new URI scheme for this purpose, a way to map these to HTTP URLs, and binary and human-speakable formats for these names. The various formats are designed to support, but not require, a strong link to the referenced object, such that the referenced object may be authenticated to the same degree as the reference to it. The reason for this work is to standardise current uses of hash outputs in URLs and to support new information-centric applications and other uses of hash outputs in protocols.\"):** [A Named Identifier can be represented using the ni URI scheme that we specifically define for the name. However it is represented, the Named Identifier *names* a resource, and the mechanism used to dereference the name and to *locate* the named resource needs to be known by the entity that dereferences it.](http://tools.ietf.org/html/rfc6920#section-3 \"Read documentation for URI Scheme "ni"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/ni"
},
"https": {
"details": "[RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing](/specs/IETF/RFC/7230 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes general security concerns for implementations.\"):** [The \"https\" URI scheme is hereby defined for the purpose of minting identifiers according to their association with the hierarchical namespace governed by a potential HTTP origin server listening to a given TCP port for TLS-secured connections.](http://tools.ietf.org/html/rfc7230#section-2.7.2 \"Read documentation for URI Scheme "https"\")",
"url": "http://webconcepts.info/concepts/uri-scheme/https"
}
},
"HTTP Cache Directive": {
"no-transform": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"no-transform\" directive indicates that an intermediary (whether or not it implements a cache) MUST NOT transform the payload.](http://tools.ietf.org/html/rfc7234#section-5.2.1.6 \"Read documentation for HTTP Cache Directive "no-transform"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/no-transform"
},
"max-stale": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"max-stale\" request directive indicates that the client is willing to accept a response that has exceeded its freshness lifetime. If max-stale is assigned a value, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds. If no value is assigned to max-stale, then the client is willing to accept a stale response of any age.](http://tools.ietf.org/html/rfc7234#section-5.2.1.2 \"Read documentation for HTTP Cache Directive "max-stale"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/max-stale"
},
"no-store": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"no-store\" directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches. \"MUST NOT store\" in this context means that the cache MUST NOT intentionally store the information in non-volatile storage, and MUST make a best-effort attempt to remove the information from volatile storage as promptly as possible after forwarding it.](http://tools.ietf.org/html/rfc7234#section-5.2.1.5 \"Read documentation for HTTP Cache Directive "no-store"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/no-store"
},
"proxy-revalidate": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"proxy-revalidate\" response directive has the same meaning as the must-revalidate response directive, except that it does not apply to private caches.](http://tools.ietf.org/html/rfc7234#section-5.2.2.7 \"Read documentation for HTTP Cache Directive "proxy-revalidate"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/proxy-revalidate"
},
"stale-while-revalidate": {
"details": "[RFC 5861: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 \"This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.\"):** [When present in an HTTP response, the stale-while-revalidate Cache-Control extension indicates that caches MAY serve the response in which it appears after it becomes stale, up to the indicated number of seconds.](http://tools.ietf.org/html/rfc5861#section-3 \"Read documentation for HTTP Cache Directive "stale-while-revalidate"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/stale-while-revalidate"
},
"no-cache": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"no-cache\" request directive indicates that a cache MUST NOT use a stored response to satisfy the request without successful validation on the origin server. The \"no-cache\" response directive indicates that the response MUST NOT be used to satisfy a subsequent request without successful validation on the origin server. This allows an origin server to prevent a cache from using it to satisfy a request without contacting it, even by caches that have been configured to send stale responses.](http://tools.ietf.org/html/rfc7234#section-5.2.1.4 \"Read documentation for HTTP Cache Directive "no-cache"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/no-cache"
},
"only-if-cached": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"only-if-cached\" request directive indicates that the client only wishes to obtain a stored response. If it receives this directive, a cache SHOULD either respond using a stored response that is consistent with the other constraints of the request, or respond with a 504 (Gateway Timeout) status code. If a group of caches is being operated as a unified system with good internal connectivity, a member cache MAY forward such a request within that group of caches.](http://tools.ietf.org/html/rfc7234#section-5.2.1.7 \"Read documentation for HTTP Cache Directive "only-if-cached"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/only-if-cached"
},
"public": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"public\" response directive indicates that any cache MAY store the response, even if the response would normally be non-cacheable or cacheable only within a private cache.](http://tools.ietf.org/html/rfc7234#section-5.2.2.5 \"Read documentation for HTTP Cache Directive "public"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/public"
},
"min-fresh": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"min-fresh\" request directive indicates that the client is willing to accept a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.](http://tools.ietf.org/html/rfc7234#section-5.2.1.3 \"Read documentation for HTTP Cache Directive "min-fresh"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/min-fresh"
},
"must-revalidate": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"must-revalidate\" response directive indicates that once it has become stale, a cache MUST NOT use the response to satisfy subsequent requests without successful validation on the origin server.](http://tools.ietf.org/html/rfc7234#section-5.2.2.1 \"Read documentation for HTTP Cache Directive "must-revalidate"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/must-revalidate"
},
"stale-if-error": {
"details": "[RFC 5861: HTTP Cache-Control Extensions for Stale Content](/specs/IETF/RFC/5861 \"This document defines two independent HTTP Cache-Control extensions that allow control over the use of stale responses by caches.\"):** [The stale-if-error Cache-Control extension indicates that when an error is encountered, a cached stale response MAY be used to satisfy the request, regardless of other freshness information.](http://tools.ietf.org/html/rfc5861#section-4 \"Read documentation for HTTP Cache Directive "stale-if-error"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/stale-if-error"
},
"private": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"private\" response directive indicates that the response message is intended for a single user and MUST NOT be stored by a shared cache. A private cache MAY store the response and reuse it for later requests, even if the response would normally be non-cacheable.](http://tools.ietf.org/html/rfc7234#section-5.2.2.6 \"Read documentation for HTTP Cache Directive "private"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/private"
},
"max-age": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"max-age\" request directive indicates that the client is unwilling to accept a response whose age is greater than the specified number of seconds. Unless the max-stale request directive is also present, the client is not willing to accept a stale response. The \"max-age\" response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds.](http://tools.ietf.org/html/rfc7234#section-5.2.1.1 \"Read documentation for HTTP Cache Directive "max-age"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/max-age"
},
"s-maxage": {
"details": "[RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching](/specs/IETF/RFC/7234 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages.\"):** [The \"s-maxage\" response directive indicates that, in shared caches, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field. The s-maxage directive also implies the semantics of the proxy-revalidate response directive.](http://tools.ietf.org/html/rfc7234#section-5.2.2.9 \"Read documentation for HTTP Cache Directive "s-maxage"\")",
"url": "http://webconcepts.info/concepts/http-cache-directive/s-maxage"
}
},
"HTTP Range Unit": {
"bytes": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [Since representation data is transferred in payloads as a sequence of octets, a byte range is a meaningful substructure for any representation transferable over HTTP. The \"bytes\" range unit is defined for expressing subranges of the data's octet sequence.](http://tools.ietf.org/html/rfc7233#section-2.1 \"Read documentation for HTTP Range Unit "bytes"\")",
"url": "http://webconcepts.info/concepts/http-range-unit/bytes"
},
"none": {
"details": "[RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests](/specs/IETF/RFC/7233 \"The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests.\"):** [A server that does not support any kind of range request for the target resource MAY send \"Accept-Ranges: none\" to advise the client not to attempt a range request.](http://tools.ietf.org/html/rfc7233#section-2.3 \"Read documentation for HTTP Range Unit "none"\")",
"url": "http://webconcepts.info/concepts/http-range-unit/none"
},
"bytes-live": {
"details": "[Internet Draft pratt-httpbis-bytes-live-range-unit: HTTP bytes-live Range Unit for Live Content](/specs/IETF/I-D/pratt-httpbis-bytes-live-range-unit \"To accommodate byte range requests for content that has data appended over time, this document defines a new HTTP range unit named "bytes-live". The "bytes-live" range unit provides the ability for a client to specify a byte range in a GET or HEAD request which starts at an arbitrary byte offset within the representation and ends at an indeterminate offset, represented by "*".\"):** [As with the \"bytes\" range unit, a \"bytes-live\" Range request allows a client to designate a subset of bytes from the representation data to be transferred in payloads as a sequence of octets. But the form of a \"bytes-live\" request is focused on accessing data that may be appended to the representation over time.](http://tools.ietf.org/html/draft-pratt-httpbis-bytes-live-range-unit#section-2 \"Read documentation for HTTP Range Unit "bytes-live"\")",
"url": "http://webconcepts.info/concepts/http-range-unit/bytes-live"
}
}
}