Ignore:
Timestamp:
Jan 1, 2008, 9:15:17 AM (12 years ago)
Author:
julian.reschke@…
Message:

Consistent indentation for all ABNF rules (addresses #36)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p1-messaging.html

    r134 r135  
    917917         set is defined by ANSI X3.4-1986 <a href="#USASCII" id="rfc.xref.USASCII.1"><cite title="Coded Character Set -- 7-bit American Standard Code for Information Interchange">[USASCII]</cite></a>.
    918918      </p>
    919       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>    OCTET          = &lt;any 8-bit sequence of data&gt;
    920     CHAR           = &lt;any US-ASCII character (octets 0 - 127)&gt;
    921     UPALPHA        = &lt;any US-ASCII uppercase letter "A".."Z"&gt;
    922     LOALPHA        = &lt;any US-ASCII lowercase letter "a".."z"&gt;
    923     ALPHA          = UPALPHA | LOALPHA
    924     DIGIT          = &lt;any US-ASCII digit "0".."9"&gt;
    925     CTL            = &lt;any US-ASCII control character
    926                      (octets 0 - 31) and DEL (127)&gt;
    927     CR             = &lt;US-ASCII CR, carriage return (13)&gt;
    928     LF             = &lt;US-ASCII LF, linefeed (10)&gt;
    929     SP             = &lt;US-ASCII SP, space (32)&gt;
    930     HT             = &lt;US-ASCII HT, horizontal-tab (9)&gt;
    931     &lt;"&gt;            = &lt;US-ASCII double-quote mark (34)&gt;
     919      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span><span id="rfc.iref.g.9"></span><span id="rfc.iref.g.10"></span><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span>  OCTET          = &lt;any 8-bit sequence of data&gt;
     920  CHAR           = &lt;any US-ASCII character (octets 0 - 127)&gt;
     921  UPALPHA        = &lt;any US-ASCII uppercase letter "A".."Z"&gt;
     922  LOALPHA        = &lt;any US-ASCII lowercase letter "a".."z"&gt;
     923  ALPHA          = UPALPHA | LOALPHA
     924  DIGIT          = &lt;any US-ASCII digit "0".."9"&gt;
     925  CTL            = &lt;any US-ASCII control character
     926                   (octets 0 - 31) and DEL (127)&gt;
     927  CR             = &lt;US-ASCII CR, carriage return (13)&gt;
     928  LF             = &lt;US-ASCII LF, linefeed (10)&gt;
     929  SP             = &lt;US-ASCII SP, space (32)&gt;
     930  HT             = &lt;US-ASCII HT, horizontal-tab (9)&gt;
     931  &lt;"&gt;            = &lt;US-ASCII double-quote mark (34)&gt;
    932932</pre><p id="rfc.section.2.2.p.3">HTTP/1.1 defines the sequence CR LF as the end-of-line marker for all protocol elements except the entity-body (see <a href="#tolerant.applications" title="Tolerant Applications">Appendix&nbsp;B</a> for tolerant applications). The end-of-line marker within an entity-body is defined by its associated media type, as described
    933933         in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    934934      </p>
    935       <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.13"></span>    CRLF           = CR LF
     935      <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.13"></span>  CRLF           = CR LF
    936936</pre><p id="rfc.section.2.2.p.5">HTTP/1.1 header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal
    937937         tab. All linear white space, including folding, has the same semantics as SP. A recipient <em class="bcp14">MAY</em> replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream.
    938938      </p>
    939       <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span>    LWS            = [CRLF] 1*( SP | HT )
     939      <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.14"></span>  LWS            = [CRLF] 1*( SP | HT )
    940940</pre><p id="rfc.section.2.2.p.7">The TEXT rule is only used for descriptive field contents and values that are not intended to be interpreted by the message
    941941         parser. Words of *TEXT <em class="bcp14">MAY</em> contain characters from character sets other than ISO-8859-1 <a href="#ISO-8859-1" id="rfc.xref.ISO-8859-1.1"><cite title="Information technology -- 8-bit single-byte coded graphic character sets -- Part 1: Latin alphabet No. 1">[ISO-8859-1]</cite></a> only when encoded according to the rules of <a href="#RFC2047" id="rfc.xref.RFC2047.1"><cite title="MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text">[RFC2047]</cite></a>.
    942942      </p>
    943       <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span>    TEXT           = &lt;any OCTET except CTLs,
    944                      but including LWS&gt;
     943      <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.15"></span>  TEXT           = &lt;any OCTET except CTLs,
     944                   but including LWS&gt;
    945945</pre><p id="rfc.section.2.2.p.9">A CRLF is allowed in the definition of TEXT only as part of a header field continuation. It is expected that the folding LWS
    946946         will be replaced with a single SP before interpretation of the TEXT value.
    947947      </p>
    948948      <p id="rfc.section.2.2.p.10">Hexadecimal numeric characters are used in several protocol elements.</p>
    949       <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    HEX            = "A" | "B" | "C" | "D" | "E" | "F"
    950                    | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
     949      <div id="rfc.figure.u.8"></div><pre class="inline"><span id="rfc.iref.g.16"></span>  HEX            = "A" | "B" | "C" | "D" | "E" | "F"
     950                 | "a" | "b" | "c" | "d" | "e" | "f" | DIGIT
    951951</pre><p id="rfc.section.2.2.p.12">Many HTTP/1.1 header field values consist of words separated by LWS or special characters. These special characters <em class="bcp14">MUST</em> be in a quoted string to be used within a parameter value (as defined in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>).
    952952      </p>
    953       <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>    token          = 1*&lt;any CHAR except CTLs or separators&gt;
    954     separators     = "(" | ")" | "&lt;" | "&gt;" | "@"
    955                    | "," | ";" | ":" | "\" | &lt;"&gt;
    956                    | "/" | "[" | "]" | "?" | "="
    957                    | "{" | "}" | SP | HT
     953      <div id="rfc.figure.u.9"></div><pre class="inline"><span id="rfc.iref.g.17"></span><span id="rfc.iref.g.18"></span>  token          = 1*&lt;any CHAR except CTLs or separators&gt;
     954  separators     = "(" | ")" | "&lt;" | "&gt;" | "@"
     955                 | "," | ";" | ":" | "\" | &lt;"&gt;
     956                 | "/" | "[" | "]" | "?" | "="
     957                 | "{" | "}" | SP | HT
    958958</pre><p id="rfc.section.2.2.p.14">Comments can be included in some HTTP header fields by surrounding the comment text with parentheses. Comments are only allowed
    959959         in fields containing "comment" as part of their field value definition. In all other fields, parentheses are considered part
    960960         of the field value.
    961961      </p>
    962       <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>    comment        = "(" *( ctext | quoted-pair | comment ) ")"
    963     ctext          = &lt;any TEXT excluding "(" and ")"&gt;
     962      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.19"></span><span id="rfc.iref.g.20"></span>  comment        = "(" *( ctext | quoted-pair | comment ) ")"
     963  ctext          = &lt;any TEXT excluding "(" and ")"&gt;
    964964</pre><p id="rfc.section.2.2.p.16">A string of text is parsed as a single word if it is quoted using double-quote marks.</p>
    965       <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>    quoted-string  = ( &lt;"&gt; *(qdtext | quoted-pair ) &lt;"&gt; )
    966     qdtext         = &lt;any TEXT excluding &lt;"&gt; and "\"&gt;
     965      <div id="rfc.figure.u.11"></div><pre class="inline"><span id="rfc.iref.g.21"></span><span id="rfc.iref.g.22"></span>  quoted-string  = ( &lt;"&gt; *(qdtext | quoted-pair ) &lt;"&gt; )
     966  qdtext         = &lt;any TEXT excluding &lt;"&gt; and "\"&gt;
    967967</pre><p id="rfc.section.2.2.p.18">The backslash character ("\") <em class="bcp14">MAY</em> be used as a single-character quoting mechanism only within quoted-string and comment constructs.
    968968      </p>
    969       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.23"></span>    quoted-pair    = "\" CHAR
     969      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.23"></span>  quoted-pair    = "\" CHAR
    970970</pre><h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="protocol.parameters" href="#protocol.parameters">Protocol Parameters</a></h1>
    971971      <h2 id="rfc.section.3.1"><a href="#rfc.section.3.1">3.1</a>&nbsp;<a id="http.version" href="#http.version">HTTP Version</a></h2>
     
    979979      </p>
    980980      <p id="rfc.section.3.1.p.2">The version of an HTTP message is indicated by an HTTP-Version field in the first line of the message. HTTP-Version is case-sensitive.</p>
    981       <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span>       HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
     981      <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.24"></span>  HTTP-Version   = "HTTP" "/" 1*DIGIT "." 1*DIGIT
    982982</pre><p id="rfc.section.3.1.p.4">Note that the major and minor numbers <em class="bcp14">MUST</em> be treated as separate integers and that each <em class="bcp14">MAY</em> 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.
    983983         Leading zeros <em class="bcp14">MUST</em> be ignored by recipients and <em class="bcp14">MUST NOT</em> be sent.
     
    10211021         and semantics for http URLs.
    10221022      </p>
    1023       <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
     1023      <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.25"></span>  http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]]
    10241024</pre><p id="rfc.section.3.2.2.p.3">If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server
    10251025         listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). The use of IP addresses in URLs <em class="bcp14">SHOULD</em> be avoided whenever possible (see <a href="#RFC1900" id="rfc.xref.RFC1900.1"><cite title="Renumbering Needs Work">[RFC1900]</cite></a>). If the abs_path is not present in the URL, it <em class="bcp14">MUST</em> be given as "/" when used as a Request-URI for a resource (<a href="#request-uri" title="Request-URI">Section&nbsp;5.1.2</a>). If a proxy receives a host name which is not a fully qualified domain name, it <em class="bcp14">MAY</em> add its domain to the host name it received. If a proxy receives a fully qualified domain name, the proxy <em class="bcp14">MUST NOT</em> change the host name.
     
    10601060         time zone, and <em class="bcp14">MUST</em> be assumed when reading the asctime format. HTTP-date is case sensitive and <em class="bcp14">MUST NOT</em> include additional LWS beyond that specifically included as SP in the grammar.
    10611061      </p>
    1062       <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>    HTTP-date    = rfc1123-date | rfc850-date | asctime-date
    1063     rfc1123-date = wkday "," SP date1 SP time SP "GMT"
    1064     rfc850-date  = weekday "," SP date2 SP time SP "GMT"
    1065     asctime-date = wkday SP date3 SP time SP 4DIGIT
    1066     date1        = 2DIGIT SP month SP 4DIGIT
    1067                    ; day month year (e.g., 02 Jun 1982)
    1068     date2        = 2DIGIT "-" month "-" 2DIGIT
    1069                    ; day-month-year (e.g., 02-Jun-82)
    1070     date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
    1071                    ; month day (e.g., Jun  2)
    1072     time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
    1073                    ; 00:00:00 - 23:59:59
    1074     wkday        = "Mon" | "Tue" | "Wed"
    1075                  | "Thu" | "Fri" | "Sat" | "Sun"
    1076     weekday      = "Monday" | "Tuesday" | "Wednesday"
    1077                  | "Thursday" | "Friday" | "Saturday" | "Sunday"
    1078     month        = "Jan" | "Feb" | "Mar" | "Apr"
    1079                  | "May" | "Jun" | "Jul" | "Aug"
    1080                  | "Sep" | "Oct" | "Nov" | "Dec"
     1062      <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.26"></span><span id="rfc.iref.g.27"></span><span id="rfc.iref.g.28"></span><span id="rfc.iref.g.29"></span><span id="rfc.iref.g.30"></span><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span><span id="rfc.iref.g.33"></span><span id="rfc.iref.g.34"></span><span id="rfc.iref.g.35"></span><span id="rfc.iref.g.36"></span>  HTTP-date    = rfc1123-date | rfc850-date | asctime-date
     1063  rfc1123-date = wkday "," SP date1 SP time SP "GMT"
     1064  rfc850-date  = weekday "," SP date2 SP time SP "GMT"
     1065  asctime-date = wkday SP date3 SP time SP 4DIGIT
     1066  date1        = 2DIGIT SP month SP 4DIGIT
     1067                 ; day month year (e.g., 02 Jun 1982)
     1068  date2        = 2DIGIT "-" month "-" 2DIGIT
     1069                 ; day-month-year (e.g., 02-Jun-82)
     1070  date3        = month SP ( 2DIGIT | ( SP 1DIGIT ))
     1071                 ; month day (e.g., Jun  2)
     1072  time         = 2DIGIT ":" 2DIGIT ":" 2DIGIT
     1073                 ; 00:00:00 - 23:59:59
     1074  wkday        = "Mon" | "Tue" | "Wed"
     1075               | "Thu" | "Fri" | "Sat" | "Sun"
     1076  weekday      = "Monday" | "Tuesday" | "Wednesday"
     1077               | "Thursday" | "Friday" | "Saturday" | "Sunday"
     1078  month        = "Jan" | "Feb" | "Mar" | "Apr"
     1079               | "May" | "Jun" | "Jul" | "Aug"
     1080               | "Sep" | "Oct" | "Nov" | "Dec"
    10811081</pre><p id="rfc.section.3.3.1.p.7"> <b>Note:</b> HTTP requirements for the date/time stamp format apply only to their usage within the protocol stream. Clients and servers
    10821082         are not required to use these formats for user presentation, request logging, etc.
     
    10871087         is a property of the message, not of the original entity.
    10881088      </p>
    1089       <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>    transfer-coding         = "chunked" | transfer-extension
    1090     transfer-extension      = token *( ";" parameter )
     1089      <div id="rfc.figure.u.18"></div><pre class="inline"><span id="rfc.iref.g.37"></span><span id="rfc.iref.g.38"></span>  transfer-coding         = "chunked" | transfer-extension
     1090  transfer-extension      = token *( ";" parameter )
    10911091</pre><p id="rfc.section.3.4.p.3">Parameters are in the form of attribute/value pairs.</p>
    1092       <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span>    parameter               = attribute "=" value
    1093     attribute               = token
    1094     value                   = token | quoted-string
     1092      <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.39"></span><span id="rfc.iref.g.40"></span><span id="rfc.iref.g.41"></span>  parameter               = attribute "=" value
     1093  attribute               = token
     1094  value                   = token | quoted-string
    10951095</pre><p id="rfc.section.3.4.p.5">All transfer-coding values are case-insensitive. HTTP/1.1 uses transfer-coding values in the TE header field (<a href="#header.te" id="rfc.xref.header.te.1" title="TE">Section&nbsp;8.5</a>) and in the Transfer-Encoding header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.1" title="Transfer-Encoding">Section&nbsp;8.7</a>).
    10961096      </p>
     
    11151115         necessary for the recipient to verify that it has received the full message.
    11161116      </p>
    1117       <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span>    Chunked-Body   = *chunk
    1118                      last-chunk
    1119                      trailer
    1120                      CRLF
    1121 
    1122     chunk          = chunk-size [ chunk-extension ] CRLF
    1123                      chunk-data CRLF
    1124     chunk-size     = 1*HEX
    1125     last-chunk     = 1*("0") [ chunk-extension ] CRLF
    1126 
    1127     chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
    1128     chunk-ext-name = token
    1129     chunk-ext-val  = token | quoted-string
    1130     chunk-data     = chunk-size(OCTET)
    1131     trailer        = *(entity-header CRLF)
     1117      <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.42"></span><span id="rfc.iref.g.43"></span><span id="rfc.iref.g.44"></span><span id="rfc.iref.g.45"></span><span id="rfc.iref.g.46"></span><span id="rfc.iref.g.47"></span><span id="rfc.iref.g.48"></span><span id="rfc.iref.g.49"></span><span id="rfc.iref.g.50"></span>  Chunked-Body   = *chunk
     1118                   last-chunk
     1119                   trailer
     1120                   CRLF
     1121 
     1122  chunk          = chunk-size [ chunk-extension ] CRLF
     1123                   chunk-data CRLF
     1124  chunk-size     = 1*HEX
     1125  last-chunk     = 1*("0") [ chunk-extension ] CRLF
     1126 
     1127  chunk-extension= *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
     1128  chunk-ext-name = token
     1129  chunk-ext-val  = token | quoted-string
     1130  chunk-data     = chunk-size(OCTET)
     1131  trailer        = *(entity-header CRLF)
    11321132</pre><p id="rfc.section.3.4.1.p.3">The chunk-size field is a string of hex digits indicating the size of the chunk-data in octets. The chunked encoding is ended
    11331133         by any chunk whose size is zero, followed by the trailer, which is terminated by an empty line.
     
    11721172      <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a>&nbsp;<a id="message.types" href="#message.types">Message Types</a></h2>
    11731173      <p id="rfc.section.4.1.p.1">HTTP messages consist of requests from client to server and responses from server to client.</p>
    1174       <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span>    HTTP-message   = Request | Response     ; HTTP/1.1 messages
     1174      <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.51"></span>  HTTP-message   = Request | Response     ; HTTP/1.1 messages
    11751175</pre><p id="rfc.section.4.1.p.3">Request (<a href="#request" title="Request">Section&nbsp;5</a>) and Response (<a href="#response" title="Response">Section&nbsp;6</a>) messages use the generic message format of <a href="#RFC2822" id="rfc.xref.RFC2822.2"><cite title="Internet Message Format">[RFC2822]</cite></a> for transferring entities (the payload of the message). Both types of message consist of a start-line, zero or more header
    11761176         fields (also known as "headers"), an empty line (i.e., a line with nothing preceding the CRLF) indicating the end of the header
    11771177         fields, and possibly a message-body.
    11781178      </p>
    1179       <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>     generic-message = start-line
    1180                        *(message-header CRLF)
    1181                        CRLF
    1182                        [ message-body ]
    1183      start-line      = Request-Line | Status-Line
     1179      <div id="rfc.figure.u.23"></div><pre class="inline"><span id="rfc.iref.g.52"></span><span id="rfc.iref.g.53"></span>  generic-message = start-line
     1180                    *(message-header CRLF)
     1181                    CRLF
     1182                    [ message-body ]
     1183  start-line      = Request-Line | Status-Line
    11841184</pre><p id="rfc.section.4.1.p.5">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore any empty line(s) received where a Request-Line is expected. In other words, if the server is reading the protocol
    11851185         stream at the beginning of a message and receives a CRLF first, it should ignore the CRLF.
     
    11941194         generating HTTP constructs, since there might exist some implementations that fail to accept anything beyond the common forms.
    11951195      </p>
    1196       <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>    message-header = field-name ":" [ field-value ]
    1197     field-name     = token
    1198     field-value    = *( field-content | LWS )
    1199     field-content  = &lt;the OCTETs making up the field-value
    1200                      and consisting of either *TEXT or combinations
    1201                      of token, separators, and quoted-string&gt;
     1196      <div id="rfc.figure.u.24"></div><pre class="inline"><span id="rfc.iref.g.54"></span><span id="rfc.iref.g.55"></span><span id="rfc.iref.g.56"></span><span id="rfc.iref.g.57"></span>  message-header = field-name ":" [ field-value ]
     1197  field-name     = token
     1198  field-value    = *( field-content | LWS )
     1199  field-content  = &lt;the OCTETs making up the field-value
     1200                   and consisting of either *TEXT or combinations
     1201                   of token, separators, and quoted-string&gt;
    12021202</pre><p id="rfc.section.4.2.p.3">The field-content does not include any leading or trailing LWS: linear white space occurring before the first non-whitespace
    12031203         character of the field-value or after the last non-whitespace character of the field-value. Such leading or trailing LWS <em class="bcp14">MAY</em> be removed without changing the semantics of the field value. Any LWS that occurs between field-content <em class="bcp14">MAY</em> be replaced with a single SP before interpreting the field value or forwarding the message downstream.
     
    12181218         header field (<a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.2" title="Transfer-Encoding">Section&nbsp;8.7</a>).
    12191219      </p>
    1220       <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.58"></span>    message-body = entity-body
    1221                  | &lt;entity-body encoded as per Transfer-Encoding&gt;
     1220      <div id="rfc.figure.u.25"></div><pre class="inline"><span id="rfc.iref.g.58"></span>  message-body = entity-body
     1221               | &lt;entity-body encoded as per Transfer-Encoding&gt;
    12221222</pre><p id="rfc.section.4.3.p.3">Transfer-Encoding <em class="bcp14">MUST</em> be used to indicate any transfer-codings applied by an application to ensure safe and proper transfer of the message. Transfer-Encoding
    12231223         is a property of the message, not of the entity, and thus <em class="bcp14">MAY</em> be added or removed by any application along the request/response chain. (However, <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a> places restrictions on when certain transfer-codings may be used.)
     
    12841284         to the entity being transferred. These header fields apply only to the message being transmitted.
    12851285      </p>
    1286       <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span>    general-header = Cache-Control            ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
    1287                    | Connection               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
    1288                    | Date                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
    1289                    | Pragma                   ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>
    1290                    | Trailer                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a>
    1291                    | Transfer-Encoding        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
    1292                    | Upgrade                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a>
    1293                    | Via                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>
    1294                    | Warning                  ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
     1286      <div id="rfc.figure.u.26"></div><pre class="inline"><span id="rfc.iref.g.59"></span>  general-header = Cache-Control            ; <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.cache-control" title="Cache-Control">Section 3.2</a>
     1287                 | Connection               ; <a href="#header.connection" id="rfc.xref.header.connection.1" title="Connection">Section&nbsp;8.1</a>
     1288                 | Date                     ; <a href="#header.date" id="rfc.xref.header.date.1" title="Date">Section&nbsp;8.3</a>
     1289                 | Pragma                   ; <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.pragma" title="Pragma">Section 3.4</a>
     1290                 | Trailer                  ; <a href="#header.trailer" id="rfc.xref.header.trailer.2" title="Trailer">Section&nbsp;8.6</a>
     1291                 | Transfer-Encoding        ; <a href="#header.transfer-encoding" id="rfc.xref.header.transfer-encoding.4" title="Transfer-Encoding">Section&nbsp;8.7</a>
     1292                 | Upgrade                  ; <a href="#header.upgrade" id="rfc.xref.header.upgrade.1" title="Upgrade">Section&nbsp;8.8</a>
     1293                 | Via                      ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section&nbsp;8.9</a>
     1294                 | Warning                  ; <a href="#Part6" id="rfc.xref.Part6.5"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a>
    12951295</pre><p id="rfc.section.4.5.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new
    12961296         or experimental header fields may be given the semantics of general header fields if all parties in the communication recognize
     
    13011301         resource, the identifier of the resource, and the protocol version in use.
    13021302      </p>
    1303       <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.60"></span>     Request       = Request-Line              ; <a href="#request-line" title="Request-Line">Section&nbsp;5.1</a>
    1304                      *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1305                       | request-header         ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>
    1306                       | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    1307                      CRLF
    1308                      [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     1303      <div id="rfc.figure.u.27"></div><pre class="inline"><span id="rfc.iref.g.60"></span>  Request       = Request-Line              ; <a href="#request-line" title="Request-Line">Section&nbsp;5.1</a>
     1304                  *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
     1305                   | request-header         ; <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 4</a>
     1306                   | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1307                  CRLF
     1308                  [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
    13091309</pre><h2 id="rfc.section.5.1"><a href="#rfc.section.5.1">5.1</a>&nbsp;<a id="request-line" href="#request-line">Request-Line</a></h2>
    13101310      <p id="rfc.section.5.1.p.1">The Request-Line begins with a method token, followed by the Request-URI and the protocol version, and ending with CRLF. The
    13111311         elements are separated by SP characters. No CR or LF is allowed except in the final CRLF sequence.
    13121312      </p>
    1313       <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.61"></span>     Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
     1313      <div id="rfc.figure.u.28"></div><pre class="inline"><span id="rfc.iref.g.61"></span>  Request-Line   = Method SP Request-URI SP HTTP-Version CRLF
    13141314</pre><h3 id="rfc.section.5.1.1"><a href="#rfc.section.5.1.1">5.1.1</a>&nbsp;<a id="method" href="#method">Method</a></h3>
    13151315      <p id="rfc.section.5.1.1.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p>
    1316       <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span>    Method         = token
     1316      <div id="rfc.figure.u.29"></div><pre class="inline"><span id="rfc.iref.g.62"></span><span id="rfc.iref.g.63"></span>  Method         = token
    13171317</pre><h3 id="rfc.section.5.1.2"><a href="#rfc.section.5.1.2">5.1.2</a>&nbsp;<a id="request-uri" href="#request-uri">Request-URI</a></h3>
    13181318      <p id="rfc.section.5.1.2.p.1">The Request-URI is a Uniform Resource Identifier (<a href="#uri" title="Uniform Resource Identifiers">Section&nbsp;3.2</a>) and identifies the resource upon which to apply the request.
    13191319      </p>
    1320       <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span>    Request-URI    = "*"
    1321                    | absoluteURI
    1322                    | ( abs_path [ "?" query ] )
    1323                    | authority
     1320      <div id="rfc.figure.u.30"></div><pre class="inline"><span id="rfc.iref.g.64"></span>  Request-URI    = "*"
     1321                 | absoluteURI
     1322                 | ( abs_path [ "?" query ] )
     1323                 | authority
    13241324</pre><p id="rfc.section.5.1.2.p.3">The four options for Request-URI are dependent on the nature of the request. The asterisk "*" means that the request does
    13251325         not apply to a particular resource, but to the server itself, and is only allowed when the method used does not necessarily
     
    13791379      <h1 id="rfc.section.6"><a href="#rfc.section.6">6.</a>&nbsp;<a id="response" href="#response">Response</a></h1>
    13801380      <p id="rfc.section.6.p.1">After receiving and interpreting a request message, a server responds with an HTTP response message.</p>
    1381       <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.65"></span>    Response      = Status-Line               ; <a href="#status-line" title="Status-Line">Section&nbsp;6.1</a>
    1382                     *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
    1383                      | response-header        ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>
    1384                      | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
    1385                     CRLF
    1386                     [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
     1381      <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.65"></span>  Response      = Status-Line               ; <a href="#status-line" title="Status-Line">Section&nbsp;6.1</a>
     1382                  *(( general-header        ; <a href="#general.header.fields" title="General Header Fields">Section&nbsp;4.5</a>
     1383                   | response-header        ; <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 6</a>
     1384                   | entity-header ) CRLF)  ; <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#entity.header.fields" title="Entity Header Fields">Section 3.1</a>
     1385                  CRLF
     1386                  [ message-body ]          ; <a href="#message.body" title="Message Body">Section&nbsp;4.3</a>
    13871387</pre><h2 id="rfc.section.6.1"><a href="#rfc.section.6.1">6.1</a>&nbsp;<a id="status-line" href="#status-line">Status-Line</a></h2>
    13881388      <p id="rfc.section.6.1.p.1">The first line of a Response message is the Status-Line, consisting of the protocol version followed by a numeric status code
     
    13901390         CRLF sequence.
    13911391      </p>
    1392       <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span>    Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
     1392      <div id="rfc.figure.u.35"></div><pre class="inline"><span id="rfc.iref.g.66"></span>  Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF
    13931393</pre><h3 id="rfc.section.6.1.1"><a href="#rfc.section.6.1.1">6.1.1</a>&nbsp;<a id="status.code.and.reason.phrase" href="#status.code.and.reason.phrase">Status Code and Reason Phrase</a></h3>
    13941394      <p id="rfc.section.6.1.1.p.1">The Status-Code element is a 3-digit integer result code of the attempt to understand and satisfy the request. These codes
     
    14061406         <li>5xx: Server Error - The server failed to fulfill an apparently valid request</li>
    14071407      </ul>
    1408       <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>   Status-Code    = 3DIGIT
    1409    Reason-Phrase  = *&lt;TEXT, excluding CR, LF&gt;
     1408      <div id="rfc.figure.u.36"></div><pre class="inline"><span id="rfc.iref.g.67"></span><span id="rfc.iref.g.68"></span><span id="rfc.iref.g.69"></span>  Status-Code    = 3DIGIT
     1409  Reason-Phrase  = *&lt;TEXT, excluding CR, LF&gt;
    14101410</pre><h1 id="rfc.section.7"><a href="#rfc.section.7">7.</a>&nbsp;<a id="connections" href="#connections">Connections</a></h1>
    14111411      <h2 id="rfc.section.7.1"><a href="#rfc.section.7.1">7.1</a>&nbsp;<a id="persistent.connections" href="#persistent.connections">Persistent Connections</a></h2>
     
    15971597      </p>
    15981598      <p id="rfc.section.8.1.p.2">The Connection header has the following grammar:</p>
    1599       <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>    Connection = "Connection" ":" 1#(connection-token)
    1600     connection-token  = token
     1599      <div id="rfc.figure.u.37"></div><pre class="inline"><span id="rfc.iref.g.70"></span><span id="rfc.iref.g.71"></span>  Connection = "Connection" ":" 1#(connection-token)
     1600  connection-token  = token
    16011601</pre><p id="rfc.section.8.1.p.4">HTTP/1.1 proxies <em class="bcp14">MUST</em> parse the Connection header field before a message is forwarded and, for each connection-token in this field, remove any header
    16021602         field(s) from the message with the same name as the connection-token. Connection options are signaled by the presence of a
     
    16251625         or, in the case of the HEAD method, the size of the entity-body that would have been sent had the request been a GET.
    16261626      </p>
    1627       <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.72"></span>    Content-Length    = "Content-Length" ":" 1*DIGIT
     1627      <div id="rfc.figure.u.39"></div><pre class="inline"><span id="rfc.iref.g.72"></span>  Content-Length    = "Content-Length" ":" 1*DIGIT
    16281628</pre><p id="rfc.section.8.2.p.3">An example is</p>
    16291629      <div id="rfc.figure.u.40"></div><pre class="text">    Content-Length: 3495
     
    16421642         as orig-date in <a href="http://tools.ietf.org/html/rfc2822#section-3.6.1">Section 3.6.1</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.4"><cite title="Internet Message Format">[RFC2822]</cite></a>. The field value is an HTTP-date, as described in <a href="#full.date" title="Full Date">Section&nbsp;3.3.1</a>; it <em class="bcp14">MUST</em> be sent in rfc1123-date format.
    16431643      </p>
    1644       <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>    Date  = "Date" ":" HTTP-date
     1644      <div id="rfc.figure.u.41"></div><pre class="inline"><span id="rfc.iref.g.73"></span>  Date  = "Date" ":" HTTP-date
    16451645</pre><p id="rfc.section.8.3.p.3">An example is</p>
    16461646      <div id="rfc.figure.u.42"></div><pre class="text">    Date: Tue, 15 Nov 1994 08:12:31 GMT
     
    16801680         a single IP address.
    16811681      </p>
    1682       <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.74"></span>    Host = "Host" ":" host [ ":" port ] ; <a href="#http.url" title="http URL">Section&nbsp;3.2.2</a>
     1682      <div id="rfc.figure.u.43"></div><pre class="inline"><span id="rfc.iref.g.74"></span>  Host = "Host" ":" host [ ":" port ] ; <a href="#http.url" title="http URL">Section&nbsp;3.2.2</a>
    16831683</pre><p id="rfc.section.8.4.p.3">A "host" without any trailing port information implies the default port for the service requested (e.g., "80" for an HTTP
    16841684         URL). For example, a request on the origin server for &lt;http://www.example.org/pub/WWW/&gt; would properly include:
     
    16991699         and/or a comma-separated list of extension transfer-coding names with optional accept parameters (as described in <a href="#transfer.codings" title="Transfer Codings">Section&nbsp;3.4</a>).
    17001700      </p>
    1701       <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>    TE        = "TE" ":" #( t-codings )
    1702     t-codings = "trailers" | ( transfer-extension [ accept-params ] )
     1701      <div id="rfc.figure.u.45"></div><pre class="inline"><span id="rfc.iref.g.75"></span><span id="rfc.iref.g.76"></span>  TE        = "TE" ":" #( t-codings )
     1702  t-codings = "trailers" | ( transfer-extension [ accept-params ] )
    17031703</pre><p id="rfc.section.8.5.p.3">The presence of the keyword "trailers" indicates that the client is willing to accept trailer fields in a chunked transfer-coding,
    17041704         as defined in <a href="#chunked.transfer.encoding" title="Chunked Transfer Coding">Section&nbsp;3.4.1</a>. This keyword is reserved for use with transfer-coding values even though it does not itself represent a transfer-coding.
     
    17421742         with chunked transfer-coding.
    17431743      </p>
    1744       <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.77"></span>    Trailer  = "Trailer" ":" 1#field-name
     1744      <div id="rfc.figure.u.47"></div><pre class="inline"><span id="rfc.iref.g.77"></span>  Trailer  = "Trailer" ":" 1#field-name
    17451745</pre><p id="rfc.section.8.6.p.3">An HTTP/1.1 message <em class="bcp14">SHOULD</em> include a Trailer header field in a message using chunked transfer-coding with a non-empty trailer. Doing so allows the recipient
    17461746         to know which header fields to expect in the trailer.
     
    17751775         to use if the server finds it appropriate to switch protocols. The server <em class="bcp14">MUST</em> use the Upgrade header field within a 101 (Switching Protocols) response to indicate which protocol(s) are being switched.
    17761776      </p>
    1777       <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.79"></span>    Upgrade        = "Upgrade" ":" 1#product
     1777      <div id="rfc.figure.u.50"></div><pre class="inline"><span id="rfc.iref.g.79"></span>  Upgrade        = "Upgrade" ":" 1#product
    17781778</pre><p id="rfc.section.8.8.p.3">For example,</p>
    17791779      <div id="rfc.figure.u.51"></div><pre class="text">    Upgrade: HTTP/2.0, SHTTP/1.3, IRC/6.9, RTA/x11
     
    18061806         of all senders along the request/response chain.
    18071807      </p>
    1808       <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span>   Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
    1809    received-protocol = [ protocol-name "/" ] protocol-version
    1810    protocol-name     = token
    1811    protocol-version  = token
    1812    received-by       = ( host [ ":" port ] ) | pseudonym
    1813    pseudonym         = token
     1808      <div id="rfc.figure.u.52"></div><pre class="inline"><span id="rfc.iref.g.80"></span><span id="rfc.iref.g.81"></span><span id="rfc.iref.g.82"></span><span id="rfc.iref.g.83"></span><span id="rfc.iref.g.84"></span><span id="rfc.iref.g.85"></span>  Via =  "Via" ":" 1#( received-protocol received-by [ comment ] )
     1809  received-protocol = [ protocol-name "/" ] protocol-version
     1810  protocol-name     = token
     1811  protocol-version  = token
     1812  received-by       = ( host [ ":" port ] ) | pseudonym
     1813  pseudonym         = token
    18141814</pre><p id="rfc.section.8.9.p.3">The received-protocol indicates the protocol version of the message received by the server or client along each segment of
    18151815         the request/response chain. The received-protocol version is appended to the Via field value when the message is forwarded
Note: See TracChangeset for help on using the changeset viewer.