string of three alphabetic characters.





 
RFC 1945                        HTTP/1.0                        May 1996


   #rule

       A construct "#" is defined, similar to "*", for defining lists
       of elements. The full form is "#element" indicating at
       least  and at most  elements, each separated by one or
       more commas (",") and optional linear whitespace (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 whitespace (LWS) can be
       included between any two adjacent words (token or
       quoted-string), and between adjacent tokens and delimiters
       (tspecials), without changing the interpretation of a field. At
       least one delimiter (tspecials) must exist between any two
       tokens, since they would otherwise be interpreted as a single
       token. However, applications should attempt to follow "common
       form" when generating HTTP constructs, since there exist some
       implementations that fail to accept anything beyond the common
       forms.

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 [17].

       OCTET          = <any 8-bit sequence of data>
       CHAR           = <any US-ASCII character (octets 0 - 127)>
       UPALPHA        = <any US-ASCII uppercase letter "A".."Z">
       LOALPHA        = <any US-ASCII lowercase letter "a".."z">




 
RFC 1945                        HTTP/1.0                        May 1996


       ALPHA          = UPALPHA | LOALPHA
       DIGIT          = <any US-ASCII digit "0".."9">
       CTL            = <any US-ASCII control character
                        (octets 0 - 31) and DEL (127)>
       CR             = <US-ASCII CR, carriage return (13)>
       LF             = <US-ASCII LF, linefeed (10)>
       SP             = <US-ASCII SP, space (32)>
       HT             = <US-ASCII HT, horizontal-tab (9)>
       <">            = <US-ASCII double-quote mark (34)>

   HTTP/1.0 defines the octet sequence CR LF as the end-of-line marker
   for all protocol elements except the Entity-Body (see Appendix B for
   tolerant applications). The end-of-line marker within an Entity-Body
   is defined by its associated media type, as described in Section 3.6.

       CRLF           = CR LF

   HTTP/1.0 headers may be folded onto multiple lines if each
   continuation line begins with a space or horizontal tab. All linear
   whitespace, including folding, has the same semantics as SP.

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

   However, folding of header lines is not expected by some
   applications, and should not be generated by HTTP/1.0 applications.

   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 octets from character sets other than US-ASCII.

       TEXT           = <any OCTET except CTLs,
                        but including LWS>

   Recipients of header field TEXT containing octets outside the US-