Changeset 623
- Timestamp:
- 26/07/09 11:50:23 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r622 r623 835 835 </section> 836 836 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 "<major>.<minor>" numbering scheme to indicate versions844 of the protocol. The protocol versioning policy is intended to allow845 the sender to indicate the format of a message and its capacity for846 understanding further HTTP communication, rather than the features847 obtained via that communication. No change is made to the version848 number for the addition of message components which do not affect849 communication behavior or which only add to extensible field values.850 The <minor> number is incremented when the changes made to the851 protocol add features which do not change the general message parsing852 algorithm, but which may add to the message semantics and imply853 additional capabilities of the sender. The <major> number is854 incremented when the format of a message within the protocol is855 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 field859 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-sensitive864 </artwork></figure>865 <t>866 Note that the major and minor numbers &MUST; be treated as separate867 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 is869 lower than HTTP/12.3. Leading zeros &MUST; be ignored by recipients and870 &MUST-NOT; be sent.871 </t>872 <t>873 An application that sends a request or response message that includes874 HTTP-Version of "HTTP/1.1" &MUST; be at least conditionally compliant875 with this specification. Applications that are at least conditionally876 compliant with this specification &SHOULD; use an HTTP-Version of877 "HTTP/1.1" in their messages, and &MUST; do so for any message that is878 not compatible with HTTP/1.0. For more details on when to send879 specific HTTP-Version values, see <xref target="RFC2145"/>.880 </t>881 <t>882 The HTTP version of an application is the highest HTTP version for883 which the application is at least conditionally compliant.884 </t>885 <t>886 Proxy and gateway applications need to be careful when forwarding887 messages in protocol versions different from that of the application.888 Since the protocol version indicates the protocol capability of the889 sender, a proxy/gateway &MUST-NOT; send a message with a version890 indicator which is greater than its actual version. If a higher891 version request is received, the proxy/gateway &MUST; either downgrade892 the request version, or respond with an error, or switch to tunnel893 behavior.894 </t>895 <t>896 Due to interoperability problems with HTTP/1.0 proxies discovered897 since the publication of <xref target="RFC2068"/>, caching proxies &MUST;, gateways898 &MAY;, and tunnels &MUST-NOT; upgrade the request to the highest version899 they support. The proxy/gateway's response to that request &MUST; be in900 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 modification905 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 formats914 for the representation of date/time stamps:915 </t>916 <figure><artwork type="example">917 Sun, 06 Nov 1994 08:49:37 GMT ; RFC 1123918 Sunday, 06-Nov-94 08:49:37 GMT ; obsolete RFC 850 format919 Sun Nov 6 08:49:37 1994 ; ANSI C's asctime() format920 </artwork></figure>921 <t>922 The first format is preferred as an Internet standard and represents923 a fixed-length subset of that defined by <xref target="RFC1123"/>. The924 other formats are described here only for925 compatibility with obsolete implementations.926 HTTP/1.1 clients and servers that parse the date value &MUST; accept927 all three formats (for compatibility with HTTP/1.0), though they &MUST;928 only generate the RFC 1123 format for representing HTTP-date values929 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 Time933 (GMT), without exception. For the purposes of HTTP, GMT is exactly934 equal to UTC (Coordinated Universal Time). This is indicated in the935 first two formats by the inclusion of "GMT" as the three-letter936 abbreviation for time zone, and &MUST; be assumed when reading the937 asctime format. HTTP-date is case sensitive and &MUST-NOT; include938 additional whitespace beyond that specifically included as SP in the939 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-sensitive961 / <x:abnf-char-sequence>"Tue"</x:abnf-char-sequence> ; "Tue", case-sensitive962 / <x:abnf-char-sequence>"Wed"</x:abnf-char-sequence> ; "Wed", case-sensitive963 / <x:abnf-char-sequence>"Thu"</x:abnf-char-sequence> ; "Thu", case-sensitive964 / <x:abnf-char-sequence>"Fri"</x:abnf-char-sequence> ; "Fri", case-sensitive965 / <x:abnf-char-sequence>"Sat"</x:abnf-char-sequence> ; "Sat", case-sensitive966 / <x:abnf-char-sequence>"Sun"</x:abnf-char-sequence> ; "Sun", case-sensitive967 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 1982970 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-sensitive973 / <x:abnf-char-sequence>"Feb"</x:abnf-char-sequence> ; "Feb", case-sensitive974 / <x:abnf-char-sequence>"Mar"</x:abnf-char-sequence> ; "Mar", case-sensitive975 / <x:abnf-char-sequence>"Apr"</x:abnf-char-sequence> ; "Apr", case-sensitive976 / <x:abnf-char-sequence>"May"</x:abnf-char-sequence> ; "May", case-sensitive977 / <x:abnf-char-sequence>"Jun"</x:abnf-char-sequence> ; "Jun", case-sensitive978 / <x:abnf-char-sequence>"Jul"</x:abnf-char-sequence> ; "Jul", case-sensitive979 / <x:abnf-char-sequence>"Aug"</x:abnf-char-sequence> ; "Aug", case-sensitive980 / <x:abnf-char-sequence>"Sep"</x:abnf-char-sequence> ; "Sep", case-sensitive981 / <x:abnf-char-sequence>"Oct"</x:abnf-char-sequence> ; "Oct", case-sensitive982 / <x:abnf-char-sequence>"Nov"</x:abnf-char-sequence> ; "Nov", case-sensitive983 / <x:abnf-char-sequence>"Dec"</x:abnf-char-sequence> ; "Dec", case-sensitive984 <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-sensitive987 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:59990 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 the998 same as those defined for the RFC 5322 constructs999 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-sensitive1021 / <x:abnf-char-sequence>"Tuesday"</x:abnf-char-sequence> ; "Tuesday", case-sensitive1022 / <x:abnf-char-sequence>"Wednesday"</x:abnf-char-sequence> ; "Wednesday", case-sensitive1023 / <x:abnf-char-sequence>"Thursday"</x:abnf-char-sequence> ; "Thursday", case-sensitive1024 / <x:abnf-char-sequence>"Friday"</x:abnf-char-sequence> ; "Friday", case-sensitive1025 / <x:abnf-char-sequence>"Saturday"</x:abnf-char-sequence> ; "Saturday", case-sensitive1026 / <x:abnf-char-sequence>"Sunday"</x:abnf-char-sequence> ; "Sunday", case-sensitive1027 </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 in1036 accepting date values that may have been sent by non-HTTP1037 applications, as is sometimes the case when retrieving or posting1038 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 only1044 to their usage within the protocol stream. Clients and servers are1045 not required to use these formats for user presentation, request1046 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 encoding1056 transformation that has been, can be, or may need to be applied to an1057 entity-body in order to ensure "safe transport" through the network.1058 This differs from a content coding in that the transfer-coding is a1059 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 uses1078 transfer-coding values in the TE header field (<xref target="header.te"/>) and in1079 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 of1083 transfer-codings &MUST; include "chunked", unless the message indicates it1084 is terminated by closing the connection. When the "chunked" transfer-coding1085 is used, it &MUST; be the last transfer-coding applied to the1086 message-body. The "chunked" transfer-coding &MUST-NOT; be applied more1087 than once to a message-body. These rules allow the recipient to1088 determine the transfer-length of the message (<xref target="message.length"/>).1089 </t>1090 <t>1091 Transfer-codings are analogous to the Content-Transfer-Encoding1092 values of MIME <xref target="RFC2045"/>, which were designed to enable safe transport of1093 binary data over a 7-bit transport service. However, safe transport1094 has a different focus for an 8bit-clean transfer protocol. In HTTP,1095 the only unsafe characteristic of message-bodies is the difficulty in1096 determining the exact body length (<xref target="message.length"/>), or the desire to1097 encrypt data over a shared transport.1098 </t>1099 <t>1100 The Internet Assigned Numbers Authority (IANA) acts as a registry for1101 transfer-coding value tokens. Initially, the registry contains the1102 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 way1107 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 does1111 not understand &SHOULD; return 501 (Not Implemented), and close the1112 connection. A server &MUST-NOT; send transfer-codings to an HTTP/1.01113 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 to1128 transfer it as a series of chunks, each with its own size indicator,1129 followed by an &OPTIONAL; trailer containing entity-header fields. This1130 allows dynamically produced content to be transferred along with the1131 information necessary for the recipient to verify that it has1132 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 octets1150 <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 of1154 the chunk-data in octets. The chunked encoding is ended by any chunk whose size is1155 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 header1159 fields at the end of the message. The Trailer header field can be1160 used to indicate which header fields are included in a trailer (see1161 <xref target="header.trailer"/>).1162 </t>1163 <t>1164 A server using chunked transfer-coding in a response &MUST-NOT; use the1165 trailer for any header fields unless at least one of the following is1166 true:1167 <list style="numbers">1168 <t>the request included a TE header field that indicates "trailers" is1169 acceptable in the transfer-coding of the response, as described in1170 <xref target="header.te"/>; or,</t>1171 1172 <t>the server is the origin server for the response, the trailer1173 fields consist entirely of optional metadata, and the recipient1174 could use the message (in a manner acceptable to the origin server)1175 without receiving this metadata. In other words, the origin server1176 is willing to accept the possibility that the trailer fields might1177 be silently discarded along the path to the client.</t>1178 </list>1179 </t>1180 <t>1181 This requirement prevents an interoperability failure when the1182 message is being received by an HTTP/1.1 (or later) proxy and1183 forwarded to an HTTP/1.0 recipient. It avoids a situation where1184 compliance with the protocol would have necessitated a possibly1185 infinite buffer on the proxy.1186 </t>1187 <t>1188 A process for decoding the "chunked" transfer-coding1189 can be represented in pseudo-code as:1190 </t>1191 <figure><artwork type="code">1192 length := 01193 read chunk-size, chunk-ext (if any) and CRLF1194 while (chunk-size > 0) {1195 read chunk-data and CRLF1196 append chunk-data to entity-body1197 length := length + chunk-size1198 read chunk-size and CRLF1199 }1200 read entity-header1201 while (entity-header not empty) {1202 append entity-header to existing header fields1203 read entity-header1204 }1205 Content-Length := length1206 Remove "chunked" from Transfer-Encoding1207 </artwork></figure>1208 <t>1209 All HTTP/1.1 applications &MUST; be able to receive and decode the1210 "chunked" transfer-coding, and &MUST; ignore chunk-ext extensions1211 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 to1221 identify themselves by software name and version. Most fields using1222 product tokens also allow sub-products which form a significant part1223 of the application to be listed, separated by whitespace. By1224 convention, the products are listed in order of their significance1225 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.17b31236 Server: Apache/0.8.41237 </artwork></figure>1238 <t>1239 Product tokens &SHOULD; be short and to the point. They &MUST-NOT; be1240 used for advertising or other non-essential information. Although any1241 token character &MAY; appear in a product-version, this token &SHOULD;1242 only be used for a version identifier (i.e., successive versions of1243 the same product &SHOULD; only differ in the product-version portion of1244 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 various1254 negotiable parameters. A weight is normalized to a real number in1255 the range 0 through 1, where 0 is the minimum and 1 the maximum1256 value. If a parameter has a quality value of 0, then content with1257 this parameter is `not acceptable' for the client. HTTP/1.11258 applications &MUST-NOT; generate more than three digits after the1259 decimal point. User configuration of these values &SHOULD; also be1260 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 represent1269 relative degradation in desired quality.1270 </t>1271 </x:note>1272 </section>1273 1274 </section>1275 1276 837 <section title="HTTP Message" anchor="http.message"> 1277 838 … … 1858 1419 </section> 1859 1420 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 "<major>.<minor>" 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 <minor> 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 <major> 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 > 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> 1860 1860 1861 1861 <section title="Connections" anchor="connections">
Note: See TracChangeset
for help on using the changeset viewer.