Connected: An Internet Encyclopedia
RFC 1945 - 2.2 Basic Rules

Top: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 1945
Up: 2. Notational Conventions and Generic Grammar
Prev: 2.1 Augmented BNF
Next: 3. Protocol Parameters

### 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">
           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- ASCII character set may assume that they represent ISO-8859-1 characters.

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

           word           = token | quoted-string

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

           tspecials      = "(" | ")" | "<" | ">" | "@"
                          | "," | ";" | ":" | "\" | <">
                          | "/" | "[" | "]" | "?" | "="
                          | "{" | "}" | SP | HT

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

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

           quoted-string  = ( <"> *(qdtext) <"> )

           qdtext         = <any CHAR except <"> and CTLs,
                            but including LWS>

Single-character quoting using the backslash ("\") character is not permitted in HTTP/1.0.

Next: 3. Protocol Parameters

Connected: An Internet Encyclopedia
RFC 1945 - 2.2 Basic Rules