Defines | |
#define | HEADER_CACHE_CONTROL "Cache-Control" |
#define | HEADER_CONNECTION "Connection" |
#define | HEADER_DATE "Date" |
#define | HEADER_PRAGMA "Pragma" |
#define | HEADER_TRAILER "Trailer" |
#define | HEADER_TRANSFER_ENCODING "Transfer-Encoding" |
#define | HEADER_UPGRADE "Upgrade" |
#define | HEADER_VIA "Via" |
#define | HEADER_WARNING "Warning" |
#define | HEADER_ALLOW "Allow" |
#define | HEADER_CONTENT_ENCODING "Content-Encoding" |
#define | HEADER_CONTENT_LANGUAGE "Content-Language" |
#define | HEADER_CONTENT_LENGTH "Content-Length" |
#define | HEADER_CONTENT_LOCATION "Content-Location" |
#define | HEADER_CONTENT_MD5 "Content-MD5" |
#define | HEADER_CONTENT_RANGE "Content-Range" |
#define | HEADER_CONTENT_TYPE "Content-Type" |
#define | HEADER_EXPIRES "Expires" |
#define | HEADER_LAST_MODIFIED "Last-Modified" |
|
The Allow entity-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field MUST be present in a 405 (Method Not Allowed) response. Definition at line 170 of file nanohttp-common.h. |
|
The Cache-Control general-header field is used to specify directives that MUST be obeyed by all caching mechanisms along the request/response chain. The directives specify behavior intended to prevent caches from adversely interfering with the request or response. These directives typically override the default caching algorithms. 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. Definition at line 58 of file nanohttp-common.h. |
|
The Connection general-header field allows the sender to specify options that are desired for that particular connection and MUST NOT be communicated by proxies over further connections. Definition at line 67 of file nanohttp-common.h. |
|
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.
Definition at line 184 of file nanohttp-common.h. |
|
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body. Definition at line 193 of file nanohttp-common.h. |
|
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.
Definition at line 206 of file nanohttp-common.h. Referenced by http_input_stream_new(), http_output_stream_new(), and httpd_get_postdata(). |
|
The Content-Location entity-header field MAY be used to supply the resource location for the entity enclosed in the message when that entity is accessible from a location separate from the requested resource's URI. A server SHOULD provide a Content-Location for the variant corresponding to the response entity; especially in the case where a resource has multiple entities associated with it, and those entities actually have separate locations by which they might be individually accessed, the server SHOULD provide a Content-Location for the particular variant which is returned. Definition at line 220 of file nanohttp-common.h. |
|
The Content-MD5 entity-header field, as defined in RFC 1864, is an MD5 digest of the entity-body for the purpose of providing an end-to-end message integrity check (MIC) of the entity-body. Note: a MIC is good for detecting accidental modification of the entity-body in transit, but is not proof against malicious attacks.
Definition at line 234 of file nanohttp-common.h. |
|
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. Range units are defined in RFC 2616 section 3.12.
Definition at line 245 of file nanohttp-common.h. |
|
The Content-Type entity-header field indicates the media type of the entity-body sent to the recipient or, in the case of the HEAD method, the media type that would have been sent had the request been a GET. Definition at line 254 of file nanohttp-common.h. Referenced by httpc_mime_begin(), httpc_mime_next(), httpd_mime_next(), httpd_mime_send_header(), and part_new(). |
|
The Date general-header field represents the date and time at which the message was originated, having the same semantics as orig-date in RFC 822. The field value is an HTTP-date, as described in RDF 2616 section 3.3.1; it MUST be sent in RFC 1123 date format.
Definition at line 81 of file nanohttp-common.h. |
|
The Expires entity-header field gives the date/time after which the response is considered stale. A stale cache entry may not normally be returned by a cache (either a proxy cache or a user agent cache) unless it is first validated with the origin server (or with an intermediate cache that has a fresh copy of the entity). See RFC 2616 section 13.2 for further discussion of the expiration model.
Definition at line 268 of file nanohttp-common.h. |
|
The Last-Modified entity-header field indicates the date and time at which the origin server believes the variant was last modified. Definition at line 276 of file nanohttp-common.h. |
|
The Pragma general-header field is used to include implementation-specific directives that might apply to any recipient along the request/response chain. All pragma directives specify optional behavior from the viewpoint of the protocol; however, some systems MAY require that behavior be consistent with the directives. Definition at line 92 of file nanohttp-common.h. |
|
The Trailer general field value indicates that the given set of header fields is present in the trailer of a message encoded with chunked transfer-coding. Definition at line 100 of file nanohttp-common.h. |
|
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. Definition at line 111 of file nanohttp-common.h. |
|
The Upgrade general-header allows the client to specify what additional communication protocols it supports and would like to use if the server finds it appropriate to switch protocols. The server MUST use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched. Definition at line 122 of file nanohttp-common.h. |
|
The Via general-header field MUST be used by gateways and proxies to indicate the intermediate protocols and recipients between the user agent and the server on requests, and between the origin server and the client on responses. It is analogous to the "Received" field of RFC 822 and is intended to be used for tracking message forwards, avoiding request loops, and identifying the protocol capabilities of all senders along the request/response chain.
Definition at line 136 of file nanohttp-common.h. |
|
The Warning general-header field is used to carry additional information about the status or transformation of a message which might not be reflected in the message. This information is typically used to warn about a possible lack of semantic transparency from caching operations or transformations applied to the entity body of the message. Definition at line 147 of file nanohttp-common.h. |