Changeset 563 for draft-ietf-httpbis/latest
- Timestamp:
- 24/03/09 20:48:26 (13 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 10 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r560 r563 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">March 12, 2009</td>473 <td class="header right">March 24, 2009</td> 474 474 </tr> 475 475 </table> … … 845 845 <p id="rfc.section.2.1.2.p.1"> <span class="comment" id="rfc.comment.1">[<a href="#rfc.comment.1" class="smpl">rfc.comment.1</a>: TBD: Define and explain purpose of https scheme.]</span> 846 846 </p> 847 <d l class="empty">848 < dd> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>.849 </ dd>850 </d l>847 <div class="note"> 848 <p> <b>Note:</b> the "https" scheme is defined in <a href="#RFC2818" id="rfc.xref.RFC2818.1"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. 849 </p> 850 </div> 851 851 <h3 id="rfc.section.2.1.3"><a href="#rfc.section.2.1.3">2.1.3</a> <a id="uri.comparison" href="#uri.comparison">URI Comparison</a></h3> 852 852 <p id="rfc.section.2.1.3.p.1">When comparing two URIs to decide if they match or not, a client <em class="bcp14">SHOULD</em> use a case-sensitive octet-by-octet comparison of the entire URIs, with these exceptions: … … 965 965 <p id="rfc.section.3.1.p.8">Due to interoperability problems with HTTP/1.0 proxies discovered since the publication of <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, caching proxies <em class="bcp14">MUST</em>, gateways <em class="bcp14">MAY</em>, and tunnels <em class="bcp14">MUST NOT</em> upgrade the request to the highest version they support. The proxy/gateway's response to that request <em class="bcp14">MUST</em> be in the same major version as the request. 966 966 </p> 967 <p id="rfc.section.3.1.p.9"> </p> 968 <dl class="empty"> 969 <dd> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved. 970 </dd> 971 </dl> 967 <div class="note"> 968 <p> <b>Note:</b> Converting between versions of HTTP may involve modification of header fields required or forbidden by the versions involved. 969 </p> 970 </div> 972 971 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="date.time.formats" href="#date.time.formats">Date/Time Formats</a></h2> 973 972 <h3 id="rfc.section.3.2.1"><a href="#rfc.section.3.2.1">3.2.1</a> <a id="full.date" href="#full.date">Full Date</a></h3> … … 979 978 that parse the date value <em class="bcp14">MUST</em> accept all three formats (for compatibility with HTTP/1.0), though they <em class="bcp14">MUST</em> only generate the RFC 1123 format for representing HTTP-date values in header fields. See <a href="#tolerant.applications" title="Tolerant Applications">Appendix A</a> for further information. 980 979 </p> 981 <d l class="empty">982 < dd> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications,980 <div class="note"> 981 <p> <b>Note:</b> Recipients of date values are encouraged to be robust in accepting date values that may have been sent by non-HTTP applications, 983 982 as is sometimes the case when retrieving or posting messages via proxies/gateways to SMTP or NNTP. 984 </ dd>985 </d l>983 </p> 984 </div> 986 985 <p id="rfc.section.3.2.1.p.5">All HTTP date/time stamps <em class="bcp14">MUST</em> be represented in Greenwich Mean Time (GMT), without exception. For the purposes of HTTP, GMT is exactly equal to UTC (Coordinated 987 986 Universal Time). This is indicated in the first two formats by the inclusion of "GMT" as the three-letter abbreviation for … … 1219 1218 thus a proxy <em class="bcp14">MUST NOT</em> change the order of these field values when a message is forwarded. 1220 1219 </p> 1221 <p id="rfc.section.4.2.p.11"> </p> 1222 <dl class="empty"> 1223 <dd> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix 1220 <div class="note"> 1221 <p> <b>Note:</b> the "Set-Cookie" header as implemented in practice (as opposed to how it is specified in <a href="#RFC2109" id="rfc.xref.RFC2109.1"><cite title="HTTP State Management Mechanism">[RFC2109]</cite></a>) can occur multiple times, but does not use the list syntax, and thus cannot be combined into a single line. (See Appendix 1224 1222 A.2.3 of <a href="#Kri2001" id="rfc.xref.Kri2001.1"><cite title="HTTP Cookies: Standards, Privacy, and Politics">[Kri2001]</cite></a> for details.) Also note that the Set-Cookie2 header specified in <a href="#RFC2965" id="rfc.xref.RFC2965.1"><cite title="HTTP State Management Mechanism">[RFC2965]</cite></a> does not share this problem. 1225 </ dd>1226 </d l>1223 </p> 1224 </div> 1227 1225 <h2 id="rfc.section.4.3"><a href="#rfc.section.4.3">4.3</a> <a id="message.body" href="#message.body">Message Body</a></h2> 1228 1226 <p id="rfc.section.4.3.p.1">The message-body (if any) of an HTTP message is used to carry the entity-body associated with the request or response. The … … 1373 1371 above to replace a null path-absolute with "/". 1374 1372 </p> 1375 <p id="rfc.section.5.1.2.p.17"> </p> 1376 <dl class="empty"> 1377 <dd> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1373 <div class="note"> 1374 <p> <b>Note:</b> The "no rewrite" rule prevents the proxy from changing the meaning of the request when the origin server is improperly using 1378 1375 a non-reserved URI character for a reserved purpose. Implementors should be aware that some pre-HTTP/1.1 proxies have been 1379 1376 known to rewrite the request-target. 1380 </ dd>1381 </d l>1377 </p> 1378 </div> 1382 1379 <p id="rfc.section.5.1.2.p.18">HTTP does not place a pre-defined limit on the length of a request-target. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status if the received request-target 1383 1380 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 8.4.15</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). -
draft-ietf-httpbis/latest/p1-messaging.xml
r547 r563 592 592 <cref>TBD: Define and explain purpose of https scheme.</cref> 593 593 </t> 594 <t><list><t> 595 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>. 596 </t></list></t> 594 <x:note> 595 <t> 596 <x:h>Note:</x:h> the "https" scheme is defined in <xref target="RFC2818"/>. 597 </t> 598 </x:note> 597 599 </section> 598 600 … … 825 827 the same major version as the request. 826 828 </t> 827 <t> 828 <list> 829 <t> 830 <x:h>Note:</x:h> Converting between versions of HTTP may involve modification 831 of header fields required or forbidden by the versions involved. 832 </t> 833 </list> 834 </t> 829 <x:note> 830 <t> 831 <x:h>Note:</x:h> Converting between versions of HTTP may involve modification 832 of header fields required or forbidden by the versions involved. 833 </t> 834 </x:note> 835 835 </section> 836 836 … … 869 869 in header fields. See <xref target="tolerant.applications"/> for further information. 870 870 </t> 871 <t><list><t> 872 <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in 873 accepting date values that may have been sent by non-HTTP 874 applications, as is sometimes the case when retrieving or posting 875 messages via proxies/gateways to SMTP or NNTP. 876 </t></list></t> 871 <x:note> 872 <t> 873 <x:h>Note:</x:h> Recipients of date values are encouraged to be robust in 874 accepting date values that may have been sent by non-HTTP 875 applications, as is sometimes the case when retrieving or posting 876 messages via proxies/gateways to SMTP or NNTP. 877 </t> 878 </x:note> 877 879 <t> 878 880 All HTTP date/time stamps &MUST; be represented in Greenwich Mean Time … … 1308 1310 change the order of these field values when a message is forwarded. 1309 1311 </t> 1310 < t>1311 < list><t>1312 <x:note> 1313 <t> 1312 1314 <x:h>Note:</x:h> the "Set-Cookie" header as implemented in 1313 1315 practice (as opposed to how it is specified in <xref target="RFC2109"/>) … … 1316 1318 for details.) Also note that the Set-Cookie2 header specified in 1317 1319 <xref target="RFC2965"/> does not share this problem. 1318 </t> </list>1319 </ t>1320 </t> 1321 </x:note> 1320 1322 1321 1323 </section> … … 1621 1623 except as noted above to replace a null path-absolute with "/". 1622 1624 </t> 1623 < t>1624 < list><t>1625 1626 1627 1628 1629 1630 </t> </list>1631 </ t>1625 <x:note> 1626 <t> 1627 <x:h>Note:</x:h> The "no rewrite" rule prevents the proxy from changing the 1628 meaning of the request when the origin server is improperly using 1629 a non-reserved URI character for a reserved purpose. Implementors 1630 should be aware that some pre-HTTP/1.1 proxies have been known to 1631 rewrite the request-target. 1632 </t> 1633 </x:note> 1632 1634 <t> 1633 1635 HTTP does not place a pre-defined limit on the length of a request-target. -
draft-ietf-httpbis/latest/p2-semantics.html
r560 r563 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 468 471 <tr> 469 472 <td class="header left"></td> 470 <td class="header right">March 12, 2009</td>473 <td class="header right">March 24, 2009</td> 471 474 </tr> 472 475 </table> … … 1166 1169 <p id="rfc.section.8.3.p.1">This class of status code indicates that further action needs to be taken by the user agent in order to fulfill the request. 1167 1170 The action required <em class="bcp14">MAY</em> be carried out by the user agent without interaction with the user if and only if the method used in the second request is 1168 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 1169 </p> 1170 <d l class="empty">1171 < dd> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that1171 GET or HEAD. A client <em class="bcp14">SHOULD</em> detect infinite redirection loops, since such loops generate network traffic for each redirection. 1172 </p> 1173 <div class="note"> 1174 <p> <b>Note:</b> previous versions of this specification recommended a maximum of five redirections. Content developers should be aware that 1172 1175 there might be clients that implement such a fixed limitation. 1173 </ dd>1174 </d l>1176 </p> 1177 </div> 1175 1178 <div id="rfc.iref.34"></div> 1176 1179 <div id="rfc.iref.s.11"></div> … … 1195 1198 </p> 1196 1199 <p id="rfc.section.8.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1197 the request was issued. 1198 </p> 1199 <d l class="empty">1200 < dd> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously1200 the request was issued. 1201 </p> 1202 <div class="note"> 1203 <p> <b>Note:</b> When automatically redirecting a POST request after receiving a 301 status code, some existing HTTP/1.0 user agents will erroneously 1201 1204 change it into a GET request. 1202 </ dd>1203 </d l>1205 </p> 1206 </div> 1204 1207 <div id="rfc.iref.36"></div> 1205 1208 <div id="rfc.iref.s.13"></div> … … 1212 1215 </p> 1213 1216 <p id="rfc.section.8.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section 7.1.1</a>, then the request <em class="bcp14">MAY</em> be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which 1214 the request was issued. 1215 </p> 1216 <d l class="empty">1217 < dd> <b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations1217 the request was issued. 1218 </p> 1219 <div class="note"> 1220 <p> <b>Note:</b> <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a> and <a href="#RFC2068" id="rfc.xref.RFC2068.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a> specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations 1218 1221 treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method. 1219 1222 The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected 1220 1223 of the client. 1221 </ dd>1222 </d l>1224 </p> 1225 </div> 1223 1226 <div id="rfc.iref.37"></div> 1224 1227 <div id="rfc.iref.s.14"></div> … … 1321 1324 <p id="rfc.section.8.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include an entity containing a list of available entity characteristics and location(s) from which the user or user agent 1322 1325 can choose the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. 1323 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1324 </p> 1325 <d l class="empty">1326 < dd> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request.1326 Depending upon the format and the capabilities of the user agent, selection of the most appropriate choice <em class="bcp14">MAY</em> be performed automatically. However, this specification does not define any standard for such automatic selection. 1327 </p> 1328 <div class="note"> 1329 <p> <b>Note:</b> HTTP/1.1 servers are allowed to return responses which are not acceptable according to the accept headers sent in the request. 1327 1330 In some cases, this may even be preferable to sending a 406 response. User agents are encouraged to inspect the headers of 1328 1331 an incoming response to determine if it is acceptable. 1329 </ dd>1330 </d l>1331 <p id="rfc.section.8.4.7.p. 3">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions.1332 </p> 1333 </div> 1334 <p id="rfc.section.8.4.7.p.4">If the response could be unacceptable, a user agent <em class="bcp14">SHOULD</em> temporarily stop receipt of more data and query the user for a decision on further actions. 1332 1335 </p> 1333 1336 <div id="rfc.iref.49"></div> … … 1438 1441 <h3 id="rfc.section.8.5.4"><a href="#rfc.section.8.5.4">8.5.4</a> <a id="status.503" href="#status.503">503 Service Unavailable</a></h3> 1439 1442 <p id="rfc.section.8.5.4.p.1">The server is currently unable to handle the request due to a temporary overloading or maintenance of the server. The implication 1440 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1441 </p> 1442 <d l class="empty">1443 < dd> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish1443 is that this is a temporary condition which will be alleviated after some delay. If known, the length of the delay <em class="bcp14">MAY</em> be indicated in a Retry-After header. If no Retry-After is given, the client <em class="bcp14">SHOULD</em> handle the response as it would for a 500 response. 1444 </p> 1445 <div class="note"> 1446 <p> <b>Note:</b> The existence of the 503 status code does not imply that a server must use it when becoming overloaded. Some servers may wish 1444 1447 to simply refuse the connection. 1445 </ dd>1446 </d l>1448 </p> 1449 </div> 1447 1450 <div id="rfc.iref.64"></div> 1448 1451 <div id="rfc.iref.s.41"></div> 1449 1452 <h3 id="rfc.section.8.5.5"><a href="#rfc.section.8.5.5">8.5.5</a> <a id="status.504" href="#status.504">504 Gateway Timeout</a></h3> 1450 1453 <p id="rfc.section.8.5.5.p.1">The server, while acting as a gateway or proxy, did not receive a timely response from the upstream server specified by the 1451 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 1452 </p> 1453 <d l class="empty">1454 < dd> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out.1455 </ dd>1456 </d l>1454 URI (e.g. HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed to access in attempting to complete the request. 1455 </p> 1456 <div class="note"> 1457 <p> <b>Note:</b> Note to implementors: some deployed proxies are known to return 400 or 500 when DNS lookups time out. 1458 </p> 1459 </div> 1457 1460 <div id="rfc.iref.65"></div> 1458 1461 <div id="rfc.iref.s.42"></div> … … 1542 1545 </pre><p id="rfc.section.9.4.p.3">An example is:</p> 1543 1546 <div id="rfc.figure.u.18"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html 1544 </pre><p id="rfc.section.9.4.p.5"> </p> 1545 <dl class="empty"> 1546 <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. 1547 </pre><div class="note"> 1548 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the response. 1547 1549 It is therefore possible for a response to contain header fields for both Location and Content-Location. 1548 </ dd>1549 </d l>1550 </p> 1551 </div> 1550 1552 <p id="rfc.section.9.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p> 1551 1553 <ul> … … 1614 1616 </pre><p id="rfc.section.9.8.p.3">Example:</p> 1615 1617 <div id="rfc.figure.u.26"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 1616 </pre><p id="rfc.section.9.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1617 </p> 1618 <d l class="empty">1619 < dd> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks1618 </pre><p id="rfc.section.9.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.26"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 1619 </p> 1620 <div class="note"> 1621 <p> <b>Note:</b> Revealing the specific software version of the server might allow the server machine to become more vulnerable to attacks 1620 1622 against software that is known to contain security holes. Server implementors are encouraged to make this field a configurable 1621 1623 option. 1622 </ dd>1623 </d l>1624 </p> 1625 </div> 1624 1626 <div id="rfc.iref.u.1"></div> 1625 1627 <div id="rfc.iref.h.10"></div> -
draft-ietf-httpbis/latest/p2-semantics.xml
r547 r563 1244 1244 GET or HEAD. A client &SHOULD; detect infinite redirection loops, since 1245 1245 such loops generate network traffic for each redirection. 1246 <list><t> 1247 <x:h>Note:</x:h> previous versions of this specification recommended a 1248 maximum of five redirections. Content developers should be aware 1249 that there might be clients that implement such a fixed 1250 limitation. 1251 </t></list> 1252 </t> 1246 </t> 1247 <x:note> 1248 <t> 1249 <x:h>Note:</x:h> previous versions of this specification recommended a 1250 maximum of five redirections. Content developers should be aware 1251 that there might be clients that implement such a fixed 1252 limitation. 1253 </t> 1254 </x:note> 1253 1255 1254 1256 <section title="300 Multiple Choices" anchor="status.300"> … … 1304 1306 request unless it can be confirmed by the user, since this might 1305 1307 change the conditions under which the request was issued. 1306 <list><t> 1307 <x:h>Note:</x:h> When automatically redirecting a POST request after 1308 receiving a 301 status code, some existing HTTP/1.0 user agents 1309 will erroneously change it into a GET request. 1310 </t></list> 1311 </t> 1308 </t> 1309 <x:note> 1310 <t> 1311 <x:h>Note:</x:h> When automatically redirecting a POST request after 1312 receiving a 301 status code, some existing HTTP/1.0 user agents 1313 will erroneously change it into a GET request. 1314 </t> 1315 </x:note> 1312 1316 </section> 1313 1317 … … 1335 1339 request unless it can be confirmed by the user, since this might 1336 1340 change the conditions under which the request was issued. 1337 <list><t> 1338 <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed 1339 to change the method on the redirected request. However, most 1340 existing user agent implementations treat 302 as if it were a 303 1341 response, performing a GET on the Location field-value regardless 1342 of the original request method. The status codes 303 and 307 have 1343 been added for servers that wish to make unambiguously clear which 1344 kind of reaction is expected of the client. 1345 </t></list> 1346 </t> 1341 </t> 1342 <x:note> 1343 <t> 1344 <x:h>Note:</x:h> <xref target="RFC1945"/> and <xref target="RFC2068"/> specify that the client is not allowed 1345 to change the method on the redirected request. However, most 1346 existing user agent implementations treat 302 as if it were a 303 1347 response, performing a GET on the Location field-value regardless 1348 of the original request method. The status codes 303 and 307 have 1349 been added for servers that wish to make unambiguously clear which 1350 kind of reaction is expected of the client. 1351 </t> 1352 </x:note> 1347 1353 </section> 1348 1354 … … 1546 1552 choice &MAY; be performed automatically. However, this specification 1547 1553 does not define any standard for such automatic selection. 1548 <list><t> 1549 <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are 1550 not acceptable according to the accept headers sent in the 1551 request. In some cases, this may even be preferable to sending a 1552 406 response. User agents are encouraged to inspect the headers of 1553 an incoming response to determine if it is acceptable. 1554 </t></list> 1555 </t> 1554 </t> 1555 <x:note> 1556 <t> 1557 <x:h>Note:</x:h> HTTP/1.1 servers are allowed to return responses which are 1558 not acceptable according to the accept headers sent in the 1559 request. In some cases, this may even be preferable to sending a 1560 406 response. User agents are encouraged to inspect the headers of 1561 an incoming response to determine if it is acceptable. 1562 </t> 1563 </x:note> 1556 1564 <t> 1557 1565 If the response could be unacceptable, a user agent &SHOULD; … … 1766 1774 Retry-After header. If no Retry-After is given, the client &SHOULD; 1767 1775 handle the response as it would for a 500 response. 1768 <list><t> 1769 <x:h>Note:</x:h> The existence of the 503 status code does not imply that a 1770 server must use it when becoming overloaded. Some servers may wish 1771 to simply refuse the connection. 1772 </t></list> 1773 </t> 1776 </t> 1777 <x:note> 1778 <t> 1779 <x:h>Note:</x:h> The existence of the 503 status code does not imply that a 1780 server must use it when becoming overloaded. Some servers may wish 1781 to simply refuse the connection. 1782 </t> 1783 </x:note> 1774 1784 </section> 1775 1785 … … 1782 1792 HTTP, FTP, LDAP) or some other auxiliary server (e.g. DNS) it needed 1783 1793 to access in attempting to complete the request. 1784 <list><t> 1785 <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to 1786 return 400 or 500 when DNS lookups time out. 1787 </t></list> 1788 </t> 1794 </t> 1795 <x:note> 1796 <t> 1797 <x:h>Note:</x:h> Note to implementors: some deployed proxies are known to 1798 return 400 or 500 when DNS lookups time out. 1799 </t> 1800 </x:note> 1789 1801 </section> 1790 1802 … … 1979 1991 Location: http://www.example.org/pub/WWW/People.html 1980 1992 </artwork></figure> 1981 < t>1982 < list><t>1983 1984 1985 1986 1987 1988 </t> </list>1989 </ t>1993 <x:note> 1994 <t> 1995 <x:h>Note:</x:h> The Content-Location header field (&header-content-location;) differs 1996 from Location in that the Content-Location identifies the original 1997 location of the entity enclosed in the response. It is therefore 1998 possible for a response to contain header fields for both Location 1999 and Content-Location. 2000 </t> 2001 </x:note> 1990 2002 <t> 1991 2003 There are circumstances in which a fragment identifier in a Location URL would not be appropriate: … … 2134 2146 application &MUST-NOT; modify the Server response-header. Instead, it 2135 2147 &MUST; include a Via field (as described in &header-via;). 2136 <list><t> 2137 <x:h>Note:</x:h> Revealing the specific software version of the server might 2138 allow the server machine to become more vulnerable to attacks 2139 against software that is known to contain security holes. Server 2140 implementors are encouraged to make this field a configurable 2141 option. 2142 </t></list> 2143 </t> 2148 </t> 2149 <x:note> 2150 <t> 2151 <x:h>Note:</x:h> Revealing the specific software version of the server might 2152 allow the server machine to become more vulnerable to attacks 2153 against software that is known to contain security holes. Server 2154 implementors are encouraged to make this field a configurable 2155 option. 2156 </t> 2157 </x:note> 2144 2158 </section> 2145 2159 -
draft-ietf-httpbis/latest/p3-payload.html
r560 r563 36 36 cite { 37 37 font-style: normal; 38 } 39 div.note { 40 margin-left: 2em; 38 41 } 39 42 dd { … … 475 478 <tr> 476 479 <td class="header left"></td> 477 <td class="header right">March 12, 2009</td>480 <td class="header right">March 24, 2009</td> 478 481 </tr> 479 482 </table> … … 670 673 to determine the exact mapping is not permitted. 671 674 </p> 672 <d l class="empty">673 < dd> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME675 <div class="note"> 676 <p> <b>Note:</b> This use of the term "character set" is more commonly referred to as a "character encoding." However, since HTTP and MIME 674 677 share the same registry, it is important that the terminology also be shared. 675 </ dd>676 </d l>678 </p> 679 </div> 677 680 <div id="rule.charset"> 678 681 <p id="rfc.section.2.1.p.4"> HTTP character sets are identified by case-insensitive tokens. The complete set of tokens is defined by the IANA Character … … 800 803 an unrecognized multipart subtype, the application <em class="bcp14">MUST</em> treat it as being equivalent to "multipart/mixed". 801 804 </p> 802 <d l class="empty">803 < dd> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request805 <div class="note"> 806 <p> <b>Note:</b> The "multipart/form-data" type has been specifically defined for carrying form data suitable for processing via the POST request 804 807 method, as described in <a href="#RFC2388" id="rfc.xref.RFC2388.1"><cite title="Returning Values from Forms: multipart/form-data">[RFC2388]</cite></a>. 805 </ dd>806 </d l>808 </p> 809 </div> 807 810 <h2 id="rfc.section.2.4"><a href="#rfc.section.2.4">2.4</a> <a id="language.tags" href="#language.tags">Language Tags</a></h2> 808 811 <p id="rfc.section.2.4.p.1">A language tag identifies a natural language spoken, written, or otherwise conveyed by human beings for communication of information … … 876 879 all users have the same preferences for what is "best," and not all user agents are equally capable of rendering all entity 877 880 types. For that reason, HTTP has provisions for several mechanisms for "content negotiation" -- the process of selecting the 878 best representation for a given response when there are multiple representations available. 879 </p> 880 <d l class="empty">881 < dd> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different881 best representation for a given response when there are multiple representations available. 882 </p> 883 <div class="note"> 884 <p> <b>Note:</b> This is not called "format negotiation" because the alternate representations may be of the same media type, but use different 882 885 capabilities of that type, be in different languages, etc. 883 </ dd>884 </d l>885 <p id="rfc.section.4.p. 2">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses.886 </p> 887 <p id="rfc.section.4.p. 3">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two886 </p> 887 </div> 888 <p id="rfc.section.4.p.3">Any response containing an entity-body <em class="bcp14">MAY</em> be subject to negotiation, including error responses. 889 </p> 890 <p id="rfc.section.4.p.4">There are two kinds of content negotiation which are possible in HTTP: server-driven and agent-driven negotiation. These two 888 891 kinds of negotiation are orthogonal and thus may be used separately or in combination. One method of combination, referred 889 892 to as transparent negotiation, occurs when a cache uses the agent-driven negotiation information provided by the origin server … … 978 981 <p id="rfc.section.5.1.p.4">Each media-range <em class="bcp14">MAY</em> be followed by one or more accept-params, beginning with the "q" parameter for indicating a relative quality factor. The first 979 982 "q" parameter (if any) separates the media-range parameter(s) from the accept-params. Quality factors allow the user or user 980 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 981 </p> 982 <d l class="empty">983 < dd> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice.983 agent to indicate the relative degree of preference for that media-range, using the qvalue scale from 0 to 1 (<a href="p1-messaging.html#quality.values" title="Quality Values">Section 3.5</a> of <a href="#Part1" id="rfc.xref.Part1.14"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). The default value is q=1. 984 </p> 985 <div class="note"> 986 <p> <b>Note:</b> Use of the "q" parameter name to separate media type parameters from Accept extension parameters is due to historical practice. 984 987 Although this prevents any media type parameter named "q" from being used with a media range, such an event is believed to 985 988 be unlikely given the lack of any "q" parameters in the IANA media type registry and the rare usage of any media type parameters 986 989 in Accept. Future media types are discouraged from registering any parameter named "q". 987 </ dd>988 </d l>989 <p id="rfc.section.5.1.p. 5">The example</p>990 </p> 991 </div> 992 <p id="rfc.section.5.1.p.6">The example</p> 990 993 <div id="rfc.figure.u.16"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 991 </pre><p id="rfc.section.5.1.p. 7"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in994 </pre><p id="rfc.section.5.1.p.8"> <em class="bcp14">SHOULD</em> be interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 992 995 quality." 993 996 </p> 994 <p id="rfc.section.5.1.p. 8">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field997 <p id="rfc.section.5.1.p.9">If no Accept header field is present, then it is assumed that the client accepts all media types. If an Accept header field 995 998 is present, and if the server cannot send a response which is acceptable according to the combined Accept field value, then 996 999 the server <em class="bcp14">SHOULD</em> send a 406 (Not Acceptable) response. 997 1000 </p> 998 <p id="rfc.section.5.1.p. 9">A more elaborate example is</p>1001 <p id="rfc.section.5.1.p.10">A more elaborate example is</p> 999 1002 <div id="rfc.figure.u.17"></div><pre class="text"> Accept: text/plain; q=0.5, text/html, 1000 1003 text/x-dvi; q=0.8, text/x-c 1001 </pre><p id="rfc.section.5.1.p.1 1">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then1004 </pre><p id="rfc.section.5.1.p.12">Verbally, this would be interpreted as "text/html and text/x-c are the preferred media types, but if they do not exist, then 1002 1005 send the text/x-dvi entity, and if that does not exist, send the text/plain entity." 1003 1006 </p> 1004 <p id="rfc.section.5.1.p.1 2">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies1007 <p id="rfc.section.5.1.p.13">Media ranges can be overridden by more specific media ranges or specific media types. If more than one media range applies 1005 1008 to a given type, the most specific reference has precedence. For example, 1006 1009 </p> 1007 1010 <div id="rfc.figure.u.18"></div><pre class="text"> Accept: text/*, text/html, text/html;level=1, */* 1008 </pre><p id="rfc.section.5.1.p.1 4">have the following precedence: </p>1011 </pre><p id="rfc.section.5.1.p.15">have the following precedence: </p> 1009 1012 <ol> 1010 1013 <li>text/html;level=1</li> … … 1013 1016 <li>*/*</li> 1014 1017 </ol> 1015 <p id="rfc.section.5.1.p.1 5">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence1018 <p id="rfc.section.5.1.p.16">The media type quality factor associated with a given type is determined by finding the media range with the highest precedence 1016 1019 which matches that type. For example, 1017 1020 </p> 1018 1021 <div id="rfc.figure.u.19"></div><pre class="text"> Accept: text/*;q=0.3, text/html;q=0.7, text/html;level=1, 1019 1022 text/html;level=2;q=0.4, */*;q=0.5 1020 </pre><p id="rfc.section.5.1.p.1 7">would cause the following values to be associated:</p>1023 </pre><p id="rfc.section.5.1.p.18">would cause the following values to be associated:</p> 1021 1024 <div id="rfc.table.u.1"> 1022 1025 <table summary="" class="tt full" cellpadding="3" cellspacing="0"> … … 1055 1058 </table> 1056 1059 </div> 1057 <p id="rfc.section.5.1.p.1 8"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent1060 <p id="rfc.section.5.1.p.19"> <b>Note:</b> A user agent might be provided with a default set of quality values for certain media ranges. However, unless the user agent 1058 1061 is a closed system which cannot interact with other rendering agents, this default set ought to be configurable by the user. 1059 1062 </p> … … 1118 1121 <p id="rfc.section.5.3.p.8">If no Accept-Encoding field is present in a request, the server <em class="bcp14">MAY</em> assume that the client will accept any content coding. In this case, if "identity" is one of the available content-codings, 1119 1122 then the server <em class="bcp14">SHOULD</em> use the "identity" content-coding, unless it has additional information that a different content-coding is meaningful to the 1120 client. 1121 </p> 1122 <d l class="empty">1123 < dd> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings1123 client. 1124 </p> 1125 <div class="note"> 1126 <p> <b>Note:</b> If the request does not include an Accept-Encoding field, and if the "identity" content-coding is unavailable, then content-codings 1124 1127 commonly understood by HTTP/1.0 clients (i.e., "gzip" and "compress") are preferred; some older clients improperly display 1125 1128 messages sent with other content-codings. The server might also make this decision based on information about the particular 1126 1129 user-agent or client. 1127 </dd> 1128 <dd> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 1130 </p> 1131 </div> 1132 <div class="note"> 1133 <p> <b>Note:</b> Most HTTP/1.0 applications do not recognize or obey qvalues associated with content-codings. This means that qvalues will 1129 1134 not work and are not permitted with x-gzip or x-compress. 1130 </ dd>1131 </d l>1135 </p> 1136 </div> 1132 1137 <div id="rfc.iref.a.4"></div> 1133 1138 <div id="rfc.iref.h.4"></div> … … 1155 1160 </blockquote> 1156 1161 <p id="rfc.section.5.4.p.8">The special range "*", if present in the Accept-Language field, matches every tag not matched by any other range present in 1157 the Accept-Language field. 1158 </p> 1159 <d l class="empty">1160 < dd> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always1162 the Accept-Language field. 1163 </p> 1164 <div class="note"> 1165 <p> <b>Note:</b> This use of a prefix matching rule does not imply that language tags are assigned to languages in such a way that it is always 1161 1166 true that if a user understands a language with a certain tag, then this user will also understand all languages with tags 1162 1167 for which this tag is a prefix. The prefix rule simply allows the use of prefix tags if this is the case. 1163 </ dd>1164 </d l>1165 <p id="rfc.section.5.4.p. 9">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range1168 </p> 1169 </div> 1170 <p id="rfc.section.5.4.p.10">The language quality factor assigned to a language-tag by the Accept-Language field is the quality value of the longest language-range 1166 1171 in the field that matches the language-tag. If no language-range in the field matches the tag, the language quality factor 1167 1172 assigned is 0. If no Accept-Language header is present in the request, the server <em class="bcp14">SHOULD</em> assume that all languages are equally acceptable. If an Accept-Language header is present, then all languages which are assigned 1168 1173 a quality factor greater than 0 are acceptable. 1169 1174 </p> 1170 <p id="rfc.section.5.4.p.1 0">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic1175 <p id="rfc.section.5.4.p.11">It might be contrary to the privacy expectations of the user to send an Accept-Language header with the complete linguistic 1171 1176 preferences of the user in every request. For a discussion of this issue, see <a href="#privacy.issues.connected.to.accept.headers" title="Privacy Issues Connected to Accept Headers">Section 7.1</a>. 1172 1177 </p> 1173 <p id="rfc.section.5.4.p.1 1">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice1174 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 1175 </p> 1176 <d l class="empty">1177 < dd> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not1178 <p id="rfc.section.5.4.p.12">As intelligibility is highly dependent on the individual user, it is recommended that client applications make the choice 1179 of linguistic preference available to the user. If the choice is not made available, then the Accept-Language header field <em class="bcp14">MUST NOT</em> be given in the request. 1180 </p> 1181 <div class="note"> 1182 <p> <b>Note:</b> When making the choice of linguistic preference available to the user, we remind implementors of the fact that users are not 1178 1183 familiar with the details of language matching as described above, and should provide appropriate guidance. As an example, 1179 1184 users might assume that on selecting "en-gb", they will be served any kind of English document if British English is not available. 1180 1185 A user agent might suggest in such a case to add "en" to get the best matching behavior. 1181 </ dd>1182 </d l>1186 </p> 1187 </div> 1183 1188 <div id="rfc.iref.c.2"></div> 1184 1189 <div id="rfc.iref.h.5"></div> … … 1279 1284 The Transfer-Encoding header field is not allowed within body-parts. 1280 1285 </p> 1281 <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1282 </p> 1283 <d l class="empty">1284 < dd> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several1286 <p id="rfc.section.5.8.p.8">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. 1287 </p> 1288 <div class="note"> 1289 <p> <b>Note:</b> while the definition of Content-MD5 is exactly the same for HTTP as in RFC 1864 for MIME entity-bodies, there are several 1285 1290 ways in which the application of Content-MD5 to HTTP entity-bodies differs from its application to MIME entity-bodies. One 1286 1291 is that HTTP, unlike MIME, does not use Content-Transfer-Encoding, and does use Transfer-Encoding and Content-Encoding. Another … … 1288 1293 used to compute the digest is the transmission byte order defined for the type. Lastly, HTTP allows transmission of text types 1289 1294 with any of several line break conventions and not just the canonical form using CRLF. 1290 </ dd>1291 </d l>1295 </p> 1296 </div> 1292 1297 <div id="rfc.iref.c.6"></div> 1293 1298 <div id="rfc.iref.h.9"></div> -
draft-ietf-httpbis/latest/p3-payload.xml
r547 r563 350 350 to determine the exact mapping is not permitted. 351 351 </t> 352 <t><list><t> 353 <x:h>Note:</x:h> This use of the term "character set" is more commonly 354 referred to as a "character encoding." However, since HTTP and 355 MIME share the same registry, it is important that the terminology 356 also be shared. 357 </t></list></t> 352 <x:note> 353 <t> 354 <x:h>Note:</x:h> This use of the term "character set" is more commonly 355 referred to as a "character encoding." However, since HTTP and 356 MIME share the same registry, it is important that the terminology 357 also be shared. 358 </t> 359 </x:note> 358 360 <t anchor="rule.charset"> 359 361 <x:anchor-alias value="charset"/> … … 603 605 application &MUST; treat it as being equivalent to "multipart/mixed". 604 606 </t> 605 <t><list><t> 606 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined 607 for carrying form data suitable for processing via the POST 608 request method, as described in <xref target="RFC2388"/>. 609 </t></list></t> 607 <x:note> 608 <t> 609 <x:h>Note:</x:h> The "multipart/form-data" type has been specifically defined 610 for carrying form data suitable for processing via the POST 611 request method, as described in <xref target="RFC2388"/>. 612 </t> 613 </x:note> 610 614 </section> 611 615 </section> … … 756 760 the process of selecting the best representation for a given response 757 761 when there are multiple representations available. 758 <list><t> 759 <x:h>Note:</x:h> This is not called "format negotiation" because the 760 alternate representations may be of the same media type, but use 761 different capabilities of that type, be in different languages, 762 etc. 763 </t></list> 764 </t> 762 </t> 763 <x:note> 764 <t> 765 <x:h>Note:</x:h> This is not called "format negotiation" because the 766 alternate representations may be of the same media type, but use 767 different capabilities of that type, be in different languages, 768 etc. 769 </t> 770 </x:note> 765 771 <t> 766 772 Any response containing an entity-body &MAY; be subject to negotiation, … … 954 960 media-range, using the qvalue scale from 0 to 1 (&qvalue;). The 955 961 default value is q=1. 956 <list><t> 957 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type 958 parameters from Accept extension parameters is due to historical 959 practice. Although this prevents any media type parameter named 960 "q" from being used with a media range, such an event is believed 961 to be unlikely given the lack of any "q" parameters in the IANA 962 media type registry and the rare usage of any media type 963 parameters in Accept. Future media types are discouraged from 964 registering any parameter named "q". 965 </t></list> 966 </t> 962 </t> 963 <x:note> 964 <t> 965 <x:h>Note:</x:h> Use of the "q" parameter name to separate media type 966 parameters from Accept extension parameters is due to historical 967 practice. Although this prevents any media type parameter named 968 "q" from being used with a media range, such an event is believed 969 to be unlikely given the lack of any "q" parameters in the IANA 970 media type registry and the rare usage of any media type 971 parameters in Accept. Future media types are discouraged from 972 registering any parameter named "q". 973 </t> 974 </x:note> 967 975 <t> 968 976 The example … … 1154 1162 additional information that a different content-coding is meaningful 1155 1163 to the client. 1156 <list><t> 1157 <x:h>Note:</x:h> If the request does not include an Accept-Encoding field, 1158 and if the "identity" content-coding is unavailable, then 1159 content-codings commonly understood by HTTP/1.0 clients (i.e., 1160 "gzip" and "compress") are preferred; some older clients 1161 improperly display messages sent with other content-codings. The 1162 server might also make this decision based on information about 1163 the particular user-agent or client. 1164 </t><t> 1165 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues 1166 associated with content-codings. This means that qvalues will not 1167 work and are not permitted with x-gzip or x-compress. 1168 </t></list> 1169 </t> 1164 </t> 1165 <x:note> 1166 <t> 1167 <x:h>Note:</x:h> If the request does not include an Accept-Encoding field, 1168 and if the "identity" content-coding is unavailable, then 1169 content-codings commonly understood by HTTP/1.0 clients (i.e., 1170 "gzip" and "compress") are preferred; some older clients 1171 improperly display messages sent with other content-codings. The 1172 server might also make this decision based on information about 1173 the particular user-agent or client. 1174 </t> 1175 </x:note> 1176 <x:note> 1177 <t> 1178 <x:h>Note:</x:h> Most HTTP/1.0 applications do not recognize or obey qvalues 1179 associated with content-codings. This means that qvalues will not 1180 work and are not permitted with x-gzip or x-compress. 1181 </t> 1182 </x:note> 1170 1183 </section> 1171 1184 … … 1218 1231 matches every tag not matched by any other range present in the 1219 1232 Accept-Language field. 1220 <list><t> 1221 <x:h>Note:</x:h> This use of a prefix matching rule does not imply that 1222 language tags are assigned to languages in such a way that it is 1223 always true that if a user understands a language with a certain 1224 tag, then this user will also understand all languages with tags 1225 for which this tag is a prefix. The prefix rule simply allows the 1226 use of prefix tags if this is the case. 1227 </t></list> 1228 </t> 1233 </t> 1234 <x:note> 1235 <t> 1236 <x:h>Note:</x:h> This use of a prefix matching rule does not imply that 1237 language tags are assigned to languages in such a way that it is 1238 always true that if a user understands a language with a certain 1239 tag, then this user will also understand all languages with tags 1240 for which this tag is a prefix. The prefix rule simply allows the 1241 use of prefix tags if this is the case. 1242 </t> 1243 </x:note> 1229 1244 <t> 1230 1245 The language quality factor assigned to a language-tag by the … … 1250 1265 available, then the Accept-Language header field &MUST-NOT; be given in 1251 1266 the request. 1252 <list><t> 1253 <x:h>Note:</x:h> When making the choice of linguistic preference available to 1254 the user, we remind implementors of the fact that users are not 1255 familiar with the details of language matching as described above, 1256 and should provide appropriate guidance. As an example, users 1257 might assume that on selecting "en-gb", they will be served any 1258 kind of English document if British English is not available. A 1259 user agent might suggest in such a case to add "en" to get the 1260 best matching behavior. 1261 </t></list> 1262 </t> 1267 </t> 1268 <x:note> 1269 <t> 1270 <x:h>Note:</x:h> When making the choice of linguistic preference available to 1271 the user, we remind implementors of the fact that users are not 1272 familiar with the details of language matching as described above, 1273 and should provide appropriate guidance. As an example, users 1274 might assume that on selecting "en-gb", they will be served any 1275 kind of English document if British English is not available. A 1276 user agent might suggest in such a case to add "en" to get the 1277 best matching behavior. 1278 </t> 1279 </x:note> 1263 1280 </section> 1264 1281 … … 1477 1494 the text actually transmitted &MUST; be left unaltered when computing 1478 1495 the digest. 1479 <list><t> 1480 <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for 1481 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1482 in which the application of Content-MD5 to HTTP entity-bodies 1483 differs from its application to MIME entity-bodies. One is that 1484 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1485 does use Transfer-Encoding and Content-Encoding. Another is that 1486 HTTP more frequently uses binary content types than MIME, so it is 1487 worth noting that, in such cases, the byte order used to compute 1488 the digest is the transmission byte order defined for the type. 1489 Lastly, HTTP allows transmission of text types with any of several 1490 line break conventions and not just the canonical form using CRLF. 1491 </t></list> 1492 </t> 1496 </t> 1497 <x:note> 1498 <t> 1499 <x:h>Note:</x:h> while the definition of Content-MD5 is exactly the same for 1500 HTTP as in RFC 1864 for MIME entity-bodies, there are several ways 1501 in which the application of Content-MD5 to HTTP entity-bodies 1502 differs from its application to MIME entity-bodies. One is that 1503 HTTP, unlike MIME, does not use Content-Transfer-Encoding, and 1504 does use Transfer-Encoding and Content-Encoding. Another is that 1505 HTTP more frequently uses binary content types than MIME, so it is 1506 worth noting that, in such cases, the byte order used to compute 1507 the digest is the transmission byte order defined for the type. 1508 Lastly, HTTP allows transmission of text types with any of several 1509 line break conventions and not just the canonical form using CRLF. 1510 </t> 1511 </x:note> 1493 1512 </section> 1494 1513 -
draft-ietf-httpbis/latest/p4-conditional.html
r560 r563 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 464 467 <tr> 465 468 <td class="header left"></td> 466 <td class="header right">March 12, 2009</td>469 <td class="header right">March 24, 2009</td> 467 470 </tr> 468 471 </table> … … 792 795 value. 793 796 </p> 794 <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way. 795 </p> 796 <d l class="empty">797 < dd> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value797 <p id="rfc.section.5.p.4">In order to be legal, a strong entity tag <em class="bcp14">MUST</em> change whenever the associated entity changes in any way. A weak entity tag <em class="bcp14">SHOULD</em> change whenever the associated entity changes in a semantically significant way. 798 </p> 799 <div class="note"> 800 <p> <b>Note:</b> in order to provide semantically transparent caching, an origin server must avoid reusing a specific strong entity tag value 798 801 for two different entities, or reusing a specific weak entity tag value for two semantically different entities. Cache entries 799 802 might persist for arbitrarily long periods, regardless of expiration times, so it might be inappropriate to expect that a 800 803 cache will never again attempt to validate an entry using a validator that it obtained at some point in the past. 801 </ dd>802 </d l>803 <p id="rfc.section.5.p. 5">HTTP/1.1 clients: </p>804 </p> 805 </div> 806 <p id="rfc.section.5.p.6">HTTP/1.1 clients: </p> 804 807 <ul> 805 808 <li>If an entity tag has been provided by the origin server, <em class="bcp14">MUST</em> use that entity tag in any cache-conditional request (using If-Match or If-None-Match). … … 812 815 </li> 813 816 </ul> 814 <p id="rfc.section.5.p. 6">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since817 <p id="rfc.section.5.p.7">An HTTP/1.1 origin server, upon receiving a conditional request that includes both a Last-Modified date (e.g., in an If-Modified-Since 815 818 or If-Unmodified-Since header field) and one or more entity tags (e.g., in an If-Match, If-None-Match, or If-Range header 816 819 field) as cache validators, <em class="bcp14">MUST NOT</em> return a response status of 304 (Not Modified) unless doing so is consistent with all of the conditional header fields in 817 820 the request. 818 821 </p> 819 <p id="rfc.section.5.p. 7">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity822 <p id="rfc.section.5.p.8">An HTTP/1.1 caching proxy, upon receiving a conditional request that includes both a Last-Modified date and one or more entity 820 823 tags as cache validators, <em class="bcp14">MUST NOT</em> return a locally cached response to the client unless that cached response is consistent with all of the conditional header 821 824 fields in the request. -
draft-ietf-httpbis/latest/p4-conditional.xml
r547 r563 602 602 change whenever the associated entity changes in a semantically 603 603 significant way. 604 <list><t> 605 <x:h>Note:</x:h> in order to provide semantically transparent caching, an 606 origin server must avoid reusing a specific strong entity tag 607 value for two different entities, or reusing a specific weak 608 entity tag value for two semantically different entities. Cache 609 entries might persist for arbitrarily long periods, regardless of 610 expiration times, so it might be inappropriate to expect that a 611 cache will never again attempt to validate an entry using a 612 validator that it obtained at some point in the past. 613 </t></list> 614 </t> 604 </t> 605 <x:note> 606 <t> 607 <x:h>Note:</x:h> in order to provide semantically transparent caching, an 608 origin server must avoid reusing a specific strong entity tag 609 value for two different entities, or reusing a specific weak 610 entity tag value for two semantically different entities. Cache 611 entries might persist for arbitrarily long periods, regardless of 612 expiration times, so it might be inappropriate to expect that a 613 cache will never again attempt to validate an entry using a 614 validator that it obtained at some point in the past. 615 </t> 616 </x:note> 615 617 <t> 616 618 HTTP/1.1 clients: -
draft-ietf-httpbis/latest/p5-range.html
r560 r563 29 29 cite { 30 30 font-style: normal; 31 } 32 div.note { 33 margin-left: 2em; 31 34 } 32 35 dd { … … 464 467 <tr> 465 468 <td class="header left"></td> 466 <td class="header right">March 12, 2009</td>469 <td class="header right">March 24, 2009</td> 467 470 </tr> 468 471 </table> … … 761 764 <p id="rfc.section.5.2.p.14">If the server receives a request (other than one including an If-Range request-header field) with an unsatisfiable Range request-header 762 765 field (that is, all of whose byte-range-spec values have a first-byte-pos value greater than the current length of the selected 763 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 3.2</a>). 764 </p> 765 <d l class="empty">766 < dd> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for766 resource), it <em class="bcp14">SHOULD</em> return a response code of 416 (Requested range not satisfiable) (<a href="#status.416" id="rfc.xref.status.416.1" title="416 Requested Range Not Satisfiable">Section 3.2</a>). 767 </p> 768 <div class="note"> 769 <p> <b>Note:</b> clients cannot depend on servers to send a 416 (Requested range not satisfiable) response instead of a 200 (OK) response for 767 770 an unsatisfiable Range request-header, since not all servers implement this request-header. 768 </ dd>769 </d l>771 </p> 772 </div> 770 773 <div id="rfc.iref.i.1"></div> 771 774 <div id="rfc.iref.h.3"></div> -
draft-ietf-httpbis/latest/p5-range.xml
r547 r563 629 629 resource), it &SHOULD; return a response code of 416 (Requested range 630 630 not satisfiable) (<xref target="status.416"/>). 631 <list><t> 632 <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested 633 range not satisfiable) response instead of a 200 (OK) response for 634 an unsatisfiable Range request-header, since not all servers 635 implement this request-header. 636 </t></list> 637 </t> 631 </t> 632 <x:note> 633 <t> 634 <x:h>Note:</x:h> clients cannot depend on servers to send a 416 (Requested 635 range not satisfiable) response instead of a 200 (OK) response for 636 an unsatisfiable Range request-header, since not all servers 637 implement this request-header. 638 </t> 639 </x:note> 638 640 </section> 639 641
Note: See TracChangeset
for help on using the changeset viewer.