- Generated on Fri Nov 15 2024 18:01:34 for TianoCore EDK2 by
1.9.6
|
TianoCore EDK2 master
|
Go to the source code of this file.
Hypertext Transfer Protocol – HTTP/1.1 Standard definitions, from RFC 2616
This file contains common HTTP 1.1 definitions from RFC 2616
(C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP
SPDX-License-Identifier: BSD-2-Clause-Patent
Definition in file Http11.h.
| #define HTTP_CONTENT_ENCODING_IDENTITY "identity" |
| #define HTTP_CONTENT_TYPE_APP_OCTET_STREAM "application/octet-stream" |
| #define HTTP_EXPECT_100_CONTINUE "100-continue" |
| #define HTTP_HEADER_ACCEPT "Accept" |
Accept Request Header The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers 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.
| #define HTTP_HEADER_ACCEPT_CHARSET "Accept-Charset" |
Accept-Charset Request Header The Accept-Charset request-header field can be used to indicate what character sets are acceptable for the response. This field allows clients capable of understanding more comprehensive or special-purpose character sets to signal that capability to a server which is capable of representing documents in those character sets.
| #define HTTP_HEADER_ACCEPT_ENCODING "Accept-Encoding" |
| #define HTTP_HEADER_ACCEPT_LANGUAGE "Accept-Language" |
| #define HTTP_HEADER_ACCEPT_RANGES "Accept-Ranges" |
| #define HTTP_HEADER_AUTHORIZATION "Authorization" |
| #define HTTP_HEADER_CONTENT_ENCODING "Content-Encoding" |
Content-Encoding Header The Content-Encoding entity-header field is used as a modifier to the media-type. When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms must be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a document to be compressed without losing the identity of its underlying media type.
| #define HTTP_HEADER_CONTENT_LENGTH "Content-Length" |
Content-Length Header The Content-Length entity-header field indicates the size of the entity-body, in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
| #define HTTP_HEADER_CONTENT_RANGE "Content-Range" |
| #define HTTP_HEADER_CONTENT_TYPE "Content-Type" |
| #define HTTP_HEADER_ETAG "ETag" |
| #define HTTP_HEADER_EXPECT "Expect" |
Expect Header 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. The only such expectation defined by this specification is 100-continue.
| #define HTTP_HEADER_HOST "Host" |
| #define HTTP_HEADER_IF_MATCH "If-Match" |
The If-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that one of those entities is current by including a list of their associated entity tags in the If-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used, on updating requests, to prevent inadvertent modification of the wrong version of a resource. As a special case, the value "*" matches any current entity of the resource.
| #define HTTP_HEADER_IF_NONE_MATCH "If-None-Match" |
The If-None-Match request-header field is used with a method to make it conditional. A client that has one or more entities previously obtained from the resource can verify that none of those entities is current by including a list of their associated entity tags in the If-None-Match header field. The purpose of this feature is to allow efficient updates of cached information with a minimum amount of transaction overhead. It is also used to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the client believes that the resource does not exist.
| #define HTTP_HEADER_IF_UNMODIFIED_SINCE "If-Unmodified-Since" |
If Unmodified Since Request Header Makes the request for the resource conditional: the server will send the requested resource or accept it in the case of a POST or another non-safe method only if the resource has not been modified after the date specified by this HTTP header. If the resource has been modified after the specified date, the response will be a 412 Precondition Failed error.
| #define HTTP_HEADER_LAST_MODIFIED "Last-Modified" |
Last-Modified Response Header The Last-Modified response HTTP header contains a date and time when the origin server believes the resource was last modified. It is used as a validator to determine if the resource is the same as the previously stored one. Less accurate than an ETag header, it is a fallback mechanism. Conditional requests containing If-Modified-Since or If-Unmodified-Since headers make use of this field.
| #define HTTP_HEADER_LOCATION "Location" |
Location Response Header
The Location response-header field is used to redirect the recipient to a location other than the Request-URI for completion of the request or identification of a new resource. For 201 (Created) responses, the Location is that of the new resource which was created by the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single absolute URI.
| #define HTTP_HEADER_TRANSFER_ENCODING "Transfer-Encoding" |
Transfer-Encoding Header The Transfer-Encoding general-header field indicates what (if any) type of transformation has been applied to the message body in order to safely transfer it between the sender and the recipient. This differs from the content-coding in that the transfer-coding is a property of the message, not of the entity.
| #define HTTP_HEADER_USER_AGENT "User-Agent" |
User Agent Request Header
The User-Agent request-header field contains information about the user agent originating the request. This is for statistical purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses to avoid particular user agent limitations. User agents SHOULD include this field with requests. The field can contain multiple product tokens and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the product tokens are listed in order of their significance for identifying the application.
| #define HTTP_HEADER_WWW_AUTHENTICATE "WWW-Authenticate" |
| #define HTTP_HEADER_X_AUTH_TOKEN "X-Auth-Token" |
| #define HTTP_METHOD_MAXIMUM_LEN sizeof (HTTP_METHOD_CONNECT) |
| #define HTTP_METHOD_OPTIONS "OPTIONS" |
1.9.6