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.

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

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











 
RFC 2068                        HTTP/1.1                    January 1997


   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 headers 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.

          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 RFC 1522
   [14].

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

   Hexadecimal numeric characters are used in several protocol elements.

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

   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.

          token          = 1*<any CHAR except CTLs or tspecials>

          tspecials      = "(" | ")" | "<" | ">" | "@"
                         | "," | ";" | ":" | "\" | <">
                         | "/" | "[" | "]" | "?" | "="
                         | "{" | "}" | 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 | comment ) ")"
          ctext          = <any TEXT excluding "(" and ")">






 
RFC 2068                        HTTP/1.1                    January 1997