Changeset 969 for draft-ietf-httpbis/latest
- Timestamp:
- 31/07/10 01:06:01 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.xml
r968 r969 263 263 of received communication, and the expected behavior of recipients. 264 264 If the communication is considered in isolation, then successful 265 actions shouldbe reflected in corresponding changes to the265 actions ought to be reflected in corresponding changes to the 266 266 observable interface provided by servers. However, since multiple 267 267 clients might act in parallel and perhaps at cross-purposes, we … … 1107 1107 empty line received where a Request-Line is expected. In other words, if 1108 1108 the server is reading the protocol stream at the beginning of a 1109 message and receives a CRLF first, it shouldignore the CRLF.1109 message and receives a CRLF first, it &SHOULD; ignore the CRLF. 1110 1110 </t> 1111 1111 <t> … … 1333 1333 Such a message might indicate an attempt to perform request or response 1334 1334 smuggling (bypass of security-related checks on message routing or content) 1335 and thus shouldbe handled as an error. The provided Content-Length &MUST;1335 and thus ought to be handled as an error. The provided Content-Length &MUST; 1336 1336 be removed, prior to forwarding the message downstream, or replaced with 1337 1337 the real message-body length after the transfer-coding is decoded. … … 1603 1603 meaning of the request when the origin server is improperly using 1604 1604 a non-reserved URI character for a reserved purpose. Implementors 1605 shouldbe aware that some pre-HTTP/1.1 proxies have been known to1605 need to be aware that some pre-HTTP/1.1 proxies have been known to 1606 1606 rewrite the request-target. 1607 1607 </t> … … 3311 3311 The HTTP Upgrade Token Registry defines the name space for product 3312 3312 tokens used to identify protocols in the Upgrade header field. 3313 Each registered token should be associated with one or a set of 3314 specifications, and with contact information. 3315 </t> 3316 <t> 3317 Registrations should be allowed on a First Come First Served basis as 3318 described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. These 3319 specifications need not be IETF documents or be subject to IESG review, but 3320 should obey the following rules: 3313 Each registered token is associated with contact information and 3314 an optional set of specifications that details how the connection 3315 will be processed after it has been upgraded. 3316 </t> 3317 <t> 3318 Registrations are allowed on a First Come First Served basis as 3319 described in <xref target="RFC5226" x:sec="4.1" x:fmt="of"/>. The 3320 specifications need not be IETF documents or be subject to IESG review. 3321 Registrations are subject to the following rules: 3321 3322 <list style="numbers"> 3322 3323 <t>A token, once registered, stays registered forever.</t> … … 3324 3325 registration.</t> 3325 3326 <t>The registration &MUST; name a point of contact.</t> 3326 <t>The registration &MAY; name the documentation required for the3327 token. </t>3327 <t>The registration &MAY; name a set of specifications associated with that 3328 token. Such specifications need not be publicly available.</t> 3328 3329 <t>The responsible party &MAY; change the registration at any time. 3329 3330 The IANA will keep a record of all such changes, and make them … … 3337 3338 </list> 3338 3339 </t> 3339 <t>3340 It is not required that specifications for upgrade tokens be made3341 publicly available, but the contact information for the registration3342 should be.3343 </t>3344 3340 </section> 3345 3341 … … 3453 3449 <section title="Header Field Registration" anchor="header.field.registration"> 3454 3450 <t> 3455 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated3451 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 3456 3452 with the permanent registrations below (see <xref target="RFC3864"/>): 3457 3453 </t> … … 3530 3526 The entries for the "http" and "https" URI Schemes in the registry located at 3531 3527 <eref target="http://www.iana.org/assignments/uri-schemes.html"/> 3532 sh ouldbe updated to point to Sections <xref target="http.uri" format="counter"/>3528 shall be updated to point to Sections <xref target="http.uri" format="counter"/> 3533 3529 and <xref target="https.uri" format="counter"/> of this document 3534 3530 (see <xref target="RFC4395"/>). … … 3693 3689 <t> 3694 3690 The HTTP Transfer Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/> 3695 sh ouldbe updated with the registrations below:3691 shall be updated with the registrations below: 3696 3692 </t> 3697 3693 <texttable align="left" suppress-title="true" anchor="iana.transfer.coding.registration.table"> … … 3732 3728 <t> 3733 3729 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-upgrade-tokens/"/> 3734 sh ouldbe updated with the registration below:3730 shall be updated with the registration below: 3735 3731 </t> 3736 3732 <texttable align="left" suppress-title="true"> … … 3860 3856 </t> 3861 3857 <t> 3862 Proxy operators shouldprotect the systems on which proxies run as3858 Proxy operators need to protect the systems on which proxies run as 3863 3859 they would protect any system that contains or transports sensitive 3864 3860 information. In particular, log information gathered at proxies often 3865 3861 contains highly sensitive personal information, and/or information 3866 about organizations. Log information shouldbe carefully guarded, and3867 appropriate guidelines for use shouldbe developed and followed.3862 about organizations. Log information needs to be carefully guarded, and 3863 appropriate guidelines for use need to be developed and followed. 3868 3864 (<xref target="abuse.of.server.log.information"/>). 3869 3865 </t> 3870 3866 <t> 3871 Proxy implementors shouldconsider the privacy and security3867 Proxy implementors need to consider the privacy and security 3872 3868 implications of their design and coding decisions, and of the 3873 3869 configuration options they provide to proxy operators (especially the -
draft-ietf-httpbis/latest/p2-semantics.xml
r968 r969 729 729 <iref item="Safe Methods" primary="true"/> 730 730 <t> 731 Implementors shouldbe aware that the software represents the user in732 their interactions over the Internet, and should be carefulto allow731 Implementors need to be aware that the software represents the user in 732 their interactions over the Internet, and need to allow 733 733 the user to be aware of any actions they take which might have an 734 734 unexpected significance to themselves or others. … … 1329 1329 <x:h>Note:</x:h> An earlier version of this specification recommended a 1330 1330 maximum of five redirections (<xref target="RFC2068" x:fmt="," x:sec="10.3"/>). 1331 Content developers should be aware that there might be clients that1331 Content developers need to be aware that some clients might 1332 1332 implement such a fixed limitation. 1333 1333 </t> … … 2179 2179 obsolete or mistyped links to be traced for maintenance. Some servers use 2180 2180 Referer as a means of controlling where they allow links from (so-called 2181 "deep linking"), but it should be noted that legitimate requests are not2182 required tocontain a Referer header field.2181 "deep linking"), but legitimate requests do not always 2182 contain a Referer header field. 2183 2183 </t> 2184 2184 <t> … … 2329 2329 </t> 2330 2330 <t> 2331 The HTTP Method Registry sh ouldbe created at <eref target="http://www.iana.org/assignments/http-methods"/>2331 The HTTP Method Registry shall be created at <eref target="http://www.iana.org/assignments/http-methods"/> 2332 2332 and be populated with the registrations below: 2333 2333 </t> … … 2391 2391 <t> 2392 2392 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 2393 sh ouldbe updated with the registrations below:2393 shall be updated with the registrations below: 2394 2394 </t> 2395 2395 <?BEGININC p2-semantics.iana-status-codes ?> … … 2585 2585 <section title="Header Field Registration" anchor="header.field.registration"> 2586 2586 <t> 2587 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated2587 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 2588 2588 with the permanent registrations below (see <xref target="RFC3864"/>): 2589 2589 </t> … … 2744 2744 </t> 2745 2745 <t> 2746 Authors of services should notuse GET-based forms for the submission of2747 sensitive data because that data will be encoded in the request-target. Many2746 Authors of services &SHOULD-NOT; use GET-based forms for the submission of 2747 sensitive data because that data will be placed in the request-target. Many 2748 2748 existing servers, proxies, and user agents log or display the request-target 2749 2749 in places where it might be visible to third parties. Such services can -
draft-ietf-httpbis/latest/p3-payload.xml
r968 r969 409 409 </t> 410 410 <t> 411 Implementors shouldbe aware of IETF character set requirements <xref target="RFC3629"/>411 Implementors need to be aware of IETF character set requirements <xref target="RFC3629"/> 412 412 <xref target="RFC2277"/>. 413 413 </t> … … 1300 1300 the user, we remind implementors of the fact that users are not 1301 1301 familiar with the details of language matching as described above, 1302 and should provideappropriate guidance. As an example, users1302 and ought to be provided appropriate guidance. As an example, users 1303 1303 might assume that on selecting "en-gb", they will be served any 1304 1304 kind of English document if British English is not available. A … … 1607 1607 <section title="Header Field Registration" anchor="header.field.registration"> 1608 1608 <t> 1609 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated1609 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 1610 1610 with the permanent registrations below (see <xref target="RFC3864"/>): 1611 1611 </t> … … 1699 1699 <t> 1700 1700 The HTTP Content Codings Registry located at <eref target="http://www.iana.org/assignments/http-parameters"/> 1701 sh ouldbe updated with the registration below:1701 shall be updated with the registration below: 1702 1702 </t> 1703 1703 <texttable align="left" suppress-title="true" anchor="iana.content.coding.registration.table"> … … 2605 2605 </t> 2606 2606 <t> 2607 Implementors should note that conversion will break any cryptographic2607 Conversion will break any cryptographic 2608 2608 checksums applied to the original content unless the original content 2609 2609 is already in canonical form. Therefore, the canonical form is -
draft-ietf-httpbis/latest/p4-conditional.xml
r965 r969 704 704 <list><t> 705 705 <x:h>Note:</x:h> The general principle behind these rules is that HTTP/1.1 706 servers and clients shouldtransmit as much non-redundant706 servers and clients ought to transmit as much non-redundant 707 707 information as is available in their responses and requests. 708 708 HTTP/1.1 systems receiving this information will make the most … … 903 903 <x:h>Note:</x:h> If a client uses an arbitrary date in the If-Modified-Since 904 904 header instead of a date taken from the Last-Modified header for 905 the same request, the client should be aware of the factthat this906 date is interpreted in the server's understanding of time. The907 client should consider unsynchronized clocks and rounding problems908 due to the different encodings of time between the client and909 server.This includes the possibility of race conditions if the905 the same request, the client needs to be aware that this 906 date is interpreted in the server's understanding of time. 907 Unsynchronized clocks and rounding problems, due to the different 908 encodings of time between the client and server, are concerns. 909 This includes the possibility of race conditions if the 910 910 document has changed between the time it was first requested and 911 911 the If-Modified-Since date of a subsequent request, and the … … 1107 1107 <t> 1108 1108 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 1109 sh ouldbe updated with the registrations below:1109 shall be updated with the registrations below: 1110 1110 </t> 1111 1111 <?BEGININC p4-conditional.iana-status-codes ?> … … 1132 1132 <section title="Header Field Registration" anchor="header.field.registration"> 1133 1133 <t> 1134 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated1134 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 1135 1135 with the permanent registrations below (see <xref target="RFC3864"/>): 1136 1136 </t> -
draft-ietf-httpbis/latest/p5-range.xml
r965 r969 520 520 <t> 521 521 The "Content-Range" header field is sent with a partial representation to 522 specify where in the full representation the payload body shouldbe522 specify where in the full representation the payload body is intended to be 523 523 applied. 524 524 </t> … … 883 883 <t> 884 884 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 885 sh ouldbe updated with the registrations below:885 shall be updated with the registrations below: 886 886 </t> 887 887 <?BEGININC p5-range.iana-status-codes ?> … … 908 908 <section title="Header Field Registration" anchor="header.field.registration"> 909 909 <t> 910 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated910 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 911 911 with the permanent registrations below (see <xref target="RFC3864"/>): 912 912 </t> … … 957 957 </t> 958 958 <t> 959 The HTTP Range Specifier Registry sh ouldbe created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/>959 The HTTP Range Specifier Registry shall be created at <eref target="http://www.iana.org/assignments/http-range-specifiers"/> 960 960 and be populated with the registrations below: 961 961 </t> -
draft-ietf-httpbis/latest/p6-cache.xml
r965 r969 280 280 <list> 281 281 <t>The time at which the origin server intends that a representation 282 shouldno longer be returned by a cache without further validation.</t>282 no longer be returned by a cache without further validation.</t> 283 283 </list> 284 284 </t> … … 566 566 <t> 567 567 If an origin server wishes to force a cache to validate every request, it 568 can assign an explicit expiration time in the past. This means that the 569 response is always stale, so that caches should validate it before using it 570 for subsequent requests. <cref anchor="TODO-response-stale">This wording 571 might cause confusion, because the response might still be served 572 stale.</cref> 568 can assign an explicit expiration time in the past to indicate that the 569 response is already stale. Compliant caches will validate the cached response 570 before reusing it for subsequent requests. 573 571 </t> 574 572 <t> … … 1741 1739 </t> 1742 1740 <t> 1743 The HTTP Cache Directive Registry sh ouldbe created at <eref1741 The HTTP Cache Directive Registry shall be created at <eref 1744 1742 target="http://www.iana.org/assignments/http-cache-directives"/> and be 1745 1743 populated with the registrations below: … … 1817 1815 The Message Header Field Registry located at <eref 1818 1816 target="http://www.iana.org/assignments/message-headers/message-header-index.html" /> 1819 sh ouldbe updated with the permanent registrations below (see <xref target="RFC3864" />):1817 shall be updated with the permanent registrations below (see <xref target="RFC3864" />): 1820 1818 </t> 1821 1819 <?BEGININC p6-cache.iana-headers ?> … … 1881 1879 on the cache can reveal information long after a user believes that the 1882 1880 information has been removed from the network. Therefore, cache contents 1883 shouldbe protected as sensitive information.1881 need to be protected as sensitive information. 1884 1882 </t> 1885 1883 </section> -
draft-ietf-httpbis/latest/p7-auth.xml
r965 r969 486 486 <t> 487 487 The HTTP Status Code Registry located at <eref target="http://www.iana.org/assignments/http-status-codes"/> 488 sh ouldbe updated with the registrations below:488 shall be updated with the registrations below: 489 489 </t> 490 490 <?BEGININC p7-auth.iana-status-codes ?> … … 511 511 <section title="Header Field Registration" anchor="header.field.registration"> 512 512 <t> 513 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> sh ouldbe updated513 The Message Header Field Registry located at <eref target="http://www.iana.org/assignments/message-headers/message-header-index.html"/> shall be updated 514 514 with the permanent registrations below (see <xref target="RFC3864"/>): 515 515 </t>
Note: See TracChangeset
for help on using the changeset viewer.