General Header Fields


#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"

Detailed Description

There are a few header fields which have general applicability for both request and response messages, but which do not apply to the entity being transferred. These header fields apply only to the General-header field names can be extended reliably only in combination with a change in the protocol version. However, new or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize them to be general-header fields. Unrecognized header fields are treated as entity-header fields.

See also:

Define Documentation

#define HEADER_ALLOW   "Allow"

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.

#define HEADER_CACHE_CONTROL   "Cache-Control"

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.

#define HEADER_CONNECTION   "Connection"

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.

#define HEADER_CONTENT_ENCODING   "Content-Encoding"

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.

See also:

Definition at line 184 of file nanohttp-common.h.

#define HEADER_CONTENT_LANGUAGE   "Content-Language"

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.

#define HEADER_CONTENT_LENGTH   "Content-Length"

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.

See also:


Definition at line 206 of file nanohttp-common.h.

Referenced by http_input_stream_new(), http_output_stream_new(), and httpd_get_postdata().

#define HEADER_CONTENT_LOCATION   "Content-Location"

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.

#define HEADER_CONTENT_MD5   "Content-MD5"

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.

See also:

Definition at line 234 of file nanohttp-common.h.

#define HEADER_CONTENT_RANGE   "Content-Range"

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.

See also:

Definition at line 245 of file nanohttp-common.h.

#define HEADER_CONTENT_TYPE   "Content-Type"

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().

#define HEADER_DATE   "Date"

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.

See also:

Definition at line 81 of file nanohttp-common.h.

#define HEADER_EXPIRES   "Expires"

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.

See also:

Definition at line 268 of file nanohttp-common.h.

#define HEADER_LAST_MODIFIED   "Last-Modified"

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.

#define HEADER_PRAGMA   "Pragma"

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.

#define HEADER_TRAILER   "Trailer"

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.

#define HEADER_TRANSFER_ENCODING   "Transfer-Encoding"

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.

#define HEADER_UPGRADE   "Upgrade"

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.

#define HEADER_VIA   "Via"

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.

See also:

Definition at line 136 of file nanohttp-common.h.

#define HEADER_WARNING   "Warning"

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.

Generated on Thu Jan 25 23:36:04 2007 for csoap by  doxygen 1.4.6