Skip to content
Permalink
Branch: master
Find file Copy path
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
186 lines (183 sloc) 152 KB

HTTP Header Fields

The following 179 HTTP Header Field definitions (170 distinct values) were found in 123 services (29 W3C, 73 RFC, 21 I-D). Please be advised that the table shown here is maintained and compiled from Sedola sources. The official HTTP Header Field registry is maintained by the Internet Assigned Numbers Authority (IANA).

HTTP Header Field Description Specification
A-IM "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." RFC 3229: Delta encoding in HTTP
ALPN "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." RFC 7639: The ALPN HTTP Header Field
Accept "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Accept-Additions(2 definitions) "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"." RFC 2324: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)
Accept-Additions(2 definitions) "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." RFC 7168: The Hyper Text Coffee Pot Control Protocol for Tea Efflux Appliances (HTCPCP-TEA)
Accept-Charset "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Accept-Datetime "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." RFC 7089: HTTP framework for time-based access to resource states - Memento
Accept-Encoding(2 definitions) "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Accept-Encoding(2 definitions) "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." RFC 7694: Hypertext Transfer Protocol (HTTP) Client-Initiated Content-Encoding
Accept-Features "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." RFC 2295: Transparent Content Negotiation in HTTP
Accept-Indefinite-Ranges "The Accept-Indefinite-Ranges request-header field allows the client to indicate its acceptance of indefinite-sized range requests for a resource." draft-combs-http-indeterminate-range: HTTP/1.1: Range Responses of Indeterminate Length
Accept-Language "The "Accept-Language" header field can be used by user agents to indicate the set of natural languages that are preferred in the response." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Accept-Patch "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." RFC 5789: PATCH Method for HTTP
Accept-Post "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." W3C TR ldp: Linked Data Platform 1.0 (LDP)
Accept-Push-Policy "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." draft-ruellan-http-accept-push-policy: Accept-Push-Policy Header Field
Accept-Ranges "The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource." RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Access-Control-Allow-Credentials "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." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Allow-Headers "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." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Allow-Methods "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." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Allow-Origin "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." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Expose-Headers "The Access-Control-Expose-Headers header indicates which headers are safe to expose to the API of a CORS API specification." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Max-Age "The Access-Control-Max-Age header indicates how long the results of a preflight request can be cached in a preflight result cache." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Request-Headers "The Access-Control-Request-Headers header indicates which headers will be used in the actual request as part of the preflight request." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Access-Control-Request-Method "The Access-Control-Request-Method header indicates which method will be used in the actual request as part of the preflight request." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Age "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." RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
Allow "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Alt-Svc "An HTTP(S) origin server can advertise the availability of alternative services to clients by adding an Alt-Svc header field to responses." RFC 7838: HTTP Alternate Services
Alt-Used "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." RFC 7838: HTTP Alternate Services
Alternates "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." RFC 2295: Transparent Content Negotiation in HTTP
Apply-To-Redirect-Ref "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." RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources
Authentication-Info "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)." RFC 7615: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields
Authorization(3 definitions) "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)." RFC 5849: The OAuth 1.0 Protocol
Authorization(3 definitions) "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." RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
Authorization(3 definitions) "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." RFC 7616: HTTP Digest Access Authentication
C-Ext "The C-Ext response header field is used to indicate that all hop-by-hop mandatory extension declarations in the request were fulfilled." RFC 2774: An HTTP Extension Framework
C-Man "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." RFC 2774: An HTTP Extension Framework
C-Opt "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." RFC 2774: An HTTP Extension Framework
C-PEP "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." W3C TR WD-http-pep: PEP - An Extension Mechanism for HTTP
C-PEP-Info "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." W3C TR WD-http-pep: PEP - An Extension Mechanism for HTTP
CH "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." draft-grigorik-http-client-hints: HTTP Client Hints
Cache-Control "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." RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
Clear-Site-Data "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." W3C TR clear-site-data: Clear Site Data
Close "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Connection "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Content-Base "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." RFC 2068: Hypertext Transfer Protocol - HTTP/1.1
Content-DPR "The "Content-DPR" header field is a number that indicates the ratio between physical pixels over CSS px of the selected image response." draft-ietf-httpbis-client-hints: HTTP Client Hints
Content-Disposition "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." RFC 6266: Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)
Content-Encoding "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Content-Language(2 definitions) "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Content-Language(2 definitions) "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Content-Length "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])." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Content-Range(2 definitions) "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." RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Content-Range(2 definitions) "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." draft-combs-http-indeterminate-range: HTTP/1.1: Range Responses of Indeterminate Length
Content-Security-Policy(2 definitions) "The Content-Security-Policy header field is the preferred mechanism for delivering a policy." W3C TR CSP2: Content Security Policy Level 2
Content-Security-Policy(2 definitions) "The Content-Security-Policy HTTP response header field is the preferred mechanism for delivering a policy from a server to a client." W3C TR CSP3: Content Security Policy Level 3
Content-Security-Policy-Pin "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)." W3C TR csp-pinning: Content Security Policy Pinning
Content-Security-Policy-Report-Only(2 definitions) "The Content-Security-Policy-Report-Only header field lets servers experiment with policies by monitoring (rather than enforcing) a policy." W3C TR CSP2: Content Security Policy Level 2
Content-Security-Policy-Report-Only(2 definitions) "The Content-Security-Policy-Report-Only HTTP response header field allows web developers to experiment with policies by monitoring (but not enforcing) their effects." W3C TR CSP3: Content Security Policy Level 3
Content-Security-Policy-Report-Only-Pin "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)." W3C TR csp-pinning: Content Security Policy Pinning
Content-Signature "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." draft-thomson-http-content-signature: Content-Signature Header Field for HTTP
Content-Type "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Content-Version "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." RFC 2068: Hypertext Transfer Protocol - HTTP/1.1
Cookie "The user agent sends stored cookies to the origin server in the Cookie header." RFC 6265: HTTP State Management Mechanism
Cookie2 "The Cookie2 request header facilitates interoperation between clients and servers that understand different versions of the cookie specification." RFC 2965: HTTP State Management Mechanism
Crypto-Key "A Crypto-Key header field can be used to describe the input keying material used in the Encryption header field." draft-ietf-httpbis-encryption-encoding: Encrypted Content-Encoding for HTTP
DASL "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)." RFC 5323: Web Distributed Authoring and Versioning (WebDAV) SEARCH
DAV "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." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
DNT "The DNT header field is defined as the means for expressing a user's tracking preference via HTTP." W3C TR tracking-dnt: Tracking Preference Expression (DNT)
DPR "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." draft-ietf-httpbis-client-hints: HTTP Client Hints
Date "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Delta-Base "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." RFC 3229: Delta encoding in HTTP
Depth "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")." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Destination "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." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Digest "The Digest message header field provides a message digest of the instance described by the message." RFC 3230: Instance Digests in HTTP
Downlink "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." draft-ietf-httpbis-client-hints: HTTP Client Hints
EPR "Servers may request the protections outlined by Entry Point Regulation (EPR) by sending an EPR HTTP response header field along with a response." W3C TR epr: Entry Point Regulation (EPR)
ETag "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Encryption "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." draft-ietf-httpbis-encryption-encoding: Encrypted Content-Encoding for HTTP
Expect "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Expires "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." RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
Ext "The Ext header field is used to indicate that all end-to-end mandatory extension declarations in the request were fulfilled." RFC 2774: An HTTP Extension Framework
Forwarded "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." RFC 7239: Forwarded HTTP Extension
From "The "From" header field contains an Internet email address for a human user who controls the requesting user agent." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
HTTP2-Settings "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." RFC 7540: Hypertext Transfer Protocol Version 2
HTTPS "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." W3C TR upgrade-insecure-requests: Upgrade Insecure Requests
Hobareg "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"." RFC 7486: HTTP Origin-Bound Authentication (HOBA)
Host "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
IM "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." RFC 3229: Delta encoding in HTTP
If "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." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
If-Match "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
If-Modified-Since "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
If-None-Match "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
If-Range "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." RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
If-Schedule-Tag-Match "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." RFC 6638: Scheduling Extensions to CalDAV
If-Unmodified-Since "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Key "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"." draft-ietf-httpbis-key: The Key HTTP Response Header Field
Label "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." RFC 3253: Versioning Extensions to WebDAV (Web Distributed Authoring and Versioning)
Last-Event-ID "The Last-Event-ID HTTP header specifies the value of the event source's last event ID string, encoded as UTF-8." W3C TR eventsource: Server-Sent Events
Last-Modified "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." RFC 7232: Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
Link "The Link entity-header field provides a means for serialising one or more links in HTTP headers. It is semantically equivalent to the element in HTML, as well as the atom:link feed-level element in Atom." RFC 5988: Web Linking
Link-Template "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." draft-nottingham-link-template: The Link-Template HTTP Header Field
Location "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Lock-Token "The Lock-Token request header is used with the UNLOCK method to identify the lock to be removed." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
MIME-Version "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Man "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." RFC 2774: An HTTP Extension Framework
Max-Forwards "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Memento-Datetime "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." RFC 7089: HTTP framework for time-based access to resource states - Memento
Negotiate "The Negotiate request header can contain directives for any content negotiation process initiated by the request." RFC 2295: Transparent Content Negotiation in HTTP
Nice "The "Nice" header field indicates that a request is less important than a request that doesn't bear this header." draft-thomson-http-nice: Marking HTTP Requests as Unimportant
Opt "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." RFC 2774: An HTTP Extension Framework
Ordering-Type "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." RFC 3648: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
Origin "The Origin header indicates where the cross-origin request or preflight request originates from." W3C TR cors: Cross-Origin Resource Sharing (CORS)
Origin-Cookie "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." draft-west-origin-cookies: Origin Cookies
Overwrite "The Overwrite request header specifies whether the server should overwrite a resource mapped to the destination URL during a COPY or MOVE." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
P3P "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." W3C TR P3P: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification
PEP "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." W3C TR WD-http-pep: PEP - An Extension Mechanism for HTTP
PEP-Info "PEP end-to-end policies MUST be transmitted to the ultimate recipient of a message." W3C TR WD-http-pep: PEP - An Extension Mechanism for HTTP
POE "The POE HTTP header is a request-header field whose field-value indicates the version of POE that a client supports." draft-nottingham-http-poe: POST Once Exactly (POE)
POE-Links "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." draft-nottingham-http-poe: POST Once Exactly (POE)
Position "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." RFC 3648: Web Distributed Authoring and Versioning (WebDAV) Ordered Collections Protocol
Pragma "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." RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
Prefer "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." RFC 7240: Prefer Header for HTTP
Preference-Applied "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." RFC 7240: Prefer Header for HTTP
Proxy-Authenticate "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." RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
Proxy-Authentication-Info "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." RFC 7615: The Hypertext Transfer Protocol (HTTP) Authentication-Info and Proxy-Authentication-Info Response Header Fields
Proxy-Authorization "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." RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
Proxy-Features "The proxy features header is used by a proxy sending data to a server. It specifies the features supported by the specified proxy." W3C TR WD-proxy: Notification for Proxy Caches
Proxy-Instruction "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." W3C TR WD-proxy: Notification for Proxy Caches
Public "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." RFC 2068: Hypertext Transfer Protocol - HTTP/1.1
Public-Key-Pins "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." RFC 7469: Public Key Pinning Extension for HTTP
Public-Key-Pins-Report-Only "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." RFC 7469: Public Key Pinning Extension for HTTP
Push-Policy "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." draft-ruellan-http-accept-push-policy: Accept-Push-Policy Header Field
Range "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." RFC 7233: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Redirect-Ref "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." RFC 4437: Web Distributed Authoring and Versioning (WebDAV): Redirect Reference Resources
Referer "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)." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Report-To "The Report-To HTTP response header field instructs the user agent to store reporting endpoints for an origin." W3C TR reporting-1: Reporting API 1
Retry-After "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
SOAPAction "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." W3C TR 2000: Simple Object Access Protocol (SOAP) 1.1
Safe "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." RFC 2310: The Safe Response Header Field
Save-Data "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." draft-ietf-httpbis-client-hints: HTTP Client Hints
Schedule-Reply "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." RFC 6638: Scheduling Extensions to CalDAV
Schedule-Tag "The Schedule-Tag response header provides the current value of the CALDAV:schedule-tag property value." RFC 6638: Scheduling Extensions to CalDAV
Sec-COWL "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." W3C TR COWL: Confinement with Origin Web Labels
Sec-WebSocket-Accept "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." RFC 6455: The WebSocket Protocol
Sec-WebSocket-Extensions "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." RFC 6455: The WebSocket Protocol
Sec-WebSocket-Key "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." RFC 6455: The WebSocket Protocol
Sec-WebSocket-Protocol "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." RFC 6455: The WebSocket Protocol
Sec-WebSocket-Version "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." RFC 6455: The WebSocket Protocol
Security-Scheme "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." RFC 2660: The Secure HyperText Transfer Protocol (S-HTTP)
Server "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Set-Cookie "The Set-Cookie HTTP response header is used to send cookies from the server to the user agent." RFC 6265: HTTP State Management Mechanism
Set-Cookie2 "The origin server initiates a session, if it so desires. To do so, it returns an extra response header to the client, Set-Cookie2." RFC 2965: HTTP State Management Mechanism
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." draft-cavage-http-signatures: Signing HTTP Messages
Slug "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." RFC 5023: Atom Publishing Protocol (AtomPub)
Status-URI "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." RFC 2518: HTTP Extensions for Distributed Authoring - WEBDAV
Strict-Transport-Security "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." RFC 6797: HTTP Strict Transport Security (HSTS)
Sunset "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." draft-wilde-sunset-header: The Sunset HTTP Header
Surrogate-Capability "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." W3C TR edge-arch: Edge Architecture Specification
Surrogate-Control "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." W3C TR edge-arch: Edge Architecture Specification
TCN "The TCN response header is used by a server to signal that the resource is transparently negotiated." RFC 2295: Transparent Content Negotiation in HTTP
TE "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Timeout "Clients MAY include Timeout request headers in their LOCK requests. However, the server is not required to honor or even consider these requests." RFC 4918: HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)
Tk "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." W3C TR tracking-dnt: Tracking Preference Expression (DNT)
Trailer "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Transfer-Encoding "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Tunnel-Protocol "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." draft-ietf-httpbis-tunnel-protocol: The Tunnel-Protocol HTTP Header Field
URI "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." RFC 2068: Hypertext Transfer Protocol - HTTP/1.1
Upgrade "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
User-Agent "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." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Variant-Vary "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." RFC 2295: Transparent Content Negotiation in HTTP
Vary "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)." RFC 7231: Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
Via "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." RFC 7230: Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
Viewport-Width "The "Viewport-Width" header field is a number that, in requests, indicates the layout viewport width in CSS px." draft-ietf-httpbis-client-hints: HTTP Client Hints
WWW-Authenticate(2 definitions) "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." RFC 7235: Hypertext Transfer Protocol (HTTP/1.1): Authentication
WWW-Authenticate(2 definitions) "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." RFC 7616: HTTP Digest Access Authentication
Want-Digest "The Want-Digest message header field indicates the sender's desire to receive an instance digest on messages associated with the Request-URI." RFC 3230: Instance Digests in HTTP
Warning "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." RFC 7234: Hypertext Transfer Protocol (HTTP/1.1): Caching
Width "The "Width" header field is a number that, in requests, indicates the resource width in physical px (i.e. intrinsic size of an image)." draft-ietf-httpbis-client-hints: HTTP Client Hints
X-Frame-Options "The X-Frame-Options HTTP header field indicates a policy that specifies whether the browser should render the transmitted resource within a 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." RFC 7034: HTTP Header Field X-Frame-Options
You can’t perform that action at this time.