]>
git.proxmox.com Git - mirror_edk2.git/blob - MdePkg/Include/IndustryStandard/Http11.h
2 Hypertext Transfer Protocol -- HTTP/1.1 Standard definitions, from RFC 2616
4 This file contains common HTTP 1.1 definitions from RFC 2616
6 (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP<BR>
7 This program and the accompanying materials
8 are licensed and made available under the terms and conditions of the BSD License
9 which accompanies this distribution. The full text of the license may be found at
10 http://opensource.org/licenses/bsd-license.php
12 THE PROGRAM IS DISTRIBUTED UNDER THE BSD LICENSE ON AN "AS IS" BASIS,
13 WITHOUT WARRANTIES OR REPRESENTATIONS OF ANY KIND, EITHER EXPRESS OR IMPLIED.
22 /// HTTP Version (currently HTTP 1.1)
24 /// The version of an HTTP message is indicated by an HTTP-Version field
25 /// in the first line of the message.
27 #define HTTP_VERSION "HTTP/1.1"
30 /// HTTP Request Method definitions
32 /// The Method token indicates the method to be performed on the
33 /// resource identified by the Request-URI. The method is case-sensitive.
35 #define HTTP_METHOD_OPTIONS "OPTIONS"
36 #define HTTP_METHOD_GET "GET"
37 #define HTTP_METHOD_HEAD "HEAD"
38 #define HTTP_METHOD_POST "POST"
39 #define HTTP_METHOD_PUT "PUT"
40 #define HTTP_METHOD_DELETE "DELETE"
41 #define HTTP_METHOD_TRACE "TRACE"
42 #define HTTP_METHOD_CONNECT "CONNECT"
43 #define HTTP_METHOD_PATCH "PATCH"
46 /// Connect method has maximum length according to EFI_HTTP_METHOD defined in
47 /// UEFI2.5 spec so use this.
49 #define HTTP_METHOD_MAXIMUM_LEN sizeof (HTTP_METHOD_CONNECT)
52 /// Accept Request Header
53 /// The Accept request-header field can be used to specify certain media types which are
54 /// acceptable for the response. Accept headers can be used to indicate that the request
55 /// is specifically limited to a small set of desired types, as in the case of a request
56 /// for an in-line image.
58 #define HTTP_HEADER_ACCEPT "Accept"
62 /// Accept-Charset Request Header
63 /// The Accept-Charset request-header field can be used to indicate what character sets
64 /// are acceptable for the response. This field allows clients capable of understanding
65 /// more comprehensive or special-purpose character sets to signal that capability to a
66 /// server which is capable of representing documents in those character sets.
68 #define HTTP_HEADER_ACCEPT_CHARSET "Accept-Charset"
71 /// Accept-Language Request Header
72 /// The Accept-Language request-header field is similar to Accept,
73 /// but restricts the set of natural languages that are preferred
74 /// as a response to the request.
76 #define HTTP_HEADER_ACCEPT_LANGUAGE "Accept-Language"
79 /// Accept-Ranges Request Header
80 /// The Accept-Ranges response-header field allows the server to
81 /// indicate its acceptance of range requests for a resource:
83 #define HTTP_HEADER_ACCEPT_RANGES "Accept-Ranges"
87 /// Accept-Encoding Request Header
88 /// The Accept-Encoding request-header field is similar to Accept,
89 /// but restricts the content-codings that are acceptable in the response.
91 #define HTTP_HEADER_ACCEPT_ENCODING "Accept-Encoding"
94 /// Content-Encoding Header
95 /// The Content-Encoding entity-header field is used as a modifier to the media-type.
96 /// When present, its value indicates what additional content codings have been applied
97 /// to the entity-body, and thus what decoding mechanisms must be applied in order to
98 /// obtain the media-type referenced by the Content-Type header field. Content-Encoding
99 /// is primarily used to allow a document to be compressed without losing the identity
100 /// of its underlying media type.
102 #define HTTP_HEADER_CONTENT_ENCODING "Content-Encoding"
105 /// HTTP Content-Encoding Compression types
108 #define HTTP_CONTENT_ENCODING_IDENTITY "identity" /// No transformation is used. This is the default value for content coding.
109 #define HTTP_CONTENT_ENCODING_GZIP "gzip" /// Content-Encoding: GNU zip format (described in RFC 1952).
110 #define HTTP_CONTENT_ENCODING_COMPRESS "compress" /// encoding format produced by the common UNIX file compression program "compress".
111 #define HTTP_CONTENT_ENCODING_DEFLATE "deflate" /// The "zlib" format defined in RFC 1950 in combination with the "deflate"
112 /// compression mechanism described in RFC 1951.
116 /// Content-Type Header
117 /// The Content-Type entity-header field indicates the media type of the entity-body sent to
118 /// the recipient or, in the case of the HEAD method, the media type that would have been sent
119 /// had the request been a GET.
121 #define HTTP_HEADER_CONTENT_TYPE "Content-Type"
123 // Common Media Types defined in http://www.iana.org/assignments/media-types/media-types.xhtml
125 #define HTTP_CONTENT_TYPE_APP_JSON "application/json"
126 #define HTTP_CONTENT_TYPE_APP_OCTET_STREAM "application/octet-stream"
128 #define HTTP_CONTENT_TYPE_TEXT_HTML "text/html"
129 #define HTTP_CONTENT_TYPE_TEXT_PLAIN "text/plain"
130 #define HTTP_CONTENT_TYPE_TEXT_CSS "text/css"
131 #define HTTP_CONTENT_TYPE_TEXT_XML "text/xml"
133 #define HTTP_CONTENT_TYPE_IMAGE_GIF "image/gif"
134 #define HTTP_CONTENT_TYPE_IMAGE_JPEG "image/jpeg"
135 #define HTTP_CONTENT_TYPE_IMAGE_PNG "image/png"
136 #define HTTP_CONTENT_TYPE_IMAGE_SVG_XML "image/svg+xml"
140 /// Content-Length Header
141 /// The Content-Length entity-header field indicates the size of the entity-body,
142 /// in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD
143 /// method, the size of the entity-body that would have been sent had the request been a GET.
145 #define HTTP_HEADER_CONTENT_LENGTH "Content-Length"
148 /// Transfer-Encoding Header
149 /// The Transfer-Encoding general-header field indicates what (if any) type of transformation
150 /// has been applied to the message body in order to safely transfer it between the sender
151 /// and the recipient. This differs from the content-coding in that the transfer-coding
152 /// is a property of the message, not of the entity.
154 #define HTTP_HEADER_TRANSFER_ENCODING "Transfer-Encoding"
158 /// User Agent Request Header
160 /// The User-Agent request-header field contains information about the user agent originating
161 /// the request. This is for statistical purposes, the tracing of protocol violations, and
162 /// automated recognition of user agents for the sake of tailoring responses to avoid
163 /// particular user agent limitations. User agents SHOULD include this field with requests.
164 /// The field can contain multiple product tokens and comments identifying the agent and any
165 /// subproducts which form a significant part of the user agent.
166 /// By convention, the product tokens are listed in order of their significance for
167 /// identifying the application.
169 #define HTTP_HEADER_USER_AGENT "User-Agent"
172 /// Host Request Header
174 /// The Host request-header field specifies the Internet host and port number of the resource
175 /// being requested, as obtained from the original URI given by the user or referring resource
177 #define HTTP_HEADER_HOST "Host"
180 /// Location Response Header
182 /// The Location response-header field is used to redirect the recipient to a location other than
183 /// the Request-URI for completion of the request or identification of a new resource.
184 /// For 201 (Created) responses, the Location is that of the new resource which was created by
185 /// the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for
186 /// automatic redirection to the resource. The field value consists of a single absolute URI.
188 #define HTTP_HEADER_LOCATION "Location"
191 /// The If-Match request-header field is used with a method to make it conditional.
192 /// A client that has one or more entities previously obtained from the resource
193 /// can verify that one of those entities is current by including a list of their
194 /// associated entity tags in the If-Match header field.
195 /// The purpose of this feature is to allow efficient updates of cached information
196 /// with a minimum amount of transaction overhead. It is also used, on updating requests,
197 /// to prevent inadvertent modification of the wrong version of a resource.
198 /// As a special case, the value "*" matches any current entity of the resource.
200 #define HTTP_HEADER_IF_MATCH "If-Match"
204 /// The If-None-Match request-header field is used with a method to make it conditional.
205 /// A client that has one or more entities previously obtained from the resource can verify
206 /// that none of those entities is current by including a list of their associated entity
207 /// tags in the If-None-Match header field. The purpose of this feature is to allow efficient
208 /// updates of cached information with a minimum amount of transaction overhead. It is also used
209 /// to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the
210 /// client believes that the resource does not exist.
212 #define HTTP_HEADER_IF_NONE_MATCH "If-None-Match"
217 /// Authorization Request Header
218 /// The Authorization field value consists of credentials
219 /// containing the authentication information of the user agent for
220 /// the realm of the resource being requested.
222 #define HTTP_HEADER_AUTHORIZATION "Authorization"
225 /// ETAG Response Header
226 /// The ETag response-header field provides the current value of the entity tag
227 /// for the requested variant.
229 #define HTTP_HEADER_ETAG "ETag"
232 /// Custom header field checked by the iLO web server to
233 /// specify a client session key.
234 /// Example: X-Auth-Token: 24de6b1f8fa147ad59f6452def628798
236 #define HTTP_HEADER_X_AUTH_TOKEN "X-Auth-Token"
240 /// The "Expect" header field in a request indicates a certain set of
241 /// behaviors (expectations) that need to be supported by the server in
242 /// order to properly handle this request. The only such expectation
243 /// defined by this specification is 100-continue.
245 #define HTTP_HEADER_EXPECT "Expect"
248 /// Expect Header Value
250 #define HTTP_EXPECT_100_CONTINUE "100-continue"