rfc2616.html

this gives details of the network programming

      foo elem" and "elem bar elem".

   *rule
      The character "*" preceding an element indicates repetition. The
      full form is "<n>*<m>element" indicating at least <n> and at most
      <m> occurrences of element. Default values are 0 and infinity so
      that "*(element)" allows any number, including zero; "1*element"
      requires at least one; and "1*2element" allows one or two.

   [rule]
      Square brackets enclose optional elements; "[foo bar]" is
      equivalent to "*1(foo bar)".



Fielding, et al.            Standards Track                    [Page 14]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   N rule
      Specific repetition: "&lt;n&gt;(element)" is equivalent to
      "&lt;n&gt;*&lt;n&gt;(element)"; that is, exactly &lt;n&gt; occurrences of (element).
      Thus 2DIGIT is a 2-digit number, and 3ALPHA is a string of three
      alphabetic characters.

   #rule
      A construct "#" is defined, similar to "*", for defining lists of
      elements. The full form is "&lt;n&gt;#&lt;m&gt;element" indicating at least
      &lt;n&gt; and at most &lt;m&gt; elements, each separated by one or more commas
      (",") and OPTIONAL linear white space (LWS). This makes the usual
      form of lists very easy; a rule such as
         ( *LWS element *( *LWS "," *LWS element ))
      can be shown as
         1#element
      Wherever this construct is used, null elements are allowed, but do
      not contribute to the count of elements present. That is,
      "(element), , (element) " is permitted, but counts as only two
      elements. Therefore, where at least one element is required, at
      least one non-null element MUST be present. Default values are 0
      and infinity so that "#element" allows any number, including zero;
      "1#element" requires at least one; and "1#2element" allows one or
      two.

   ; comment
      A semi-colon, set off some distance to the right of rule text,
      starts a comment that continues to the end of line. This is a
      simple way of including useful notes in parallel with the
      specifications.

   implied *LWS
      The grammar described by this specification is word-based. Except
      where noted otherwise, linear white space (LWS) can be included
      between any two adjacent words (token or quoted-string), and
      between adjacent words and separators, without changing the
      interpretation of a field. At least one delimiter (LWS and/or

      separators) MUST exist between any two tokens (for the definition
      of "token" below), since they would otherwise be interpreted as a
      single token.

2.2 Basic Rules

   The following rules are used throughout this specification to
   describe basic parsing constructs. The US-ASCII coded character set
   is defined by ANSI X3.4-1986 [21].





Fielding, et al.            Standards Track                    [Page 15]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


       OCTET          = &lt;any 8-bit sequence of data&gt;
       CHAR           = &lt;any US-ASCII character (octets 0 - 127)&gt;
       UPALPHA        = &lt;any US-ASCII uppercase letter "A".."Z"&gt;
       LOALPHA        = &lt;any US-ASCII lowercase letter "a".."z"&gt;
       ALPHA          = UPALPHA | LOALPHA
       DIGIT          = &lt;any US-ASCII digit "0".."9"&gt;
       CTL            = &lt;any US-ASCII control character
                        (octets 0 - 31) and DEL (127)&gt;
       CR             = &lt;US-ASCII CR, carriage return (13)&gt;
       LF             = &lt;US-ASCII LF, linefeed (10)&gt;
       SP             = &lt;US-ASCII SP, space (32)&gt;
       HT             = &lt;US-ASCII HT, horizontal-tab (9)&gt;
       &lt;"&gt;            = &lt;US-ASCII double-quote mark (34)&gt;

   HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all
   protocol elements except the entity-body (see appendix 19.3 for
   tolerant applications). The end-of-line marker within an entity-body
   is defined by its associated media type, as described in section 3.7.

       CRLF           = CR LF

   HTTP/1.1 header field values can be folded onto multiple lines if the
   continuation line begins with a space or horizontal tab. All linear
   white space, including folding, has the same semantics as SP. A
   recipient MAY replace any linear white space with a single SP before
   interpreting the field value or forwarding the message downstream.

       LWS            = [CRLF] 1*( SP | HT )

   The TEXT rule is only used for descriptive field contents and values
   that are not intended to be interpreted by the message parser. Words
   of *TEXT MAY contain characters from character sets other than ISO-
   8859-1 [22] only when encoded according to the rules of <A href="../../../../rfc.net/rfc2047.html">RFC 2047</A>
   [14].

       TEXT           = &lt;any OCTET except CTLs,
                        but including LWS&gt;

   A CRLF is allowed in the definition of TEXT only as part of a header
   field continuation. It is expected that the folding LWS will be
   replaced with a single SP before interpretation of the TEXT value.

   Hexadecimal numeric characters are used in several protocol elements.

       HEX            = "A" | "B" | "C" | "D" | "E" | "F"
                      | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT





Fielding, et al.            Standards Track                    [Page 16]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   Many HTTP/1.1 header field values consist of words separated by LWS
   or special characters. These special characters MUST be in a quoted
   string to be used within a parameter value (as defined in section
   3.6).

       token          = 1*&lt;any CHAR except CTLs or separators&gt;
       separators     = "(" | ")" | "&lt;" | "&gt;" | "@"
                      | "," | ";" | ":" | "\" | &lt;"&gt;
                      | "/" | "[" | "]" | "?" | "="
                      | "{" | "}" | SP | HT

   Comments can be included in some HTTP header fields by surrounding
   the comment text with parentheses. Comments are only allowed in
   fields containing "comment" as part of their field value definition.
   In all other fields, parentheses are considered part of the field
   value.

       comment        = "(" *( ctext | quoted-pair | comment ) ")"
       ctext          = &lt;any TEXT excluding "(" and ")"&gt;

   A string of text is parsed as a single word if it is quoted using
   double-quote marks.

       quoted-string  = ( &lt;"&gt; *(qdtext | quoted-pair ) &lt;"&gt; )
       qdtext         = &lt;any TEXT except &lt;"&gt;&gt;

   The backslash character ("\") MAY be used as a single-character
   quoting mechanism only within quoted-string and comment constructs.

       quoted-pair    = "\" CHAR

3 Protocol Parameters

3.1 HTTP Version

   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
   of the protocol. The protocol versioning policy is intended to allow
   the sender to indicate the format of a message and its capacity for
   understanding further HTTP communication, rather than the features
   obtained via that communication. No change is made to the version
   number for the addition of message components which do not affect
   communication behavior or which only add to extensible field values.
   The &lt;minor&gt; number is incremented when the changes made to the
   protocol add features which do not change the general message parsing
   algorithm, but which may add to the message semantics and imply
   additional capabilities of the sender. The &lt;major&gt; number is
   incremented when the format of a message within the protocol is
   changed. See <A href="../../../../rfc.net/rfc2145.html">RFC 2145</A> [36] for a fuller explanation.



Fielding, et al.            Standards Track                    [Page 17]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


   The version of an HTTP message is indicated by an HTTP-Version field
   in the first line of the message.

       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT

   Note that the major and minor numbers MUST be treated as separate
   integers and that each MAY be incremented higher than a single digit.
   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
   lower than HTTP/12.3. Leading zeros MUST be ignored by recipients and
   MUST NOT be sent.

   An application that sends a request or response message that includes
   HTTP-Version of "HTTP/1.1" MUST be at least conditionally compliant
   with this specification. Applications that are at least conditionally
   compliant with this specification SHOULD use an HTTP-Version of
   "HTTP/1.1" in their messages, and MUST do so for any message that is
   not compatible with HTTP/1.0. For more details on when to send
   specific HTTP-Version values, see <A href="../../../../rfc.net/rfc2145.html">RFC 2145</A> [36].

   The HTTP version of an application is the highest HTTP version for
   which the application is at least conditionally compliant.

   Proxy and gateway applications need to be careful when forwarding
   messages in protocol versions different from that of the application.
   Since the protocol version indicates the protocol capability of the
   sender, a proxy/gateway MUST NOT send a message with a version
   indicator which is greater than its actual version. If a higher
   version request is received, the proxy/gateway MUST either downgrade
   the request version, or respond with an error, or switch to tunnel
   behavior.

   Due to interoperability problems with HTTP/1.0 proxies discovered
   since the publication of <A href="../../../../rfc.net/rfc2068.html">RFC 2068</A>[33], caching proxies MUST, gateways
   MAY, and tunnels MUST NOT upgrade the request to the highest version
   they support. The proxy/gateway's response to that request MUST be in
   the same major version as the request.

      Note: Converting between versions of HTTP may involve modification
      of header fields required or forbidden by the versions involved.

3.2 Uniform Resource Identifiers

   URIs have been known by many names: WWW addresses, Universal Document
   Identifiers, Universal Resource Identifiers [3], and finally the
   combination of Uniform Resource Locators (URL) [4] and Names (URN)
   [20]. As far as HTTP is concerned, Uniform Resource Identifiers are
   simply formatted strings which identify--via name, location, or any
   other characteristic--a resource.



Fielding, et al.            Standards Track                    [Page 18]
<HR>
<A href="rfc2616.html">RFC 2616</A>                        HTTP/1.1                       June 1999


3.2.1 General Syntax

   URIs in HTTP can be represented in absolute form or relative to some
   known base URI [11], depending upon the context of their use. The two
   forms are differentiated by the fact that absolute URIs always begin
   with a scheme name followed by a colon. For definitive information on
   URL syntax and semantics, see "Uniform Resource Identifiers (URI):
   Generic Syntax and Semantics," <A href="../../../../rfc.net/rfc2396.html">RFC 2396</A> [42] (which replaces RFCs
   1738 [4] and <A href="../../../../rfc.net/rfc1808.html">RFC 1808</A> [11]). This specification adopts the
   definitions of "URI-reference", "absoluteURI", "relativeURI", "port",
   "host","abs_path", "rel_path", and "authority" from that
   specification.

   The HTTP protocol does not place any a priori limit on the length of
   a URI. Servers MUST be able to handle the URI of any resource they
   serve, and SHOULD be able to handle URIs of unbounded length if they
   provide GET-based forms that could generate such URIs. A server