Changeset 623


Ignore:
Timestamp:
26/07/09 11:50:23 (13 years ago)
Author:
fielding@…
Message:

Move the protocol parameters below the definition of HTTP messages.
The subsections will probably be redistributed later.

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.xml

    r622 r623  
    835835</section>
    836836
    837 <section title="Protocol Parameters" anchor="protocol.parameters">
    838 
    839 <section title="HTTP Version" anchor="http.version">
    840   <x:anchor-alias value="HTTP-Version"/>
    841   <x:anchor-alias value="HTTP-Prot-Name"/>
    842 <t>
    843    HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
    844    of the protocol. The protocol versioning policy is intended to allow
    845    the sender to indicate the format of a message and its capacity for
    846    understanding further HTTP communication, rather than the features
    847    obtained via that communication. No change is made to the version
    848    number for the addition of message components which do not affect
    849    communication behavior or which only add to extensible field values.
    850    The &lt;minor&gt; number is incremented when the changes made to the
    851    protocol add features which do not change the general message parsing
    852    algorithm, but which may add to the message semantics and imply
    853    additional capabilities of the sender. The &lt;major&gt; number is
    854    incremented when the format of a message within the protocol is
    855    changed. See <xref target="RFC2145"/> for a fuller explanation.
    856 </t>
    857 <t>
    858    The version of an HTTP message is indicated by an HTTP-Version field
    859    in the first line of the message. HTTP-Version is case-sensitive.
    860 </t>
    861 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>
    862   <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
    863   <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
    864 </artwork></figure>
    865 <t>
    866    Note that the major and minor numbers &MUST; be treated as separate
    867    integers and that each &MAY; be incremented higher than a single digit.
    868    Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
    869    lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
    870    &MUST-NOT; be sent.
    871 </t>
    872 <t>
    873    An application that sends a request or response message that includes
    874    HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
    875    with this specification. Applications that are at least conditionally
    876    compliant with this specification &SHOULD; use an HTTP-Version of
    877    "HTTP/1.1" in their messages, and &MUST; do so for any message that is
    878    not compatible with HTTP/1.0. For more details on when to send
    879    specific HTTP-Version values, see <xref target="RFC2145"/>.
    880 </t>
    881 <t>
    882    The HTTP version of an application is the highest HTTP version for
    883    which the application is at least conditionally compliant.
    884 </t>
    885 <t>
    886    Proxy and gateway applications need to be careful when forwarding
    887    messages in protocol versions different from that of the application.
    888    Since the protocol version indicates the protocol capability of the
    889    sender, a proxy/gateway &MUST-NOT; send a message with a version
    890    indicator which is greater than its actual version. If a higher
    891    version request is received, the proxy/gateway &MUST; either downgrade
    892    the request version, or respond with an error, or switch to tunnel
    893    behavior.
    894 </t>
    895 <t>
    896    Due to interoperability problems with HTTP/1.0 proxies discovered
    897    since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
    898    &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
    899    they support. The proxy/gateway's response to that request &MUST; be in
    900    the same major version as the request.
    901 </t>
    902 <x:note>
    903   <t>
    904     <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
    905     of header fields required or forbidden by the versions involved.
    906   </t>
    907 </x:note>
    908 </section>
    909 
    910 <section title="Date/Time Formats: Full Date" anchor="date.time.formats.full.date">
    911   <x:anchor-alias value="HTTP-date"/>
    912 <t>
    913    HTTP applications have historically allowed three different formats
    914    for the representation of date/time stamps:
    915 </t>
    916 <figure><artwork type="example">
    917   Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
    918   Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
    919   Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
    920 </artwork></figure>
    921 <t>
    922    The first format is preferred as an Internet standard and represents
    923    a fixed-length subset of that defined by <xref target="RFC1123"/>. The
    924    other formats are described here only for
    925    compatibility with obsolete implementations.
    926    HTTP/1.1 clients and servers that parse the date value &MUST; accept
    927    all three formats (for compatibility with HTTP/1.0), though they &MUST;
    928    only generate the RFC 1123 format for representing HTTP-date values
    929    in header fields. See <xref target="tolerant.applications"/> for further information.
    930 </t>
    931 <t>
    932    All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
    933    (GMT), without exception. For the purposes of HTTP, GMT is exactly
    934    equal to UTC (Coordinated Universal Time). This is indicated in the
    935    first two formats by the inclusion of "GMT" as the three-letter
    936    abbreviation for time zone, and &MUST; be assumed when reading the
    937    asctime format. HTTP-date is case sensitive and &MUST-NOT; include
    938    additional whitespace beyond that specifically included as SP in the
    939    grammar.
    940 </t>
    941 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/>
    942   <x:ref>HTTP-date</x:ref>    = <x:ref>rfc1123-date</x:ref> / <x:ref>obs-date</x:ref>
    943 </artwork></figure>
    944 <t anchor="preferred.date.format">
    945   <x:anchor-alias value="rfc1123-date"/>
    946   <x:anchor-alias value="time-of-day"/>
    947   <x:anchor-alias value="hour"/>
    948   <x:anchor-alias value="minute"/>
    949   <x:anchor-alias value="second"/>
    950   <x:anchor-alias value="day-name"/>
    951   <x:anchor-alias value="day"/>
    952   <x:anchor-alias value="month"/>
    953   <x:anchor-alias value="year"/>
    954   <x:anchor-alias value="GMT"/>
    955   Preferred format:
    956 </t>
    957 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>
    958   <x:ref>rfc1123-date</x:ref> = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
    959 
    960   <x:ref>day-name</x:ref>     = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive
    961                / <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive
    962                / <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive
    963                / <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive
    964                / <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive
    965                / <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive
    966                / <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive
    967                
    968   <x:ref>date1</x:ref>        = <x:ref>day</x:ref> <x:ref>SP</x:ref> <x:ref>month</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
    969                ; e.g., 02 Jun 1982
    970 
    971   <x:ref>day</x:ref>          = 2<x:ref>DIGIT</x:ref>
    972   <x:ref>month</x:ref>        = <x:abnf-char-sequence>"Jan"</x:abnf-char-sequence> ; "Jan", case-sensitive
    973                / <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive
    974                / <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive
    975                / <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive
    976                / <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive
    977                / <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive
    978                / <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive
    979                / <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive
    980                / <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive
    981                / <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive
    982                / <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive
    983                / <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive
    984   <x:ref>year</x:ref>         = 4<x:ref>DIGIT</x:ref>
    985 
    986   <x:ref>GMT</x:ref>   = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
    987 
    988   <x:ref>time-of-day</x:ref>  = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref>
    989                  ; 00:00:00 - 23:59:59
    990                  
    991   <x:ref>hour</x:ref>         = 2<x:ref>DIGIT</x:ref>               
    992   <x:ref>minute</x:ref>       = 2<x:ref>DIGIT</x:ref>               
    993   <x:ref>second</x:ref>       = 2<x:ref>DIGIT</x:ref>               
    994 </artwork></figure>
    995 <t>
    996   The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,
    997   <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> are the
    998   same as those defined for the RFC 5322 constructs
    999   with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
    1000 </t>
    1001 <t anchor="obsolete.date.formats">
    1002   <x:anchor-alias value="obs-date"/>
    1003   <x:anchor-alias value="rfc850-date"/>
    1004   <x:anchor-alias value="asctime-date"/>
    1005   <x:anchor-alias value="date1"/>
    1006   <x:anchor-alias value="date2"/>
    1007   <x:anchor-alias value="date3"/>
    1008   <x:anchor-alias value="rfc1123-date"/>
    1009   <x:anchor-alias value="day-name-l"/>
    1010   Obsolete formats:
    1011 </t>
    1012 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="obs-date"/>
    1013   <x:ref>obs-date</x:ref>     = <x:ref>rfc850-date</x:ref> / <x:ref>asctime-date</x:ref>
    1014 </artwork></figure>
    1015 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc850-date"/>
    1016   <x:ref>rfc850-date</x:ref>  = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
    1017   <x:ref>date2</x:ref>        = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref>
    1018                  ; day-month-year (e.g., 02-Jun-82)
    1019 
    1020   <x:ref>day-name-l</x:ref>   = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive
    1021          / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive
    1022          / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive
    1023          / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive
    1024          / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive
    1025          / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive
    1026          / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive
    1027 </artwork></figure>
    1028 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/>
    1029   <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
    1030   <x:ref>date3</x:ref>        = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> ))
    1031                  ; month day (e.g., Jun  2)
    1032 </artwork></figure>
    1033 <x:note>
    1034   <t>
    1035     <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
    1036     accepting date values that may have been sent by non-HTTP
    1037     applications, as is sometimes the case when retrieving or posting
    1038     messages via proxies/gateways to SMTP or NNTP.
    1039   </t>
    1040 </x:note>
    1041 <x:note>
    1042   <t>
    1043     <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only
    1044     to their usage within the protocol stream. Clients and servers are
    1045     not required to use these formats for user presentation, request
    1046     logging, etc.
    1047   </t>
    1048 </x:note>
    1049 </section>
    1050 
    1051 <section title="Transfer Codings" anchor="transfer.codings">
    1052   <x:anchor-alias value="transfer-coding"/>
    1053   <x:anchor-alias value="transfer-extension"/>
    1054 <t>
    1055    Transfer-coding values are used to indicate an encoding
    1056    transformation that has been, can be, or may need to be applied to an
    1057    entity-body in order to ensure "safe transport" through the network.
    1058    This differs from a content coding in that the transfer-coding is a
    1059    property of the message, not of the original entity.
    1060 </t>
    1061 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/>
    1062   <x:ref>transfer-coding</x:ref>         = "chunked" / <x:ref>transfer-extension</x:ref>
    1063   <x:ref>transfer-extension</x:ref>      = <x:ref>token</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>transfer-parameter</x:ref> )
    1064 </artwork></figure>
    1065 <t anchor="rule.parameter">
    1066   <x:anchor-alias value="attribute"/>
    1067   <x:anchor-alias value="transfer-parameter"/>
    1068   <x:anchor-alias value="value"/>
    1069    Parameters are in  the form of attribute/value pairs.
    1070 </t>
    1071 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/>
    1072   <x:ref>transfer-parameter</x:ref>      = <x:ref>attribute</x:ref> <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>value</x:ref>
    1073   <x:ref>attribute</x:ref>               = <x:ref>token</x:ref>
    1074   <x:ref>value</x:ref>                   = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
    1075 </artwork></figure>
    1076 <t>
    1077    All transfer-coding values are case-insensitive. HTTP/1.1 uses
    1078    transfer-coding values in the TE header field (<xref target="header.te"/>) and in
    1079    the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
    1080 </t>
    1081 <t>
    1082    Whenever a transfer-coding is applied to a message-body, the set of
    1083    transfer-codings &MUST; include "chunked", unless the message indicates it
    1084    is terminated by closing the connection. When the "chunked" transfer-coding
    1085    is used, it &MUST; be the last transfer-coding applied to the
    1086    message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
    1087    than once to a message-body. These rules allow the recipient to
    1088    determine the transfer-length of the message (<xref target="message.length"/>).
    1089 </t>
    1090 <t>
    1091    Transfer-codings are analogous to the Content-Transfer-Encoding
    1092    values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of
    1093    binary data over a 7-bit transport service. However, safe transport
    1094    has a different focus for an 8bit-clean transfer protocol. In HTTP,
    1095    the only unsafe characteristic of message-bodies is the difficulty in
    1096    determining the exact body length (<xref target="message.length"/>), or the desire to
    1097    encrypt data over a shared transport.
    1098 </t>
    1099 <t>
    1100    The Internet Assigned Numbers Authority (IANA) acts as a registry for
    1101    transfer-coding value tokens. Initially, the registry contains the
    1102    following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>),
    1103    "gzip", "compress", and "deflate" (&content-codings;).
    1104 </t>
    1105 <t>
    1106    New transfer-coding value tokens &SHOULD; be registered in the same way
    1107    as new content-coding value tokens (&content-codings;).
    1108 </t>
    1109 <t>
    1110    A server which receives an entity-body with a transfer-coding it does
    1111    not understand &SHOULD; return 501 (Not Implemented), and close the
    1112    connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
    1113    client.
    1114 </t>
    1115 
    1116 <section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding">
    1117   <x:anchor-alias value="chunk"/>
    1118   <x:anchor-alias value="Chunked-Body"/>
    1119   <x:anchor-alias value="chunk-data"/>
    1120   <x:anchor-alias value="chunk-ext"/>
    1121   <x:anchor-alias value="chunk-ext-name"/>
    1122   <x:anchor-alias value="chunk-ext-val"/>
    1123   <x:anchor-alias value="chunk-size"/>
    1124   <x:anchor-alias value="last-chunk"/>
    1125   <x:anchor-alias value="trailer-part"/>
    1126 <t>
    1127    The chunked encoding modifies the body of a message in order to
    1128    transfer it as a series of chunks, each with its own size indicator,
    1129    followed by an &OPTIONAL; trailer containing entity-header fields. This
    1130    allows dynamically produced content to be transferred along with the
    1131    information necessary for the recipient to verify that it has
    1132    received the full message.
    1133 </t>
    1134 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer-part"/>
    1135   <x:ref>Chunked-Body</x:ref>   = *<x:ref>chunk</x:ref>
    1136                    <x:ref>last-chunk</x:ref>
    1137                    <x:ref>trailer-part</x:ref>
    1138                    <x:ref>CRLF</x:ref>
    1139  
    1140   <x:ref>chunk</x:ref>          = <x:ref>chunk-size</x:ref> *WSP [ <x:ref>chunk-ext</x:ref> ] <x:ref>CRLF</x:ref>
    1141                    <x:ref>chunk-data</x:ref> <x:ref>CRLF</x:ref>
    1142   <x:ref>chunk-size</x:ref>     = 1*<x:ref>HEXDIG</x:ref>
    1143   <x:ref>last-chunk</x:ref>     = 1*("0") *WSP [ <x:ref>chunk-ext</x:ref> ] <x:ref>CRLF</x:ref>
    1144  
    1145   <x:ref>chunk-ext</x:ref>      = *( ";" *WSP <x:ref>chunk-ext-name</x:ref>
    1146                       [ "=" <x:ref>chunk-ext-val</x:ref> ] *WSP )
    1147   <x:ref>chunk-ext-name</x:ref> = <x:ref>token</x:ref>
    1148   <x:ref>chunk-ext-val</x:ref>  = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
    1149   <x:ref>chunk-data</x:ref>     = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets
    1150   <x:ref>trailer-part</x:ref>   = *( <x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref> )
    1151 </artwork></figure>
    1152 <t>
    1153    The chunk-size field is a string of hex digits indicating the size of
    1154    the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
    1155    zero, followed by the trailer, which is terminated by an empty line.
    1156 </t>
    1157 <t>
    1158    The trailer allows the sender to include additional HTTP header
    1159    fields at the end of the message. The Trailer header field can be
    1160    used to indicate which header fields are included in a trailer (see
    1161    <xref target="header.trailer"/>).
    1162 </t>
    1163 <t>
    1164    A server using chunked transfer-coding in a response &MUST-NOT; use the
    1165    trailer for any header fields unless at least one of the following is
    1166    true:
    1167   <list style="numbers">
    1168     <t>the request included a TE header field that indicates "trailers" is
    1169      acceptable in the transfer-coding of the  response, as described in
    1170      <xref target="header.te"/>; or,</t>
    1171 
    1172     <t>the server is the origin server for the response, the trailer
    1173      fields consist entirely of optional metadata, and the recipient
    1174      could use the message (in a manner acceptable to the origin server)
    1175      without receiving this metadata.  In other words, the origin server
    1176      is willing to accept the possibility that the trailer fields might
    1177      be silently discarded along the path to the client.</t>
    1178   </list>
    1179 </t>
    1180 <t>
    1181    This requirement prevents an interoperability failure when the
    1182    message is being received by an HTTP/1.1 (or later) proxy and
    1183    forwarded to an HTTP/1.0 recipient. It avoids a situation where
    1184    compliance with the protocol would have necessitated a possibly
    1185    infinite buffer on the proxy.
    1186 </t>
    1187 <t>
    1188    A process for decoding the "chunked" transfer-coding
    1189    can be represented in pseudo-code as:
    1190 </t>
    1191 <figure><artwork type="code">
    1192   length := 0
    1193   read chunk-size, chunk-ext (if any) and CRLF
    1194   while (chunk-size &gt; 0) {
    1195      read chunk-data and CRLF
    1196      append chunk-data to entity-body
    1197      length := length + chunk-size
    1198      read chunk-size and CRLF
    1199   }
    1200   read entity-header
    1201   while (entity-header not empty) {
    1202      append entity-header to existing header fields
    1203      read entity-header
    1204   }
    1205   Content-Length := length
    1206   Remove "chunked" from Transfer-Encoding
    1207 </artwork></figure>
    1208 <t>
    1209    All HTTP/1.1 applications &MUST; be able to receive and decode the
    1210    "chunked" transfer-coding, and &MUST; ignore chunk-ext extensions
    1211    they do not understand.
    1212 </t>
    1213 </section>
    1214 </section>
    1215 
    1216 <section title="Product Tokens" anchor="product.tokens">
    1217   <x:anchor-alias value="product"/>
    1218   <x:anchor-alias value="product-version"/>
    1219 <t>
    1220    Product tokens are used to allow communicating applications to
    1221    identify themselves by software name and version. Most fields using
    1222    product tokens also allow sub-products which form a significant part
    1223    of the application to be listed, separated by whitespace. By
    1224    convention, the products are listed in order of their significance
    1225    for identifying the application.
    1226 </t>
    1227 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
    1228   <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
    1229   <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
    1230 </artwork></figure>
    1231 <t>
    1232    Examples:
    1233 </t>
    1234 <figure><artwork type="example">
    1235   User-Agent: CERN-LineMode/2.15 libwww/2.17b3
    1236   Server: Apache/0.8.4
    1237 </artwork></figure>
    1238 <t>
    1239    Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
    1240    used for advertising or other non-essential information. Although any
    1241    token character &MAY; appear in a product-version, this token &SHOULD;
    1242    only be used for a version identifier (i.e., successive versions of
    1243    the same product &SHOULD; only differ in the product-version portion of
    1244    the product value).
    1245 </t>
    1246 </section>
    1247 
    1248 <section title="Quality Values" anchor="quality.values">
    1249   <x:anchor-alias value="qvalue"/>
    1250 <t>
    1251    Both transfer codings (TE request header, <xref target="header.te"/>)
    1252    and content negotiation (&content.negotiation;) use short "floating point"
    1253    numbers to indicate the relative importance ("weight") of various
    1254    negotiable parameters.  A weight is normalized to a real number in
    1255    the range 0 through 1, where 0 is the minimum and 1 the maximum
    1256    value. If a parameter has a quality value of 0, then content with
    1257    this parameter is `not acceptable' for the client. HTTP/1.1
    1258    applications &MUST-NOT; generate more than three digits after the
    1259    decimal point. User configuration of these values &SHOULD; also be
    1260    limited in this fashion.
    1261 </t>
    1262 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="qvalue"/>
    1263   <x:ref>qvalue</x:ref>         = ( "0" [ "." 0*3<x:ref>DIGIT</x:ref> ] )
    1264                  / ( "1" [ "." 0*3("0") ] )
    1265 </artwork></figure>
    1266 <x:note>
    1267   <t>
    1268      <x:h>Note:</x:h> "Quality values" is a misnomer, since these values merely represent
    1269      relative degradation in desired quality.
    1270   </t>
    1271 </x:note>
    1272 </section>
    1273 
    1274 </section>
    1275 
    1276837<section title="HTTP Message" anchor="http.message">
    1277838
    … …  
    18581419</section>
    18591420
     1421
     1422<section title="Protocol Parameters" anchor="protocol.parameters">
     1423
     1424<section title="HTTP Version" anchor="http.version">
     1425  <x:anchor-alias value="HTTP-Version"/>
     1426  <x:anchor-alias value="HTTP-Prot-Name"/>
     1427<t>
     1428   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions
     1429   of the protocol. The protocol versioning policy is intended to allow
     1430   the sender to indicate the format of a message and its capacity for
     1431   understanding further HTTP communication, rather than the features
     1432   obtained via that communication. No change is made to the version
     1433   number for the addition of message components which do not affect
     1434   communication behavior or which only add to extensible field values.
     1435   The &lt;minor&gt; number is incremented when the changes made to the
     1436   protocol add features which do not change the general message parsing
     1437   algorithm, but which may add to the message semantics and imply
     1438   additional capabilities of the sender. The &lt;major&gt; number is
     1439   incremented when the format of a message within the protocol is
     1440   changed. See <xref target="RFC2145"/> for a fuller explanation.
     1441</t>
     1442<t>
     1443   The version of an HTTP message is indicated by an HTTP-Version field
     1444   in the first line of the message. HTTP-Version is case-sensitive.
     1445</t>
     1446<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-Version"/><iref primary="true" item="Grammar" subitem="HTTP-Prot-Name"/>
     1447  <x:ref>HTTP-Version</x:ref>   = <x:ref>HTTP-Prot-Name</x:ref> "/" 1*<x:ref>DIGIT</x:ref> "." 1*<x:ref>DIGIT</x:ref>
     1448  <x:ref>HTTP-Prot-Name</x:ref> = <x:abnf-char-sequence>"HTTP"</x:abnf-char-sequence> ; "HTTP", case-sensitive
     1449</artwork></figure>
     1450<t>
     1451   Note that the major and minor numbers &MUST; be treated as separate
     1452   integers and that each &MAY; be incremented higher than a single digit.
     1453   Thus, HTTP/2.4 is a lower version than HTTP/2.13, which in turn is
     1454   lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and
     1455   &MUST-NOT; be sent.
     1456</t>
     1457<t>
     1458   An application that sends a request or response message that includes
     1459   HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant
     1460   with this specification. Applications that are at least conditionally
     1461   compliant with this specification &SHOULD; use an HTTP-Version of
     1462   "HTTP/1.1" in their messages, and &MUST; do so for any message that is
     1463   not compatible with HTTP/1.0. For more details on when to send
     1464   specific HTTP-Version values, see <xref target="RFC2145"/>.
     1465</t>
     1466<t>
     1467   The HTTP version of an application is the highest HTTP version for
     1468   which the application is at least conditionally compliant.
     1469</t>
     1470<t>
     1471   Proxy and gateway applications need to be careful when forwarding
     1472   messages in protocol versions different from that of the application.
     1473   Since the protocol version indicates the protocol capability of the
     1474   sender, a proxy/gateway &MUST-NOT; send a message with a version
     1475   indicator which is greater than its actual version. If a higher
     1476   version request is received, the proxy/gateway &MUST; either downgrade
     1477   the request version, or respond with an error, or switch to tunnel
     1478   behavior.
     1479</t>
     1480<t>
     1481   Due to interoperability problems with HTTP/1.0 proxies discovered
     1482   since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways
     1483   &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version
     1484   they support. The proxy/gateway's response to that request &MUST; be in
     1485   the same major version as the request.
     1486</t>
     1487<x:note>
     1488  <t>
     1489    <x:h>Note:</x:h> Converting between versions of HTTP may involve modification
     1490    of header fields required or forbidden by the versions involved.
     1491  </t>
     1492</x:note>
     1493</section>
     1494
     1495<section title="Date/Time Formats: Full Date" anchor="date.time.formats.full.date">
     1496  <x:anchor-alias value="HTTP-date"/>
     1497<t>
     1498   HTTP applications have historically allowed three different formats
     1499   for the representation of date/time stamps:
     1500</t>
     1501<figure><artwork type="example">
     1502  Sun, 06 Nov 1994 08:49:37 GMT  ; RFC 1123
     1503  Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format
     1504  Sun Nov  6 08:49:37 1994       ; ANSI C's asctime() format
     1505</artwork></figure>
     1506<t>
     1507   The first format is preferred as an Internet standard and represents
     1508   a fixed-length subset of that defined by <xref target="RFC1123"/>. The
     1509   other formats are described here only for
     1510   compatibility with obsolete implementations.
     1511   HTTP/1.1 clients and servers that parse the date value &MUST; accept
     1512   all three formats (for compatibility with HTTP/1.0), though they &MUST;
     1513   only generate the RFC 1123 format for representing HTTP-date values
     1514   in header fields. See <xref target="tolerant.applications"/> for further information.
     1515</t>
     1516<t>
     1517   All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time
     1518   (GMT), without exception. For the purposes of HTTP, GMT is exactly
     1519   equal to UTC (Coordinated Universal Time). This is indicated in the
     1520   first two formats by the inclusion of "GMT" as the three-letter
     1521   abbreviation for time zone, and &MUST; be assumed when reading the
     1522   asctime format. HTTP-date is case sensitive and &MUST-NOT; include
     1523   additional whitespace beyond that specifically included as SP in the
     1524   grammar.
     1525</t>
     1526<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="HTTP-date"/>
     1527  <x:ref>HTTP-date</x:ref>    = <x:ref>rfc1123-date</x:ref> / <x:ref>obs-date</x:ref>
     1528</artwork></figure>
     1529<t anchor="preferred.date.format">
     1530  <x:anchor-alias value="rfc1123-date"/>
     1531  <x:anchor-alias value="time-of-day"/>
     1532  <x:anchor-alias value="hour"/>
     1533  <x:anchor-alias value="minute"/>
     1534  <x:anchor-alias value="second"/>
     1535  <x:anchor-alias value="day-name"/>
     1536  <x:anchor-alias value="day"/>
     1537  <x:anchor-alias value="month"/>
     1538  <x:anchor-alias value="year"/>
     1539  <x:anchor-alias value="GMT"/>
     1540  Preferred format:
     1541</t>
     1542<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc1123-date"/><iref primary="true" item="Grammar" subitem="date1"/><iref primary="true" item="Grammar" subitem="time-of-day"/><iref primary="true" item="Grammar" subitem="hour"/><iref primary="true" item="Grammar" subitem="minute"/><iref primary="true" item="Grammar" subitem="second"/><iref primary="true" item="Grammar" subitem="day-name"/><iref primary="true" item="Grammar" subitem="day-name-l"/><iref primary="true" item="Grammar" subitem="day"/><iref primary="true" item="Grammar" subitem="month"/><iref primary="true" item="Grammar" subitem="year"/><iref primary="true" item="Grammar" subitem="GMT"/>
     1543  <x:ref>rfc1123-date</x:ref> = <x:ref>day-name</x:ref> "," <x:ref>SP</x:ref> date1 <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
     1544
     1545  <x:ref>day-name</x:ref>     = <x:abnf-char-sequence>"Mon"</x:abnf-char-sequence> ; "Mon", case-sensitive
     1546               / <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive
     1547               / <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive
     1548               / <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive
     1549               / <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive
     1550               / <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive
     1551               / <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive
     1552               
     1553  <x:ref>date1</x:ref>        = <x:ref>day</x:ref> <x:ref>SP</x:ref> <x:ref>month</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
     1554               ; e.g., 02 Jun 1982
     1555
     1556  <x:ref>day</x:ref>          = 2<x:ref>DIGIT</x:ref>
     1557  <x:ref>month</x:ref>        = <x:abnf-char-sequence>"Jan"</x:abnf-char-sequence> ; "Jan", case-sensitive
     1558               / <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive
     1559               / <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive
     1560               / <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive
     1561               / <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive
     1562               / <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive
     1563               / <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive
     1564               / <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive
     1565               / <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive
     1566               / <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive
     1567               / <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive
     1568               / <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive
     1569  <x:ref>year</x:ref>         = 4<x:ref>DIGIT</x:ref>
     1570
     1571  <x:ref>GMT</x:ref>   = <x:abnf-char-sequence>"GMT"</x:abnf-char-sequence> ; "GMT", case-sensitive
     1572
     1573  <x:ref>time-of-day</x:ref>  = <x:ref>hour</x:ref> ":" <x:ref>minute</x:ref> ":" <x:ref>second</x:ref>
     1574                 ; 00:00:00 - 23:59:59
     1575                 
     1576  <x:ref>hour</x:ref>         = 2<x:ref>DIGIT</x:ref>               
     1577  <x:ref>minute</x:ref>       = 2<x:ref>DIGIT</x:ref>               
     1578  <x:ref>second</x:ref>       = 2<x:ref>DIGIT</x:ref>               
     1579</artwork></figure>
     1580<t>
     1581  The semantics of <x:ref>day-name</x:ref>, <x:ref>day</x:ref>,
     1582  <x:ref>month</x:ref>, <x:ref>year</x:ref>, and <x:ref>time-of-day</x:ref> are the
     1583  same as those defined for the RFC 5322 constructs
     1584  with the corresponding name (<xref target="RFC5322" x:fmt="," x:sec="3.3"/>).
     1585</t>
     1586<t anchor="obsolete.date.formats">
     1587  <x:anchor-alias value="obs-date"/>
     1588  <x:anchor-alias value="rfc850-date"/>
     1589  <x:anchor-alias value="asctime-date"/>
     1590  <x:anchor-alias value="date1"/>
     1591  <x:anchor-alias value="date2"/>
     1592  <x:anchor-alias value="date3"/>
     1593  <x:anchor-alias value="rfc1123-date"/>
     1594  <x:anchor-alias value="day-name-l"/>
     1595  Obsolete formats:
     1596</t>
     1597<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="obs-date"/>
     1598  <x:ref>obs-date</x:ref>     = <x:ref>rfc850-date</x:ref> / <x:ref>asctime-date</x:ref>
     1599</artwork></figure>
     1600<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="rfc850-date"/>
     1601  <x:ref>rfc850-date</x:ref>  = <x:ref>day-name-l</x:ref> "," <x:ref>SP</x:ref> <x:ref>date2</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>GMT</x:ref>
     1602  <x:ref>date2</x:ref>        = <x:ref>day</x:ref> "-" <x:ref>month</x:ref> "-" 2<x:ref>DIGIT</x:ref>
     1603                 ; day-month-year (e.g., 02-Jun-82)
     1604
     1605  <x:ref>day-name-l</x:ref>   = <x:abnf-char-sequence>"Monday"</x:abnf-char-sequence> ; "Monday", case-sensitive
     1606         / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive
     1607         / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive
     1608         / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive
     1609         / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive
     1610         / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive
     1611         / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive
     1612</artwork></figure>
     1613<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="asctime-date"/>
     1614  <x:ref>asctime-date</x:ref> = <x:ref>day-name</x:ref> <x:ref>SP</x:ref> <x:ref>date3</x:ref> <x:ref>SP</x:ref> <x:ref>time-of-day</x:ref> <x:ref>SP</x:ref> <x:ref>year</x:ref>
     1615  <x:ref>date3</x:ref>        = <x:ref>month</x:ref> <x:ref>SP</x:ref> ( 2<x:ref>DIGIT</x:ref> / ( <x:ref>SP</x:ref> 1<x:ref>DIGIT</x:ref> ))
     1616                 ; month day (e.g., Jun  2)
     1617</artwork></figure>
     1618<x:note>
     1619  <t>
     1620    <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in
     1621    accepting date values that may have been sent by non-HTTP
     1622    applications, as is sometimes the case when retrieving or posting
     1623    messages via proxies/gateways to SMTP or NNTP.
     1624  </t>
     1625</x:note>
     1626<x:note>
     1627  <t>
     1628    <x:h>Note:</x:h> HTTP requirements for the date/time stamp format apply only
     1629    to their usage within the protocol stream. Clients and servers are
     1630    not required to use these formats for user presentation, request
     1631    logging, etc.
     1632  </t>
     1633</x:note>
     1634</section>
     1635
     1636<section title="Transfer Codings" anchor="transfer.codings">
     1637  <x:anchor-alias value="transfer-coding"/>
     1638  <x:anchor-alias value="transfer-extension"/>
     1639<t>
     1640   Transfer-coding values are used to indicate an encoding
     1641   transformation that has been, can be, or may need to be applied to an
     1642   entity-body in order to ensure "safe transport" through the network.
     1643   This differs from a content coding in that the transfer-coding is a
     1644   property of the message, not of the original entity.
     1645</t>
     1646<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-coding"/><iref primary="true" item="Grammar" subitem="transfer-extension"/>
     1647  <x:ref>transfer-coding</x:ref>         = "chunked" / <x:ref>transfer-extension</x:ref>
     1648  <x:ref>transfer-extension</x:ref>      = <x:ref>token</x:ref> *( <x:ref>OWS</x:ref> ";" <x:ref>OWS</x:ref> <x:ref>transfer-parameter</x:ref> )
     1649</artwork></figure>
     1650<t anchor="rule.parameter">
     1651  <x:anchor-alias value="attribute"/>
     1652  <x:anchor-alias value="transfer-parameter"/>
     1653  <x:anchor-alias value="value"/>
     1654   Parameters are in  the form of attribute/value pairs.
     1655</t>
     1656<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="transfer-parameter"/><iref primary="true" item="Grammar" subitem="attribute"/><iref primary="true" item="Grammar" subitem="value"/><iref primary="true" item="Grammar" subitem="date2"/><iref primary="true" item="Grammar" subitem="date3"/>
     1657  <x:ref>transfer-parameter</x:ref>      = <x:ref>attribute</x:ref> <x:ref>BWS</x:ref> "=" <x:ref>BWS</x:ref> <x:ref>value</x:ref>
     1658  <x:ref>attribute</x:ref>               = <x:ref>token</x:ref>
     1659  <x:ref>value</x:ref>                   = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
     1660</artwork></figure>
     1661<t>
     1662   All transfer-coding values are case-insensitive. HTTP/1.1 uses
     1663   transfer-coding values in the TE header field (<xref target="header.te"/>) and in
     1664   the Transfer-Encoding header field (<xref target="header.transfer-encoding"/>).
     1665</t>
     1666<t>
     1667   Whenever a transfer-coding is applied to a message-body, the set of
     1668   transfer-codings &MUST; include "chunked", unless the message indicates it
     1669   is terminated by closing the connection. When the "chunked" transfer-coding
     1670   is used, it &MUST; be the last transfer-coding applied to the
     1671   message-body. The "chunked" transfer-coding &MUST-NOT; be applied more
     1672   than once to a message-body. These rules allow the recipient to
     1673   determine the transfer-length of the message (<xref target="message.length"/>).
     1674</t>
     1675<t>
     1676   Transfer-codings are analogous to the Content-Transfer-Encoding
     1677   values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of
     1678   binary data over a 7-bit transport service. However, safe transport
     1679   has a different focus for an 8bit-clean transfer protocol. In HTTP,
     1680   the only unsafe characteristic of message-bodies is the difficulty in
     1681   determining the exact body length (<xref target="message.length"/>), or the desire to
     1682   encrypt data over a shared transport.
     1683</t>
     1684<t>
     1685   The Internet Assigned Numbers Authority (IANA) acts as a registry for
     1686   transfer-coding value tokens. Initially, the registry contains the
     1687   following tokens: "chunked" (<xref target="chunked.transfer.encoding"/>),
     1688   "gzip", "compress", and "deflate" (&content-codings;).
     1689</t>
     1690<t>
     1691   New transfer-coding value tokens &SHOULD; be registered in the same way
     1692   as new content-coding value tokens (&content-codings;).
     1693</t>
     1694<t>
     1695   A server which receives an entity-body with a transfer-coding it does
     1696   not understand &SHOULD; return 501 (Not Implemented), and close the
     1697   connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.0
     1698   client.
     1699</t>
     1700
     1701<section title="Chunked Transfer Coding" anchor="chunked.transfer.encoding">
     1702  <x:anchor-alias value="chunk"/>
     1703  <x:anchor-alias value="Chunked-Body"/>
     1704  <x:anchor-alias value="chunk-data"/>
     1705  <x:anchor-alias value="chunk-ext"/>
     1706  <x:anchor-alias value="chunk-ext-name"/>
     1707  <x:anchor-alias value="chunk-ext-val"/>
     1708  <x:anchor-alias value="chunk-size"/>
     1709  <x:anchor-alias value="last-chunk"/>
     1710  <x:anchor-alias value="trailer-part"/>
     1711<t>
     1712   The chunked encoding modifies the body of a message in order to
     1713   transfer it as a series of chunks, each with its own size indicator,
     1714   followed by an &OPTIONAL; trailer containing entity-header fields. This
     1715   allows dynamically produced content to be transferred along with the
     1716   information necessary for the recipient to verify that it has
     1717   received the full message.
     1718</t>
     1719<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Chunked-Body"/><iref primary="true" item="Grammar" subitem="chunk"/><iref primary="true" item="Grammar" subitem="chunk-size"/><iref primary="true" item="Grammar" subitem="last-chunk"/><iref primary="true" item="Grammar" subitem="chunk-ext"/><iref primary="true" item="Grammar" subitem="chunk-ext-name"/><iref primary="true" item="Grammar" subitem="chunk-ext-val"/><iref primary="true" item="Grammar" subitem="chunk-data"/><iref primary="true" item="Grammar" subitem="trailer-part"/>
     1720  <x:ref>Chunked-Body</x:ref>   = *<x:ref>chunk</x:ref>
     1721                   <x:ref>last-chunk</x:ref>
     1722                   <x:ref>trailer-part</x:ref>
     1723                   <x:ref>CRLF</x:ref>
     1724 
     1725  <x:ref>chunk</x:ref>          = <x:ref>chunk-size</x:ref> *WSP [ <x:ref>chunk-ext</x:ref> ] <x:ref>CRLF</x:ref>
     1726                   <x:ref>chunk-data</x:ref> <x:ref>CRLF</x:ref>
     1727  <x:ref>chunk-size</x:ref>     = 1*<x:ref>HEXDIG</x:ref>
     1728  <x:ref>last-chunk</x:ref>     = 1*("0") *WSP [ <x:ref>chunk-ext</x:ref> ] <x:ref>CRLF</x:ref>
     1729 
     1730  <x:ref>chunk-ext</x:ref>      = *( ";" *WSP <x:ref>chunk-ext-name</x:ref>
     1731                      [ "=" <x:ref>chunk-ext-val</x:ref> ] *WSP )
     1732  <x:ref>chunk-ext-name</x:ref> = <x:ref>token</x:ref>
     1733  <x:ref>chunk-ext-val</x:ref>  = <x:ref>token</x:ref> / <x:ref>quoted-string</x:ref>
     1734  <x:ref>chunk-data</x:ref>     = 1*<x:ref>OCTET</x:ref> ; a sequence of chunk-size octets
     1735  <x:ref>trailer-part</x:ref>   = *( <x:ref>entity-header</x:ref> <x:ref>CRLF</x:ref> )
     1736</artwork></figure>
     1737<t>
     1738   The chunk-size field is a string of hex digits indicating the size of
     1739   the chunk-data in octets. The chunked encoding is ended by any chunk whose size is
     1740   zero, followed by the trailer, which is terminated by an empty line.
     1741</t>
     1742<t>
     1743   The trailer allows the sender to include additional HTTP header
     1744   fields at the end of the message. The Trailer header field can be
     1745   used to indicate which header fields are included in a trailer (see
     1746   <xref target="header.trailer"/>).
     1747</t>
     1748<t>
     1749   A server using chunked transfer-coding in a response &MUST-NOT; use the
     1750   trailer for any header fields unless at least one of the following is
     1751   true:
     1752  <list style="numbers">
     1753    <t>the request included a TE header field that indicates "trailers" is
     1754     acceptable in the transfer-coding of the  response, as described in
     1755     <xref target="header.te"/>; or,</t>
     1756
     1757    <t>the server is the origin server for the response, the trailer
     1758     fields consist entirely of optional metadata, and the recipient
     1759     could use the message (in a manner acceptable to the origin server)
     1760     without receiving this metadata.  In other words, the origin server
     1761     is willing to accept the possibility that the trailer fields might
     1762     be silently discarded along the path to the client.</t>
     1763  </list>
     1764</t>
     1765<t>
     1766   This requirement prevents an interoperability failure when the
     1767   message is being received by an HTTP/1.1 (or later) proxy and
     1768   forwarded to an HTTP/1.0 recipient. It avoids a situation where
     1769   compliance with the protocol would have necessitated a possibly
     1770   infinite buffer on the proxy.
     1771</t>
     1772<t>
     1773   A process for decoding the "chunked" transfer-coding
     1774   can be represented in pseudo-code as:
     1775</t>
     1776<figure><artwork type="code">
     1777  length := 0
     1778  read chunk-size, chunk-ext (if any) and CRLF
     1779  while (chunk-size &gt; 0) {
     1780     read chunk-data and CRLF
     1781     append chunk-data to entity-body
     1782     length := length + chunk-size
     1783     read chunk-size and CRLF
     1784  }
     1785  read entity-header
     1786  while (entity-header not empty) {
     1787     append entity-header to existing header fields
     1788     read entity-header
     1789  }
     1790  Content-Length := length
     1791  Remove "chunked" from Transfer-Encoding
     1792</artwork></figure>
     1793<t>
     1794   All HTTP/1.1 applications &MUST; be able to receive and decode the
     1795   "chunked" transfer-coding, and &MUST; ignore chunk-ext extensions
     1796   they do not understand.
     1797</t>
     1798</section>
     1799</section>
     1800
     1801<section title="Product Tokens" anchor="product.tokens">
     1802  <x:anchor-alias value="product"/>
     1803  <x:anchor-alias value="product-version"/>
     1804<t>
     1805   Product tokens are used to allow communicating applications to
     1806   identify themselves by software name and version. Most fields using
     1807   product tokens also allow sub-products which form a significant part
     1808   of the application to be listed, separated by whitespace. By
     1809   convention, the products are listed in order of their significance
     1810   for identifying the application.
     1811</t>
     1812<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="product"/><iref primary="true" item="Grammar" subitem="product-version"/>
     1813  <x:ref>product</x:ref>         = <x:ref>token</x:ref> ["/" <x:ref>product-version</x:ref>]
     1814  <x:ref>product-version</x:ref> = <x:ref>token</x:ref>
     1815</artwork></figure>
     1816<t>
     1817   Examples:
     1818</t>
     1819<figure><artwork type="example">
     1820  User-Agent: CERN-LineMode/2.15 libwww/2.17b3
     1821  Server: Apache/0.8.4
     1822</artwork></figure>
     1823<t>
     1824   Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be
     1825   used for advertising or other non-essential information. Although any
     1826   token character &MAY; appear in a product-version, this token &SHOULD;
     1827   only be used for a version identifier (i.e., successive versions of
     1828   the same product &SHOULD; only differ in the product-version portion of
     1829   the product value).
     1830</t>
     1831</section>
     1832
     1833<section title="Quality Values" anchor="quality.values">
     1834  <x:anchor-alias value="qvalue"/>
     1835<t>
     1836   Both transfer codings (TE request header, <xref target="header.te"/>)
     1837   and content negotiation (&content.negotiation;) use short "floating point"
     1838   numbers to indicate the relative importance ("weight") of various
     1839   negotiable parameters.  A weight is normalized to a real number in
     1840   the range 0 through 1, where 0 is the minimum and 1 the maximum
     1841   value. If a parameter has a quality value of 0, then content with
     1842   this parameter is `not acceptable' for the client. HTTP/1.1
     1843   applications &MUST-NOT; generate more than three digits after the
     1844   decimal point. User configuration of these values &SHOULD; also be
     1845   limited in this fashion.
     1846</t>
     1847<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="qvalue"/>
     1848  <x:ref>qvalue</x:ref>         = ( "0" [ "." 0*3<x:ref>DIGIT</x:ref> ] )
     1849                 / ( "1" [ "." 0*3("0") ] )
     1850</artwork></figure>
     1851<x:note>
     1852  <t>
     1853     <x:h>Note:</x:h> "Quality values" is a misnomer, since these values merely represent
     1854     relative degradation in desired quality.
     1855  </t>
     1856</x:note>
     1857</section>
     1858
     1859</section>
    18601860
    18611861<section title="Connections" anchor="connections">
Note: See TracChangeset for help on using the changeset viewer.