Changeset 2398
- Timestamp:
- 14/09/13 23:59:24 (9 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 8 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2393 r2398 1555 1555 the user agent <em class="bcp14">MUST</em> count the terminating CRLF octets as part of the message body length. 1556 1556 </p> 1557 <p id="rfc.section.3.5.p.2">In the interest of robustness, servers <em class="bcp14">SHOULD</em> ignore at least one empty line received where a request-line is expected. In other words, if a server is reading the protocol 1558 stream at the beginning of a message and receives a CRLF first, the server <em class="bcp14">SHOULD</em> ignore the CRLF. 1557 <p id="rfc.section.3.5.p.2">In the interest of robustness, a server that is expecting to receive and parse a request-line <em class="bcp14">SHOULD</em> ignore at least one empty line (CRLF) received prior to the request-line. 1559 1558 </p> 1560 1559 <p id="rfc.section.3.5.p.3">Although the line terminator for the start-line and header fields is the sequence CRLF, recipients <em class="bcp14">MAY</em> recognize a single LF as a line terminator and ignore any preceding CR. … … 2644 2643 <p id="rfc.section.9.3.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 6.5.12</a> of <a href="#Part2" id="rfc.xref.Part2.30"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 6.5</a> of <a href="#Part2" id="rfc.xref.Part2.31"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content">[Part2]</cite></a>). Additional status codes related to capacity limits have been defined by extensions to HTTP <a href="#RFC6585" id="rfc.xref.RFC6585.1"><cite title="Additional HTTP Status Codes">[RFC6585]</cite></a>. 2645 2644 </p> 2646 <p id="rfc.section.9.3.p.4">Recipients <em class="bcp14">SHOULD</em> carefully limit the extent to which they read other fields, including (but not limited to) request methods, response status2647 phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability.2645 <p id="rfc.section.9.3.p.4">Recipients ought to carefully limit the extent to which they read other fields, including (but not limited to) request methods, 2646 response status phrases, header field-names, and body chunks, so as to avoid denial of service attacks without impeding interoperability. 2648 2647 </p> 2649 2648 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="message.integrity" href="#message.integrity">Message Integrity</a></h2> … … 2670 2669 needs to be securely stored and appropriate guidelines followed for its analysis. Anonymization of personal information within 2671 2670 individual entries helps, but is generally not sufficient to prevent real log traces from being re-identified based on correlation 2672 with other access characteristics. As such, access traces that are keyed to a specific client should not be published even2673 ifthe key is pseudonymous.2674 </p> 2675 <p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information shouldbe purged of personally identifiable information,2671 with other access characteristics. As such, access traces that are keyed to a specific client are unsafe to publish even if 2672 the key is pseudonymous. 2673 </p> 2674 <p id="rfc.section.9.5.p.3">To minimize the risk of theft or accidental publication, log information ought to be purged of personally identifiable information, 2676 2675 including user identifiers, IP addresses, and user-provided query parameters, as soon as that information is no longer necessary 2677 2676 to support operational needs for security, auditing, or fraud control. -
draft-ietf-httpbis/latest/p1-messaging.xml
r2393 r2398 1905 1905 </t> 1906 1906 <t> 1907 In the interest of robustness, servers &SHOULD; ignore at least one 1908 empty line received where a request-line is expected. In other words, if 1909 a server is reading the protocol stream at the beginning of a 1910 message and receives a CRLF first, the server &SHOULD; ignore the CRLF. 1907 In the interest of robustness, a server that is expecting to receive and 1908 parse a request-line &SHOULD; ignore at least one empty line (CRLF) 1909 received prior to the request-line. 1911 1910 </t> 1912 1911 <t> … … 3836 3835 </t> 3837 3836 <t> 3838 Recipients &SHOULD;carefully limit the extent to which they read other3837 Recipients ought to carefully limit the extent to which they read other 3839 3838 fields, including (but not limited to) request methods, response status 3840 3839 phrases, header field-names, and body chunks, so as to avoid denial of … … 3886 3885 but is generally not sufficient to prevent real log traces from being 3887 3886 re-identified based on correlation with other access characteristics. 3888 As such, access traces that are keyed to a specific client should not3889 be publishedeven if the key is pseudonymous.3887 As such, access traces that are keyed to a specific client are unsafe to 3888 publish even if the key is pseudonymous. 3890 3889 </t> 3891 3890 <t> 3892 3891 To minimize the risk of theft or accidental publication, log information 3893 shouldbe purged of personally identifiable information, including3892 ought to be purged of personally identifiable information, including 3894 3893 user identifiers, IP addresses, and user-provided query parameters, 3895 3894 as soon as that information is no longer necessary to support operational -
draft-ietf-httpbis/latest/p2-semantics.html
r2396 r2398 1470 1470 appropriate error message containing sufficient information to explain why the representation is unsuitable. The <a href="#status.409" class="smpl">409 (Conflict)</a> or <a href="#status.415" class="smpl">415 (Unsupported Media Type)</a> status codes are suggested, with the latter being specific to constraints on <a href="#header.content-type" class="smpl">Content-Type</a> values. 1471 1471 </p> 1472 <p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the n the origin server <em class="bcp14">SHOULD</em>do one of:1472 <p id="rfc.section.4.3.4.p.5">For example, if the target resource is configured to always have a <a href="#header.content-type" class="smpl">Content-Type</a> of "text/html" and the representation being PUT has a Content-Type of "image/jpeg", the origin server ought to do one of: 1473 1473 </p> 1474 1474 <ol class="la"> … … 1867 1867 <p id="rfc.section.5.3.2.p.6">The example</p> 1868 1868 <div id="rfc.figure.u.25"></div><pre class="text"> Accept: audio/*; q=0.2, audio/basic 1869 </pre><p id="rfc.section.5.3.2.p.8"> <em class="bcp14">SHOULD</em> beinterpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in1869 </pre><p id="rfc.section.5.3.2.p.8">is interpreted as "I prefer audio/basic, but send me any audio type if it is the best available after an 80% mark-down in 1870 1870 quality". 1871 1871 </p> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2396 r2398 1460 1460 For example, if the target resource is configured to always have a 1461 1461 <x:ref>Content-Type</x:ref> of "text/html" and the representation being PUT 1462 has a Content-Type of "image/jpeg", the n the origin server &SHOULD;do one of:1462 has a Content-Type of "image/jpeg", the origin server ought to do one of: 1463 1463 <list style="letters"> 1464 1464 <t>reconfigure the target resource to reflect the new media type;</t> … … 2128 2128 </artwork></figure> 2129 2129 <t> 2130 &SHOULD; beinterpreted as "I prefer audio/basic, but send me any audio2130 is interpreted as "I prefer audio/basic, but send me any audio 2131 2131 type if it is the best available after an 80% mark-down in quality". 2132 2132 </t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2394 r2398 682 682 data is available prior to the response header fields being sent and the digest does not need to be recalculated every time 683 683 a validation request is received. However, if a resource has distinct representations that differ only in their metadata, 684 such as might occur with content negotiation over media types that happen to share the same data format, then the origin server <em class="bcp14">SHOULD</em> incorporate additional information in the validator to distinguish those representations. 684 such as might occur with content negotiation over media types that happen to share the same data format, then the origin server 685 needs to incorporate additional information in the validator to distinguish those representations. 685 686 </p> 686 687 <p id="rfc.section.2.1.p.6">In contrast, a "weak validator" is representation metadata that might not change for every change to the representation data. -
draft-ietf-httpbis/latest/p4-conditional.xml
r2394 r2398 244 244 only in their metadata, such as might occur with content negotiation over 245 245 media types that happen to share the same data format, then the origin 246 server &SHOULD;incorporate additional information in the validator to246 server needs to incorporate additional information in the validator to 247 247 distinguish those representations. 248 248 </t> -
draft-ietf-httpbis/latest/p7-auth.html
r2393 r2398 726 726 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 727 727 <p id="rfc.section.4.1.p.1">The "Authorization" header field allows a user agent to authenticate itself with an origin server — usually, but not necessarily, 728 after receiving a <a href="#status.401" class="smpl">401 729 (Unauthorized)</a> response. Its value consists of credentials containing information of the user agent for the realm of theresource being requested.728 after receiving a <a href="#status.401" class="smpl">401 (Unauthorized)</a> response. Its value consists of credentials containing the authentication information of the user agent for the realm of the 729 resource being requested. 730 730 </p> 731 731 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.6"></span> <a href="#header.authorization" class="smpl">Authorization</a> = <a href="#challenge.and.response" class="smpl">credentials</a> 732 </pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials <em class="bcp14">SHOULD</em> be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, 733 such as credentials that vary according to a challenge value or using synchronized clocks). 732 </pre><p id="rfc.section.4.1.p.3">If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests 733 within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary 734 according to a challenge value or using synchronized clocks). 734 735 </p> 735 736 <p id="rfc.section.4.1.p.4">See <a href="p6-cache.html#caching.authenticated.responses" title="Storing Responses to Authenticated Requests">Section 3.2</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a> for details of and requirements pertaining to handling of the Authorization field by HTTP caches. -
draft-ietf-httpbis/latest/p7-auth.xml
r2393 r2398 362 362 <x:anchor-alias value="Authorization"/> 363 363 <t> 364 The "Authorization" header field allows a user agent to authenticate 365 itself with an origin server — usually, but not necessarily, after receiving a <x:ref>401366 (Unauthorized)</x:ref> response. Its value consists of credentials containing367 information of the user agent for the realm of the resource being368 requested.364 The "Authorization" header field allows a user agent to authenticate itself 365 with an origin server — usually, but not necessarily, after receiving 366 a <x:ref>401 (Unauthorized)</x:ref> response. Its value consists of 367 credentials containing the authentication information of the user agent for 368 the realm of the resource being requested. 369 369 </t> 370 370 <figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Authorization"/> … … 372 372 </artwork></figure> 373 373 <t> 374 If a request is 375 authenticated and a realm specified, the same credentials &SHOULD; 376 be valid for all other requests within this realm (assuming that 377 the authentication scheme itself does not require otherwise, such 378 as credentials that vary according to a challenge value or using 379 synchronized clocks). 374 If a request is authenticated and a realm specified, the same credentials 375 are presumed to be valid for all other requests within this realm (assuming 376 that the authentication scheme itself does not require otherwise, such as 377 credentials that vary according to a challenge value or using synchronized 378 clocks). 380 379 </t> 381 380 <t>
Note: See TracChangeset
for help on using the changeset viewer.