Jonathan Zhang | 6d27778 | 2020-06-09 17:56:53 -0700 | [diff] [blame] | 1 | /** @file |
| 2 | Hypertext Transfer Protocol -- HTTP/1.1 Standard definitions, from RFC 2616 |
| 3 | |
| 4 | This file contains common HTTP 1.1 definitions from RFC 2616 |
| 5 | |
| 6 | (C) Copyright 2015-2016 Hewlett Packard Enterprise Development LP<BR> |
| 7 | SPDX-License-Identifier: BSD-2-Clause-Patent |
| 8 | **/ |
| 9 | |
| 10 | #ifndef __HTTP_11_H__ |
| 11 | #define __HTTP_11_H__ |
| 12 | |
| 13 | #pragma pack(1) |
| 14 | |
| 15 | /// |
| 16 | /// HTTP Version (currently HTTP 1.1) |
| 17 | /// |
| 18 | /// The version of an HTTP message is indicated by an HTTP-Version field |
| 19 | /// in the first line of the message. |
| 20 | /// |
| 21 | #define HTTP_VERSION "HTTP/1.1" |
| 22 | |
| 23 | /// |
| 24 | /// HTTP Request Method definitions |
| 25 | /// |
| 26 | /// The Method token indicates the method to be performed on the |
| 27 | /// resource identified by the Request-URI. The method is case-sensitive. |
| 28 | /// |
| 29 | #define HTTP_METHOD_OPTIONS "OPTIONS" |
| 30 | #define HTTP_METHOD_GET "GET" |
| 31 | #define HTTP_METHOD_HEAD "HEAD" |
| 32 | #define HTTP_METHOD_POST "POST" |
| 33 | #define HTTP_METHOD_PUT "PUT" |
| 34 | #define HTTP_METHOD_DELETE "DELETE" |
| 35 | #define HTTP_METHOD_TRACE "TRACE" |
| 36 | #define HTTP_METHOD_CONNECT "CONNECT" |
| 37 | #define HTTP_METHOD_PATCH "PATCH" |
| 38 | |
| 39 | /// |
| 40 | /// Connect method has maximum length according to EFI_HTTP_METHOD defined in |
| 41 | /// UEFI2.5 spec so use this. |
| 42 | /// |
| 43 | #define HTTP_METHOD_MAXIMUM_LEN sizeof (HTTP_METHOD_CONNECT) |
| 44 | |
| 45 | /// |
| 46 | /// Accept Request Header |
| 47 | /// The Accept request-header field can be used to specify certain media types which are |
| 48 | /// acceptable for the response. Accept headers can be used to indicate that the request |
| 49 | /// is specifically limited to a small set of desired types, as in the case of a request |
| 50 | /// for an in-line image. |
| 51 | /// |
| 52 | #define HTTP_HEADER_ACCEPT "Accept" |
| 53 | |
| 54 | |
| 55 | /// |
| 56 | /// Accept-Charset Request Header |
| 57 | /// The Accept-Charset request-header field can be used to indicate what character sets |
| 58 | /// are acceptable for the response. This field allows clients capable of understanding |
| 59 | /// more comprehensive or special-purpose character sets to signal that capability to a |
| 60 | /// server which is capable of representing documents in those character sets. |
| 61 | /// |
| 62 | #define HTTP_HEADER_ACCEPT_CHARSET "Accept-Charset" |
| 63 | |
| 64 | /// |
| 65 | /// Accept-Language Request Header |
| 66 | /// The Accept-Language request-header field is similar to Accept, |
| 67 | /// but restricts the set of natural languages that are preferred |
| 68 | /// as a response to the request. |
| 69 | /// |
| 70 | #define HTTP_HEADER_ACCEPT_LANGUAGE "Accept-Language" |
| 71 | |
| 72 | /// |
| 73 | /// Accept-Ranges Request Header |
| 74 | /// The Accept-Ranges response-header field allows the server to |
| 75 | /// indicate its acceptance of range requests for a resource: |
| 76 | /// |
| 77 | #define HTTP_HEADER_ACCEPT_RANGES "Accept-Ranges" |
| 78 | |
| 79 | |
| 80 | /// |
| 81 | /// Accept-Encoding Request Header |
| 82 | /// The Accept-Encoding request-header field is similar to Accept, |
| 83 | /// but restricts the content-codings that are acceptable in the response. |
| 84 | /// |
| 85 | #define HTTP_HEADER_ACCEPT_ENCODING "Accept-Encoding" |
| 86 | |
| 87 | /// |
| 88 | /// Content-Encoding Header |
| 89 | /// The Content-Encoding entity-header field is used as a modifier to the media-type. |
| 90 | /// When present, its value indicates what additional content codings have been applied |
| 91 | /// to the entity-body, and thus what decoding mechanisms must be applied in order to |
| 92 | /// obtain the media-type referenced by the Content-Type header field. Content-Encoding |
| 93 | /// is primarily used to allow a document to be compressed without losing the identity |
| 94 | /// of its underlying media type. |
| 95 | /// |
| 96 | #define HTTP_HEADER_CONTENT_ENCODING "Content-Encoding" |
| 97 | |
| 98 | /// |
| 99 | /// HTTP Content-Encoding Compression types |
| 100 | /// |
| 101 | |
| 102 | #define HTTP_CONTENT_ENCODING_IDENTITY "identity" /// No transformation is used. This is the default value for content coding. |
| 103 | #define HTTP_CONTENT_ENCODING_GZIP "gzip" /// Content-Encoding: GNU zip format (described in RFC 1952). |
| 104 | #define HTTP_CONTENT_ENCODING_COMPRESS "compress" /// encoding format produced by the common UNIX file compression program "compress". |
| 105 | #define HTTP_CONTENT_ENCODING_DEFLATE "deflate" /// The "zlib" format defined in RFC 1950 in combination with the "deflate" |
| 106 | /// compression mechanism described in RFC 1951. |
| 107 | |
| 108 | |
| 109 | /// |
| 110 | /// Content-Type Header |
| 111 | /// The Content-Type entity-header field indicates the media type of the entity-body sent to |
| 112 | /// the recipient or, in the case of the HEAD method, the media type that would have been sent |
| 113 | /// had the request been a GET. |
| 114 | /// |
| 115 | #define HTTP_HEADER_CONTENT_TYPE "Content-Type" |
| 116 | // |
| 117 | // Common Media Types defined in http://www.iana.org/assignments/media-types/media-types.xhtml |
| 118 | // |
| 119 | #define HTTP_CONTENT_TYPE_APP_JSON "application/json" |
| 120 | #define HTTP_CONTENT_TYPE_APP_OCTET_STREAM "application/octet-stream" |
| 121 | |
| 122 | #define HTTP_CONTENT_TYPE_TEXT_HTML "text/html" |
| 123 | #define HTTP_CONTENT_TYPE_TEXT_PLAIN "text/plain" |
| 124 | #define HTTP_CONTENT_TYPE_TEXT_CSS "text/css" |
| 125 | #define HTTP_CONTENT_TYPE_TEXT_XML "text/xml" |
| 126 | |
| 127 | #define HTTP_CONTENT_TYPE_IMAGE_GIF "image/gif" |
| 128 | #define HTTP_CONTENT_TYPE_IMAGE_JPEG "image/jpeg" |
| 129 | #define HTTP_CONTENT_TYPE_IMAGE_PNG "image/png" |
| 130 | #define HTTP_CONTENT_TYPE_IMAGE_SVG_XML "image/svg+xml" |
| 131 | |
| 132 | |
| 133 | /// |
| 134 | /// Content-Length Header |
| 135 | /// The Content-Length entity-header field indicates the size of the entity-body, |
| 136 | /// in decimal number of OCTETs, sent to the recipient or, in the case of the HEAD |
| 137 | /// method, the size of the entity-body that would have been sent had the request been a GET. |
| 138 | /// |
| 139 | #define HTTP_HEADER_CONTENT_LENGTH "Content-Length" |
| 140 | |
| 141 | /// |
| 142 | /// Transfer-Encoding Header |
| 143 | /// The Transfer-Encoding general-header field indicates what (if any) type of transformation |
| 144 | /// has been applied to the message body in order to safely transfer it between the sender |
| 145 | /// and the recipient. This differs from the content-coding in that the transfer-coding |
| 146 | /// is a property of the message, not of the entity. |
| 147 | /// |
| 148 | #define HTTP_HEADER_TRANSFER_ENCODING "Transfer-Encoding" |
| 149 | |
| 150 | |
| 151 | /// |
| 152 | /// User Agent Request Header |
| 153 | /// |
| 154 | /// The User-Agent request-header field contains information about the user agent originating |
| 155 | /// the request. This is for statistical purposes, the tracing of protocol violations, and |
| 156 | /// automated recognition of user agents for the sake of tailoring responses to avoid |
| 157 | /// particular user agent limitations. User agents SHOULD include this field with requests. |
| 158 | /// The field can contain multiple product tokens and comments identifying the agent and any |
| 159 | /// subproducts which form a significant part of the user agent. |
| 160 | /// By convention, the product tokens are listed in order of their significance for |
| 161 | /// identifying the application. |
| 162 | /// |
| 163 | #define HTTP_HEADER_USER_AGENT "User-Agent" |
| 164 | |
| 165 | /// |
| 166 | /// Host Request Header |
| 167 | /// |
| 168 | /// The Host request-header field specifies the Internet host and port number of the resource |
| 169 | /// being requested, as obtained from the original URI given by the user or referring resource |
| 170 | /// |
| 171 | #define HTTP_HEADER_HOST "Host" |
| 172 | |
| 173 | /// |
| 174 | /// Location Response Header |
| 175 | /// |
| 176 | /// The Location response-header field is used to redirect the recipient to a location other than |
| 177 | /// the Request-URI for completion of the request or identification of a new resource. |
| 178 | /// For 201 (Created) responses, the Location is that of the new resource which was created by |
| 179 | /// the request. For 3xx responses, the location SHOULD indicate the server's preferred URI for |
| 180 | /// automatic redirection to the resource. The field value consists of a single absolute URI. |
| 181 | /// |
| 182 | #define HTTP_HEADER_LOCATION "Location" |
| 183 | |
| 184 | /// |
| 185 | /// The If-Match request-header field is used with a method to make it conditional. |
| 186 | /// A client that has one or more entities previously obtained from the resource |
| 187 | /// can verify that one of those entities is current by including a list of their |
| 188 | /// associated entity tags in the If-Match header field. |
| 189 | /// The purpose of this feature is to allow efficient updates of cached information |
| 190 | /// with a minimum amount of transaction overhead. It is also used, on updating requests, |
| 191 | /// to prevent inadvertent modification of the wrong version of a resource. |
| 192 | /// As a special case, the value "*" matches any current entity of the resource. |
| 193 | /// |
| 194 | #define HTTP_HEADER_IF_MATCH "If-Match" |
| 195 | |
| 196 | |
| 197 | /// |
| 198 | /// The If-None-Match request-header field is used with a method to make it conditional. |
| 199 | /// A client that has one or more entities previously obtained from the resource can verify |
| 200 | /// that none of those entities is current by including a list of their associated entity |
| 201 | /// tags in the If-None-Match header field. The purpose of this feature is to allow efficient |
| 202 | /// updates of cached information with a minimum amount of transaction overhead. It is also used |
| 203 | /// to prevent a method (e.g. PUT) from inadvertently modifying an existing resource when the |
| 204 | /// client believes that the resource does not exist. |
| 205 | /// |
| 206 | #define HTTP_HEADER_IF_NONE_MATCH "If-None-Match" |
| 207 | |
| 208 | |
| 209 | |
| 210 | /// |
| 211 | /// Authorization Request Header |
| 212 | /// The Authorization field value consists of credentials |
| 213 | /// containing the authentication information of the user agent for |
| 214 | /// the realm of the resource being requested. |
| 215 | /// |
| 216 | #define HTTP_HEADER_AUTHORIZATION "Authorization" |
| 217 | |
| 218 | /// |
| 219 | /// ETAG Response Header |
| 220 | /// The ETag response-header field provides the current value of the entity tag |
| 221 | /// for the requested variant. |
| 222 | /// |
| 223 | #define HTTP_HEADER_ETAG "ETag" |
| 224 | |
| 225 | /// |
| 226 | /// Custom header field checked by the iLO web server to |
| 227 | /// specify a client session key. |
| 228 | /// Example: X-Auth-Token: 24de6b1f8fa147ad59f6452def628798 |
| 229 | /// |
| 230 | #define HTTP_HEADER_X_AUTH_TOKEN "X-Auth-Token" |
| 231 | |
| 232 | /// |
| 233 | /// Expect Header |
| 234 | /// The "Expect" header field in a request indicates a certain set of |
| 235 | /// behaviors (expectations) that need to be supported by the server in |
| 236 | /// order to properly handle this request. The only such expectation |
| 237 | /// defined by this specification is 100-continue. |
| 238 | /// |
| 239 | #define HTTP_HEADER_EXPECT "Expect" |
| 240 | |
| 241 | /// |
| 242 | /// Expect Header Value |
| 243 | /// |
| 244 | #define HTTP_EXPECT_100_CONTINUE "100-continue" |
| 245 | |
| 246 | #pragma pack() |
| 247 | |
| 248 | #endif |