Documentation enhancements

1 files changed, 676 insertions, 2 deletions

diff --git a/nanohttp/nanohttp-common.h b/nanohttp/nanohttp-common.h
index 2356259..2cf6b90 100644
--- a/nanohttp/nanohttp-common.h
+++ b/nanohttp/nanohttp-common.h
@@ -1,5 +1,5 @@
 /******************************************************************
- *  $Id: nanohttp-common.h,v 1.41 2006/12/10 12:23:45 m0gg Exp $
+ *  $Id: nanohttp-common.h,v 1.42 2006/12/10 13:20:38 m0gg Exp $
  * 
  * CSOAP Project:  A http client/server library in C
  * Copyright (C) 2003-2004  Ferhat Ayaz
@@ -447,7 +447,7 @@ typedef enum _hreq_method
   HTTP_REQUEST_UNKOWN
 } hreq_method_t;
 
-/**
+/** @defgroup http_status HTTP status-codes
  *
  * The Status-Code element is a 3-digit integer result code of the attempt to
  * understand and satisfy the request. These codes are fully defined in section
@@ -484,50 +484,724 @@ typedef enum _hreq_method
  * since that entity is likely to include human-readable information which will
  * explain the unusual status.
  *
+ * \subsection status_informational_sec Informational 1xx
+ *
+ * This class of status code indicates a provisional response, consisting only
+ * of the Status-Line and optional headers, and is terminated by an empty line.
+ * There are no required headers for this class of status code. Since HTTP/1.0
+ * did not define any 1xx status codes, servers MUST NOT send a 1xx response to
+ * an HTTP/1.0 client except under experimental conditions.
+ *
+ * A client MUST be prepared to accept one or more 1xx status responses prior to
+ * a regular response, even if the client does not expect a 100 (Continue)
+ * status message. Unexpected 1xx status responses MAY be ignored by a user
+ * agent.
+ *
+ * Proxies MUST forward 1xx responses, unless the connection between the proxy
+ * and its client has been closed, or unless the proxy itself requested the
+ * generation of the 1xx response. (For example, if a proxy adds a
+ * "Expect: 100-continue" field when it forwards a request, then it need not
+ * forward the corresponding 100 (Continue) response(s).)
+ *
+ * \subsection status_successful_sec Successful 2xx
+ *
+ * This class of status code indicates that the client's request was
+ * successfully received, understood, and accepted.
+ *
+ * \subsection status_refirection_sec Redirection 3xx
+ *
+ * This class of status code indicates that further action needs to be taken by
+ * the user agent in order to fulfill the request.  The action required MAY be
+ * carried out by the user agent without interaction with the user if and only
+ * if the method used in the second request is GET or HEAD. A client SHOULD
+ * detect infinite redirection loops, since such loops generate network traffic
+ * for each redirection.
+ *
+ * \subsection status_client_error_sec Client Error 4xx
+ *
+ * The 4xx class of status code is intended for cases in which the client seems
+ * to have erred. Except when responding to a HEAD request, the server SHOULD
+ * include an entity containing an explanation of the error situation, and
+ * whether it is a temporary or permanent condition. These status codes are
+ * applicable to any request method. User agents SHOULD display any included
+ * entity to the user.
+ *
+ * If the client is sending data, a server implementation using TCP SHOULD be
+ * careful to ensure that the client acknowledges receipt of the packet(s)
+ * containing the response, before the server closes the input connection. If
+ * the client continues sending data to the server after the close, the server's
+ * TCP stack will send a reset packet to the client, which may erase the client's
+ * unacknowledged input buffers before they can be read and interpreted by the
+ * HTTP application.
+ *
+ * \subsection status_server_error_sec Server Error 5xx
+ *
+ * Response status codes beginning with the digit "5" indicate cases in which
+ * the server is aware that it has erred or is incapable of performing the
+ * request. Except when responding to a HEAD request, the server SHOULD include
+ * an entity containing an explanation of the error situation, and whether it is
+ * a temporary or permanent condition. User agents SHOULD display any included
+ * entity to the user. These response codes are applicable to any request method.
+ *
+ * Each Status-Code is described below, including a description of which
+ * method(s) it can follow and any metainformation required in the response.
+ *
+ * @see http://www.ietf.org/rfc/rfc2616.txt
+ *
+ */
+/*{*/
+
+/**
+ *
+ * The client SHOULD continue with its request. This interim response is used to
+ * inform the client that the initial part of the request has been received and
+ * has not yet been rejected by the server. The client SHOULD continue by sending
+ * the remainder of the request or, if the request has already been completed,
+ * ignore this response. The server MUST send a final response after the request
+ * has been completed. See RFC 2616 section 8.2.3 for detailed discussion of the
+ * use and handling of this status code.
+ *
  * @see http://www.ietf.org/rfc/rfc2616.txt
  *
  */
 #define HTTP_STATUS_100_REASON_PHRASE	"Continue"
+
+/**
+ *
+ * The server understands and is willing to comply with the client's request,
+ * via the Upgrade message header field (RFC 2616 section 14.42), for a change
+ * in the application protocol being used on this connection. The server will
+ * switch protocols to those defined by the response's Upgrade header field
+ * immediately after the empty line which terminates the 101 response.
+ *
+ * The protocol SHOULD be switched only when it is advantageous to do so. For
+ * example, switching to a newer version of HTTP is advantageous over older
+ * versions, and switching to a real-time, synchronous protocol might be
+ * advantageous when delivering resources that use such features.
+ *
+ */
 #define HTTP_STATUS_101_REASON_PHRASE	"Switching Protocols"
+
+/**
+ *
+ * The request has succeeded. The information returned with the response is
+ * dependent on the method used in the request, for example:
+ *
+ * GET    an entity corresponding to the requested resource is sent in
+ *        the response;
+ *
+ * HEAD   the entity-header fields corresponding to the requested
+ *        resource are sent in the response without any message-body;
+ *
+ * POST   an entity describing or containing the result of the action;
+ *
+ * TRACE  an entity containing the request message as received by the
+ *        end server.
+ *
+ */
 #define HTTP_STATUS_200_REASON_PHRASE	"OK"
+
+/**
+ *
+ * The request has been fulfilled and resulted in a new resource being created.
+ * The newly created resource can be referenced by the URI(s) returned in the
+ * entity of the response, with the most specific URI for the resource given by
+ * a Location header field. The response SHOULD include an entity containing a
+ * list of resource characteristics and location(s) from which the user or user
+ * agent can choose the one most appropriate. The entity format is specified by
+ * the media type given in the Content-Type header field. The origin server MUST
+ * create the resource before returning the 201 status code. If the action cannot
+ * be carried out immediately, the server SHOULD respond with 202 (Accepted)
+ * response instead.
+ *
+ * A 201 response MAY contain an ETag response header field indicating the
+ * current value of the entity tag for the requested variant just created, see
+ * RFC 2616 section 14.19.
+ *
+ * @see http://www.ietf.org/rfc/rfc2616.txt
+ *
+ */
 #define HTTP_STATUS_201_REASON_PHRASE	"Created"
+
+/**
+ *
+ * The request has been accepted for processing, but the processing has not been
+ * completed.  The request might or might not eventually be acted upon, as it
+ * might be disallowed when processing actually takes place. There is no
+ * facility for re-sending a status code from an asynchronous operation such as
+ * this.
+ *
+ * The 202 response is intentionally non-committal. Its purpose is to allow a
+ * server to accept a request for some other process (perhaps a batch-oriented
+ * process that is only run once per day) without requiring that the user
+ * agent's connection to the server persist until the process is completed. The
+ * entity returned with this response SHOULD include an indication of the
+ * request's current status and either a pointer to a status monitor or some
+ * estimate of when the user can expect the request to be fulfilled.
+ *
+ */
 #define HTTP_STATUS_202_REASON_PHRASE	"Accepted"
+
+/**
+ *
+ * The returned metainformation in the entity-header is not the definitive set
+ * as available from the origin server, but is gathered from a local or a
+ * third-party copy. The set presented MAY be a subset or superset of the
+ * original version. For example, including local annotation information about
+ * the resource might result in a superset of the metainformation known by the
+ * origin server. Use of this response code is not required and is only
+ * appropriate when the response would otherwise be 200 (OK).
+ *
+ */
 #define HTTP_STATUS_203_REASON_PHRASE	"Non-Authoritative Information"
+
+/**
+ *
+ * The server has fulfilled the request but does not need to return an
+ * entity-body, and might want to return updated metainformation. The response
+ * MAY include new or updated metainformation in the form of entity-headers,
+ * which if present SHOULD be associated with the requested variant.
+ *
+ * If the client is a user agent, it SHOULD NOT change its document view from
+ * that which caused the request to be sent. This response is primarily intended
+ * to allow input for actions to take place without causing a change to the user
+ * agent's active document view, although any new or updated metainformation
+ * SHOULD be applied to the document currently in the user agent's active view.
+ *
+ * The 204 response MUST NOT include a message-body, and thus is always
+ * terminated by the first empty line after the header fields.
+ *
+ */
 #define HTTP_STATUS_204_REASON_PHRASE	"No Content"
+
+/**
+ *
+ * The server has fulfilled the request and the user agent SHOULD reset the
+ * document view which caused the request to be sent. This response is primarily
+ * intended to allow input for actions to take place via user input, followed by
+ * a clearing of the form in which the input is given so that the user can
+ * easily initiate another input action. The response MUST NOT include an
+ * entity.
+ *
+ */
 #define HTTP_STATUS_205_REASON_PHRASE	"Reset Content"
+
+/**
+ *
+ * The server has fulfilled the partial GET request for the resource. The request
+ * MUST have included a Range header field (RFC 2616 section 14.35) indicating
+ * the desired range, and MAY have included an If-Range header field (RFC 2616 
+ * section 14.27) to make the request conditional.
+ *
+ * The response MUST include the following header fields:
+ *
+ * - Either a Content-Range header field (section 14.16) indicating the range
+ *   included with this response, or a multipart/byteranges Content-Type
+ *   including Content-Range fields for each part. If a Content-Length header
+ *   field is present in the response, its value MUST match the actual number of
+ *   OCTETs transmitted in the message-body.
+ * - Date
+ * - ETag and/or Content-Location, if the header would have been sent in a 200
+ *   response to the same request
+ * - Expires, Cache-Control, and/or Vary, if the field-value might differ from
+ *   that sent in any previous response for the same variant.
+ *
+ * If the 206 response is the result of an If-Range request that used a strong
+ * cache validator (see RFC 2616 section 13.3.3), the response SHOULD NOT include
+ * other entity-headers. If the response is the result of an If-Range request
+ * that used a weak validator, the response MUST NOT include other
+ * entity-headers; this prevents inconsistencies between cached entity-bodies and
+ * updated headers. Otherwise, the response MUST include all of the
+ * entity-headers that would have been returned with a 200 (OK) response to the
+ * same request.
+ *
+ * A cache MUST NOT combine a 206 response with other previously cached content
+ * if the ETag or Last-Modified headers do not match exactly, see RFC 2616
+ * section 13.5.4.
+ *
+ * A cache that does not support the Range and Content-Range headers MUST NOT
+ * cache 206 (Partial) responses.
+ *
+ */
 #define HTTP_STATUS_206_REASON_PHRASE	"Partial Content"
+
+/**
+ *
+ * The requested resource corresponds to any one of a set of representations,
+ * each with its own specific location, and agent-driven negotiation information
+ * (RFC 2616 section 12) is being provided so that the user (or user agent) can
+ * select a preferred representation and redirect its request to that location.
+ *
+ * Unless it was a HEAD request, the response SHOULD include an entity containing
+ * a list of resource characteristics and location(s) from which the user or user
+ * agent can choose the one most appropriate. The entity format is specified by
+ * the media type given in the Content-Type header field. Depending upon the
+ * format and the capabilities of the user agent, selection of the most
+ * appropriate choice MAY be performed automatically. However, this
+ * specification does not define any standard for such automatic selection.
+ *
+ * If the server has a preferred choice of representation, it SHOULD include the
+ * specific URI for that representation in the Location field; user agents MAY
+ * use the Location field value for automatic redirection. This response is
+ * cacheable unless indicated otherwise.
+ *
+ */
 #define HTTP_STATUS_300_REASON_PHRASE	"Multiple Choices"
+
+/**
+ *
+ * The requested resource has been assigned a new permanent URI and any future
+ * references to this resource SHOULD use one of the returned URIs.  Clients
+ * with link editing capabilities ought to automatically re-link references to
+ * the Request-URI to one or more of the new references returned by the server,
+ * where possible. This response is cacheable unless indicated otherwise.
+ *
+ * The new permanent URI SHOULD be given by the Location field in the response.
+ * Unless the request method was HEAD, the entity of the response SHOULD contain
+ * a short hypertext note with a hyperlink to the new URI(s).
+ *
+ * If the 301 status code is received in response to a request other than GET or
+ * HEAD, the user agent MUST NOT automatically redirect the request unless it can
+ * be confirmed by the user, since this might change the conditions under which
+ * the request was issued.
+ *
+ */
 #define HTTP_STATUS_301_REASON_PHRASE	"Moved Permanently"
+
+/**
+ *
+ * The requested resource resides temporarily under a different URI. Since the
+ * redirection might be altered on occasion, the client SHOULD continue to use
+ * the Request-URI for future requests.  This response is only cacheable if
+ * indicated by a Cache-Control or Expires header field.
+ *
+ * The temporary URI SHOULD be given by the Location field in the response.
+ * Unless the request method was HEAD, the entity of the response SHOULD contain
+ * a short hypertext note with a hyperlink to the new URI(s).
+ *
+ * If the 302 status code is received in response to a request other than GET or
+ * HEAD, the user agent MUST NOT automatically redirect the request unless it can
+ * be confirmed by the user, since this might change the conditions under which
+ * the request was issued.
+ *
+ * Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change
+ * the method on the redirected request. However, most existing user agent
+ * implementations treat 302 as if it were a 303 response, performing a GET on
+ * the Location field-value regardless of the original request method. The
+ * status codes 303 and 307 have been added for servers that wish to make
+ * unambiguously clear which kind of reaction is expected of the client.
+ *
+ */
 #define HTTP_STATUS_302_REASON_PHRASE	"Found"
+
+/**
+ *
+ * The response to the request can be found under a different URI and SHOULD be
+ * retrieved using a GET method on that resource. This method exists primarily to
+ * allow the output of a POST-activated script to redirect the user agent to a
+ * selected resource. The new URI is not a substitute reference for the
+ * originally requested resource. The 303 response MUST NOT be cached, but the
+ * response to the second (redirected) request might be cacheable.
+ *
+ * The different URI SHOULD be given by the Location field in the response.
+ * Unless the request method was HEAD, the entity of the response SHOULD contain
+ * a short hypertext note with a hyperlink to the new URI(s).
+ *
+ * Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When
+ * interoperability with such clients is a concern, the 302 status code may be
+ * used instead, since most user agents react to a 302 response as described
+ * here for 303.
+ *
+ */
 #define HTTP_STATUS_303_REASON_PHRASE	"See Other"
+
+/**
+ *
+ * If the client has performed a conditional GET request and access is allowed,
+ * but the document has not been modified, the server SHOULD respond with this
+ * status code. The 304 response MUST NOT contain a message-body, and thus is
+ * always terminated by the first empty line after the header fields.
+ *
+ * The response MUST include the following header fields:
+ *
+ * - Date, unless its omission is required by RFC 2616 section 14.18.1
+ *
+ * If a clockless origin server obeys these rules, and proxies and clients add
+ * their own Date to any response received without one (as already specified by
+ * [RFC 2068], section 14.19), caches will operate correctly.
+ *
+ * - ETag and/or Content-Location, if the header would have been sent in a 200
+ *   response to the same request
+ * - Expires, Cache-Control, and/or Vary, if the field-value might differ from
+ *   that sent in any previous response for the same variant
+ *
+ * If the conditional GET used a strong cache validator (see RFC 2616 section
+ * 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise
+ * (i.e., the conditional GET used a weak validator), the response MUST NOT
+ * include other entity-headers; this prevents inconsistencies between cached
+ * entity-bodies and updated headers.
+ *
+ * If a 304 response indicates an entity not currently cached, then the cache
+ * MUST disregard the response and repeat the request without the conditional.
+ *
+ * If a cache uses a received 304 response to update a cache entry, the cache
+ * MUST update the entry to reflect any new field values given in the response.
+ *
+ */
 #define HTTP_STATUS_304_REASON_PHRASE	"Not Modified"
+
+/**
+ *
+ * The requested resource MUST be accessed through the proxy given by the
+ * Location field. The Location field gives the URI of the proxy. The recipient
+ * is expected to repeat this single request via the proxy. 305 responses MUST
+ * only be generated by origin servers.
+ *
+ * Note: RFC 2068 was not clear that 305 was intended to redirect a single
+ * request, and to be generated by origin servers only.  Not observing these
+ * limitations has significant security consequences.
+ *
+ */
 #define HTTP_STATUS_305_REASON_PHRASE	"Use Proxy"
+
+/**
+ *
+ * The requested resource resides temporarily under a different URI. Since the
+ * redirection MAY be altered on occasion, the client SHOULD continue to use the
+ * Request-URI for future requests.  This response is only cacheable if indicated
+ * by a Cache-Control or Expires header field.
+ *
+ * The temporary URI SHOULD be given by the Location field in the response.
+ * Unless the request method was HEAD, the entity of the response SHOULD contain
+ * a short hypertext note with a hyperlink to the new URI(s) , since many
+ * pre-HTTP/1.1 user agents do not understand the 307 status. Therefore, the
+ * note SHOULD contain the information necessary for a user to repeat the
+ * original request on the new URI.
+ *
+ * If the 307 status code is received in response to a request other than GET or
+ * HEAD, the user agent MUST NOT automatically redirect the request unless it can
+ * be confirmed by the user, since this might change the conditions under which
+ * the request was issued.
+ *
+ */
 #define HTTP_STATUS_307_REASON_PHRASE	"Temporary Redirect"
+
+/**
+ *
+ * The request could not be understood by the server due to malformed syntax.
+ * The client SHOULD NOT repeat the request without modifications.
+ *
+ */
 #define HTTP_STATUS_400_REASON_PHRASE	"Bad Request"
+
+/**
+ *
+ * The request requires user authentication. The response MUST include a
+ * WWW-Authenticate header field (RFC 2616 section 14.47) containing a challenge
+ * applicable to the requested resource. The client MAY repeat the request with
+ * a suitable Authorization header field (RFC 2616 section 14.8). If the request
+ * already included Authorization credentials, then the 401 response indicates
+ * that authorization has been refused for those credentials. If the 401
+ * response contains the same challenge as the prior response, and the user
+ * agent has already attempted authentication at least once, then the user
+ * SHOULD be presented the entity that was given in the response, since that
+ * entity might include relevant diagnostic information. HTTP access
+ * authentication is explained in RFC 2617 "HTTP Authentication: Basic and
+ * Digest Access Authentication"
+ *
+ * @see http://www.ietf.org/rfc/rfc2616.txt
+ * @see http://www.ietf.org/rfc/rfc2617.txt
+ *
+ */
 #define HTTP_STATUS_401_REASON_PHRASE	"Unauthorized"
+
+/**
+ *
+ * This code is reserved for future use.
+ *
+ */
 #define HTTP_STATUS_402_REASON_PHRASE	"Payment Required"
+
+/**
+ *
+ * The server understood the request, but is refusing to fulfill it.
+ * Authorization will not help and the request SHOULD NOT be repeated. If the
+ * request method was not HEAD and the server wishes to make public why the
+ * request has not been fulfilled, it SHOULD describe the reason for the refusal
+ * in the entity.  If the server does not wish to make this information
+ * available to the client, the status code 404 (Not Found) can be used instead.
+ *
+ */
 #define HTTP_STATUS_403_REASON_PHRASE	"Forbidden"
+
+/**
+ *
+ * The server has not found anything matching the Request-URI. No indication is
+ * given of whether the condition is temporary or permanent. The 410 (Gone)
+ * status code SHOULD be used if the server knows, through some internally
+ * configurable mechanism, that an old resource is permanently unavailable and
+ * has no forwarding address. This status code is commonly used when the server
+ * does not wish to reveal exactly why the request has been refused, or when no
+ * other response is applicable.
+ *
+ */
 #define HTTP_STATUS_404_REASON_PHRASE	"Not Found"
+
+/**
+ *
+ * The method specified in the Request-Line is not allowed for the resource
+ * identified by the Request-URI. The response MUST include an Allow header
+ * containing a list of valid methods for the requested resource.
+ *
+ */
 #define HTTP_STATUS_405_REASON_PHRASE	"Method Not Allowed"
+
+/**
+ *
+ * The resource identified by the request is only capable of generating response
+ * entities which have content characteristics not acceptable according to the
+ * accept headers sent in the request.
+ *
+ * Unless it was a HEAD request, the response SHOULD include an entity containing
+ * a list of available entity characteristics and location(s) from which the user
+ * or user agent can choose the one most appropriate. The entity format is
+ * specified by the media type given in the Content-Type header field. Depending
+ * upon the format and the capabilities of the user agent, selection of the most
+ * appropriate choice MAY be performed automatically. However, this specification
+ * does not define any standard for such automatic selection.
+ *
+ * Note: HTTP/1.1 servers are allowed to return responses which are not
+ * acceptable according to the accept headers sent in the request. In some cases,
+ * this may even be preferable to sending a 406 response. User agents are
+ * encouraged to inspect the headers of an incoming response to determine if it
+ * is acceptable.
+ *
+ * If the response could be unacceptable, a user agent SHOULD temporarily stop
+ * receipt of more data and query the user for a decision on further actions.
+ *
+ */
 #define HTTP_STATUS_406_REASON_PHRASE	"Not Acceptable"
+
+/**
+ *
+ * This code is similar to 401 (Unauthorized), but indicates that the client
+ * must first authenticate itself with the proxy. The proxy MUST return a
+ * Proxy-Authenticate header field (RFC 2616 section 14.33) containing a
+ * challenge applicable to the proxy for the requested resource. The client MAY
+ * repeat the request with a suitable Proxy-Authorization header field (RFC 2616
+ * section 14.34). HTTP access authentication is explained in RFC 2617 "HTTP
+ * Authentication: Basic and Digest Access Authentication".
+ *
+ * @see http://www.ietf.org/rfc/rfc2616.txt
+ * @see http://www.ietf.org/rfc/rfc2617.txt
+ *
+ */
 #define HTTP_STATUS_407_REASON_PHRASE	"Proxy Authentication Required"
+
+/**
+ *
+ * The client did not produce a request within the time that the server was
+ * prepared to wait. The client MAY repeat the request without modifications at
+ * any later time.
+ *
+ */
 #define HTTP_STATUS_408_REASON_PHRASE	"Request Time-out"
+
+/**
+ *
+ * The request could not be completed due to a conflict with the current state
+ * of the resource. This code is only allowed in situations where it is expected
+ * that the user might be able to resolve the conflict and resubmit the request.
+ * The response body SHOULD include enough information for the user to recognize
+ * the source of the conflict. Ideally, the response entity would include enough
+ * information for the user or user agent to fix the problem; however, that
+ * might not be possible and is not required.
+ *
+ * Conflicts are most likely to occur in response to a PUT request. For example,
+ * if versioning were being used and the entity being PUT included changes to a
+ * resource which conflict with those made by an earlier (third-party) request,
+ * the server might use the 409 response to indicate that it can't complete the
+ * request. In this case, the response entity would likely contain a list of the
+ * differences between the two versions in a format defined by the response
+ * Content-Type.
+ *
+ */
 #define HTTP_STATUS_409_REASON_PHRASE	"Conflict"
+
+/**
+ *
+ * The requested resource is no longer available at the server and no forwarding
+ * address is known. This condition is expected to be considered permanent.
+ * Clients with link editing capabilities SHOULD delete references to the
+ * Request-URI after user approval. If the server does not know, or has no
+ * facility to determine, whether or not the condition is permanent, the status
+ * code 404 (Not Found) SHOULD be used instead. This response is cacheable unless
+ * indicated otherwise.
+ *
+ * The 410 response is primarily intended to assist the task of web maintenance
+ * by notifying the recipient that the resource is intentionally unavailable and
+ * that the server owners desire that remote links to that resource be removed.
+ * Such an event is common for limited-time, promotional services and for
+ * resources belonging to individuals no longer working at the server's site. It
+ * is not necessary to mark all permanently unavailable resources as "gone" or to
+ * keep the mark for any length of time -- that is left to the discretion of the
+ * server owner.
+ *
+ */
 #define HTTP_STATUS_410_REASON_PHRASE	"Gone"
+
+/**
+ *
+ * The server refuses to accept the request without a defined Content- Length.
+ * The client MAY repeat the request if it adds a valid Content-Length header
+ * field containing the length of the message-body in the request message.
+ *
+ */
 #define HTTP_STATUS_411_REASON_PHRASE	"Length Required"
+
+/**
+ *
+ * The precondition given in one or more of the request-header fields evaluated
+ * to false when it was tested on the server. This response code allows the
+ * client to place preconditions on the current resource metainformation (header
+ * field data) and thus prevent the requested method from being applied to a
+ * resource other than the one intended.
+ *
+ */
 #define HTTP_STATUS_412_REASON_PHRASE	"Precondition Failed"
+
+/**
+ *
+ * The server is refusing to process a request because the request entity is
+ * larger than the server is willing or able to process. The server MAY close
+ * the connection to prevent the client from continuing the request.
+ *
+ * If the condition is temporary, the server SHOULD include a Retry-After header
+ * field to indicate that it is temporary and after what time the client MAY try
+ * again.
+ *
+ */
 #define HTTP_STATUS_413_REASON_PHRASE	"Request Entity Too Large"
+
+/**
+ *
+ * The server is refusing to service the request because the Request-URI is
+ * longer than the server is willing to interpret. This rare condition is only
+ * likely to occur when a client has improperly converted a POST request to a
+ * GET request with long query information, when the client has descended into a
+ * URI "black hole" of redirection (e.g., a redirected URI prefix that points to
+ * a suffix of itself), or when the server is under attack by a client attempting
+ * to exploit security holes present in some servers using fixed-length buffers
+ * for reading or manipulating the Request-URI.
+ *
+ */
 #define HTTP_STATUS_414_REASON_PHRASE	"Request-URI Too Large"
+
+/**
+ *
+ * The server is refusing to service the request because the entity of the
+ * request is in a format not supported by the requested resource for the
+ * requested method.
+ *
+ */
 #define HTTP_STATUS_415_REASON_PHRASE	"Unsupported Media Type"
+
+/**
+ *
+ * A server SHOULD return a response with this status code if a request included
+ * a Range request-header field (RFC 2616 section 14.35), and none of the
+ * range-specifier values in this field overlap the current extent of the
+ * selected resource, and the request did not include an If-Range request-header
+ * field. (For byte-ranges, this means that the first-byte-pos of all of the
+ * byte-range-spec values were greater than the current length of the selected
+ * resource.)
+ *
+ * When this status code is returned for a byte-range request, the response
+ * SHOULD include a Content-Range entity-header field specifying the current
+ * length of the selected resource (see RFC 2616 section 14.16). This response
+ * MUST NOT use the multipart/byteranges content-type.
+ *
+ */
 #define HTTP_STATUS_416_REASON_PHRASE	"Requested range not satisfiable"
+
+/**
+ *
+ * The expectation given in an Expect request-header field (see RFC 2616 section
+ * 14.20) could not be met by this server, or, if the server is a proxy, the
+ * server has unambiguous evidence that the request could not be met by the
+ * next-hop server.
+ *
+ */
 #define HTTP_STATUS_417_REASON_PHRASE	"Expectation Failed"
+
+/**
+ *
+ * The server encountered an unexpected condition which prevented it from
+ * fulfilling the request.
+ *
+ */
 #define HTTP_STATUS_500_REASON_PHRASE	"Internal Server Error"
+
+/**
+ *
+ * The server does not support the functionality required to fulfill the request.
+ * This is the appropriate response when the server does not recognize the
+ * request method and is not capable of supporting it for any resource.
+ *
+ */
 #define HTTP_STATUS_501_REASON_PHRASE	"Not Implemented"
+
+/**
+ *
+ * The server, while acting as a gateway or proxy, received an invalid response
+ * from the upstream server it accessed in attempting to fulfill the request.
+ *
+ */
 #define HTTP_STATUS_502_REASON_PHRASE	"Bad Gateway"
+
+/**
+ *
+ * The server is currently unable to handle the request due to a temporary
+ * overloading or maintenance of the server. The implication is that this is a
+ * temporary condition which will be alleviated after some delay. If known, the
+ * length of the delay MAY be indicated in a Retry-After header. If no
+ * Retry-After is given, the client SHOULD handle the response as it would for a
+ * 500 response.
+ *
+ * Note: The existence of the 503 status code does not imply that a server must
+ * use it when becoming overloaded. Some servers may wish to simply refuse the
+ * connection.
+ *
+ */
 #define HTTP_STATUS_503_REASON_PHRASE	"Service Unavailable"
+
+/**
+ *
+ * The server, while acting as a gateway or proxy, did not receive a timely
+ * response from the upstream server specified by the URI (e.g. HTTP, FTP, LDAP)
+ * or some other auxiliary server (e.g. DNS) it needed to access in attempting
+ * to complete the request.
+ *
+ * Note: Note to implementors: some deployed proxies are known to return 400 or
+ * 500 when DNS lookups time out.
+ *
+ */
 #define HTTP_STATUS_504_REASON_PHRASE	"Gateway Time-out"
+
+/**
+ *
+ * The server does not support, or refuses to support, the HTTP protocol version
+ * that was used in the request message. The server is indicating that it is
+ * unable or unwilling to complete the request using the same major version as
+ * the client, as described in RFC 2616 section 3.1, other than with this error
+ * message. The response SHOULD contain an entity describing why that version is
+ * not supported and what other protocols are supported by that server.
+ *
+ */
 #define HTTP_STATUS_505_REASON_PHRASE	"HTTP Version not supported"
 
+/*}*/
+
 /**
  *
  * part. Attachment