Changeset 2024
- Timestamp:
- 29/11/12 23:51:24 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 6 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r2018 r2024 449 449 } 450 450 @bottom-center { 451 content: "Expires June 2, 2013";451 content: "Expires June 3, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-11- 29">493 <meta name="dct.issued" scheme="ISO8601" content="2012-11-30"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2145"> 495 495 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> … … 520 520 <tr> 521 521 <td class="left">Intended status: Standards Track</td> 522 <td class="right">November 29, 2012</td>522 <td class="right">November 30, 2012</td> 523 523 </tr> 524 524 <tr> 525 <td class="left">Expires: June 2, 2013</td>525 <td class="left">Expires: June 3, 2013</td> 526 526 <td class="right"></td> 527 527 </tr> … … 551 551 in progress”. 552 552 </p> 553 <p>This Internet-Draft will expire on June 2, 2013.</p>553 <p>This Internet-Draft will expire on June 3, 2013.</p> 554 554 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 555 555 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2824 2824 </p> 2825 2825 <h2 id="rfc.section.A.2"><a href="#rfc.section.A.2">A.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> 2826 <p id="rfc.section.A.2.p.1">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted 2826 <p id="rfc.section.A.2.p.1">HTTP's approach to error handling has been explained. (<a href="#conformance" title="Conformance and Error Handling">Section 2.5</a>) 2827 </p> 2828 <p id="rfc.section.A.2.p.2">The expectation to support HTTP/0.9 requests has been removed.</p> 2829 <p id="rfc.section.A.2.p.3">The term "Effective Request URI" has been introduced. (<a href="#effective.request.uri" title="Effective Request URI">Section 5.5</a>) 2830 </p> 2831 <p id="rfc.section.A.2.p.4">HTTP messages can be (and often are) buffered by implementations; despite it sometimes being available as a stream, HTTP is 2832 fundamentally a message-oriented protocol. (<a href="#http.message" title="Message Format">Section 3</a>) 2833 </p> 2834 <p id="rfc.section.A.2.p.5">Minimum supported sizes for various protocol elements have been suggested, to improve interoperability.</p> 2835 <p id="rfc.section.A.2.p.6">Header fields that span multiple lines ("line folding") are deprecated. (<a href="#field.parsing" title="Field Parsing">Section 3.2.2</a>) 2836 </p> 2837 <p id="rfc.section.A.2.p.7">The HTTP-version ABNF production has been clarified to be case-sensitive. Additionally, version numbers has been restricted 2827 2838 to single digits, due to the fact that implementations are known to handle multi-digit version numbers incorrectly. (<a href="#http.version" title="Protocol Versioning">Section 2.6</a>) 2828 2839 </p> 2829 <p id="rfc.section.A.2.p.2">The "HTTPS" URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2830 </p> 2831 <p id="rfc.section.A.2.p.3">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. 2840 <p id="rfc.section.A.2.p.8">The HTTPS URI scheme is now defined by this specification; previously, it was done in <a href="http://tools.ietf.org/html/rfc2818#section-2.4">Section 2.4</a> of <a href="#RFC2818" id="rfc.xref.RFC2818.3"><cite title="HTTP Over TLS">[RFC2818]</cite></a>. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2841 </p> 2842 <p id="rfc.section.A.2.p.9">The HTTPS URI scheme implies end-to-end security. (<a href="#https.uri" title="https URI scheme">Section 2.7.2</a>) 2843 </p> 2844 <p id="rfc.section.A.2.p.10">Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their 2845 transmission on the wire. (<a href="#http.uri" title="http URI scheme">Section 2.7.1</a>) 2846 </p> 2847 <p id="rfc.section.A.2.p.11">Invalid whitespace around field-names is now required to be rejected, because accepting it represents a security vulnerability. 2832 2848 (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2833 2849 </p> 2834 <p id="rfc.section.A.2.p. 4">The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section 3.2</a>)2835 </p> 2836 <p id="rfc.section.A.2.p. 5">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed2850 <p id="rfc.section.A.2.p.12">The ABNF productions defining header fields now only list the field value. (<a href="#header.fields" title="Header Fields">Section 3.2</a>) 2851 </p> 2852 <p id="rfc.section.A.2.p.13">Rules about implicit linear whitespace between certain grammar productions have been removed; now whitespace is only allowed 2837 2853 where specifically defined in the ABNF. (<a href="#whitespace" title="Whitespace">Section 3.2.1</a>) 2838 2854 </p> 2839 <p id="rfc.section.A.2.p.6">The NUL octet is no longer allowed in comment and quoted-string text. (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2840 </p> 2841 <p id="rfc.section.A.2.p.7">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2842 </p> 2843 <p id="rfc.section.A.2.p.8">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2844 </p> 2845 <p id="rfc.section.A.2.p.9">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) 2846 </p> 2847 <p id="rfc.section.A.2.p.10">The "identity" transfer-coding value token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) 2848 </p> 2849 <p id="rfc.section.A.2.p.11">"multipart/byteranges" is no longer a way of determining message body length detection. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 2850 </p> 2851 <p id="rfc.section.A.2.p.12">CONNECT is a new, special case in determining message body length. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 2852 </p> 2853 <p id="rfc.section.A.2.p.13">Chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 2854 </p> 2855 <p id="rfc.section.A.2.p.14">Use of chunk extensions is deprecated, and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 2856 </p> 2857 <p id="rfc.section.A.2.p.15">The path-absolute + query components of RFC3986 have been used to define the request-target, instead of abs_path from RFC 2855 <p id="rfc.section.A.2.p.14">The NUL octet is no longer allowed in comment and quoted-string text, and handling of backslash-escaping in them has been 2856 clarified. (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2857 </p> 2858 <p id="rfc.section.A.2.p.15">The quoted-pair rule no longer allows escaping control characters other than HTAB. (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2859 </p> 2860 <p id="rfc.section.A.2.p.16">Non-ASCII content in header fields and the reason phrase has been obsoleted and made opaque (the TEXT rule was removed). (<a href="#field.components" title="Field value components">Section 3.2.4</a>) 2861 </p> 2862 <p id="rfc.section.A.2.p.17">Bogus "<a href="#header.content-length" class="smpl">Content-Length</a>" header fields are now required to be handled as errors by recipients. (<a href="#header.content-length" id="rfc.xref.header.content-length.2" title="Content-Length">Section 3.3.2</a>) 2863 </p> 2864 <p id="rfc.section.A.2.p.18">The "identity" transfer-coding value token has been removed. (Sections <a href="#message.body" title="Message Body">3.3</a> and <a href="#transfer.codings" title="Transfer Codings">4</a>) 2865 </p> 2866 <p id="rfc.section.A.2.p.19">The algorithm for determining the message body length has been clarified to indicate all of the special cases (e.g., driven 2867 by methods or status codes) that affect it, and that new protocol elements cannot define such special cases. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 2868 </p> 2869 <p id="rfc.section.A.2.p.20">"multipart/byteranges" is no longer a way of determining message body length detection. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 2870 </p> 2871 <p id="rfc.section.A.2.p.21">CONNECT is a new, special case in determining message body length. (<a href="#message.body.length" title="Message Body Length">Section 3.3.3</a>) 2872 </p> 2873 <p id="rfc.section.A.2.p.22">Chunk length does not include the count of the octets in the chunk header and trailer. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 2874 </p> 2875 <p id="rfc.section.A.2.p.23">Use of chunk extensions is deprecated, and line folding in them is disallowed. (<a href="#chunked.encoding" title="Chunked Transfer Coding">Section 4.1</a>) 2876 </p> 2877 <p id="rfc.section.A.2.p.24">The path-absolute + query components of RFC3986 have been used to define the request-target, instead of abs_path from RFC 2858 2878 1808. (<a href="#request-target" title="Request Target">Section 5.3</a>) 2859 2879 </p> 2860 <p id="rfc.section.A.2.p. 16">The asterisk form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>)2861 </p> 2862 <p id="rfc.section.A.2.p. 17">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>)2863 </p> 2864 <p id="rfc.section.A.2.p. 18">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop2880 <p id="rfc.section.A.2.p.25">The asterisk form of the request-target is only allowed in the OPTIONS method. (<a href="#request-target" title="Request Target">Section 5.3</a>) 2881 </p> 2882 <p id="rfc.section.A.2.p.26">Exactly when "close" connection options have to be sent has been clarified. (<a href="#header.connection" id="rfc.xref.header.connection.10" title="Connection">Section 6.1</a>) 2883 </p> 2884 <p id="rfc.section.A.2.p.27">"hop-by-hop" header fields are required to appear in the Connection header field; just because they're defined as hop-by-hop 2865 2885 in this specification doesn't exempt them. (<a href="#header.connection" id="rfc.xref.header.connection.11" title="Connection">Section 6.1</a>) 2866 2886 </p> 2867 <p id="rfc.section.A.2.p. 19">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>)2868 </p> 2869 <p id="rfc.section.A.2.p.2 0">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>)2870 </p> 2871 <p id="rfc.section.A.2.p. 21">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed.2887 <p id="rfc.section.A.2.p.28">The limit of two connections per server has been removed. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) 2888 </p> 2889 <p id="rfc.section.A.2.p.29">An idempotent sequence of requests is no longer required to be retried. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) 2890 </p> 2891 <p id="rfc.section.A.2.p.30">The requirement to retry requests under certain circumstances when the server prematurely closes the connection has been removed. 2872 2892 (<a href="#persistent.reuse" title="Reuse">Section 6.2.2</a>) 2873 2893 </p> 2874 <p id="rfc.section.A.2.p.22">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) 2875 </p> 2876 <p id="rfc.section.A.2.p.23">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.3</a>) 2877 </p> 2878 <p id="rfc.section.A.2.p.24">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>) 2879 </p> 2880 <p id="rfc.section.A.2.p.25">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>) 2881 </p> 2882 <p id="rfc.section.A.2.p.26">Empty list elements in list productions have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Appendix B</a>) 2894 <p id="rfc.section.A.2.p.31">Some extraneous requirements about when servers are allowed to close connections prematurely have been removed. (<a href="#persistent.connections" title="Persistent Connections">Section 6.2</a>) 2895 </p> 2896 <p id="rfc.section.A.2.p.32">The semantics of the <a href="#header.upgrade" class="smpl">Upgrade</a> header field is now defined in responses other than 101 (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#header.upgrade" id="rfc.xref.header.upgrade.3" title="Upgrade">Section 6.3</a>) 2897 </p> 2898 <p id="rfc.section.A.2.p.33">Registration of Transfer Codings now requires IETF Review (<a href="#transfer.coding.registry" title="Transfer Coding Registry">Section 7.4</a>) 2899 </p> 2900 <p id="rfc.section.A.2.p.34">The meaning of the "deflate" content coding has been clarified. (<a href="#deflate.coding" title="Deflate Coding">Section 4.2.2</a>) 2901 </p> 2902 <p id="rfc.section.A.2.p.35">This specification now defines the Upgrade Token Registry, previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 7.6</a>) 2903 </p> 2904 <p id="rfc.section.A.2.p.36">Empty list elements in list productions (e.g., a list header containing ", ,") have been deprecated. (<a href="#abnf.extension" title="ABNF list extension: #rule">Appendix B</a>) 2905 </p> 2906 <p id="rfc.section.A.2.p.37">Issues with the Keep-Alive and Proxy-Connection headers in requests are pointed out, with use of the latter being discouraged 2907 altogether. (<a href="#compatibility.with.http.1.0.persistent.connections" title="Keep-Alive Connections">Appendix A.1.2</a>) 2883 2908 </p> 2884 2909 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="abnf.extension" href="#abnf.extension">ABNF list extension: #rule</a></h1> -
draft-ietf-httpbis/latest/p1-messaging.xml
r2012 r2024 4719 4719 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 4720 4720 <t> 4721 HTTP's approach to error handling has been explained. 4722 (<xref target="conformance"/>) 4723 </t> 4724 <t> 4725 The expectation to support HTTP/0.9 requests has been removed. 4726 </t> 4727 <t> 4728 The term "Effective Request URI" has been introduced. 4729 (<xref target="effective.request.uri" />) 4730 </t> 4731 <t> 4732 HTTP messages can be (and often are) buffered by implementations; despite 4733 it sometimes being available as a stream, HTTP is fundamentally a 4734 message-oriented protocol. 4735 (<xref target="http.message" />) 4736 </t> 4737 <t> 4738 Minimum supported sizes for various protocol elements have been 4739 suggested, to improve interoperability. 4740 </t> 4741 <t> 4742 Header fields that span multiple lines ("line folding") are deprecated. 4743 (<xref target="field.parsing" />) 4744 </t> 4745 <t> 4721 4746 The HTTP-version ABNF production has been clarified to be case-sensitive. 4722 4747 Additionally, version numbers has been restricted to single digits, due … … 4726 4751 </t> 4727 4752 <t> 4728 The "HTTPS"URI scheme is now defined by this specification; previously,4753 The HTTPS URI scheme is now defined by this specification; previously, 4729 4754 it was done in <xref target="RFC2818" x:fmt="of" x:sec="2.4"/>. 4730 4755 (<xref target="https.uri"/>) 4756 </t> 4757 <t> 4758 The HTTPS URI scheme implies end-to-end security. 4759 (<xref target="https.uri"/>) 4760 </t> 4761 <t> 4762 Userinfo (i.e., username and password) are now disallowed in HTTP and 4763 HTTPS URIs, because of security issues related to their transmission on the 4764 wire. 4765 (<xref target="http.uri" />) 4731 4766 </t> 4732 4767 <t> … … 4746 4781 </t> 4747 4782 <t> 4748 The NUL octet is no longer allowed in comment and quoted-string text. 4783 The NUL octet is no longer allowed in comment and quoted-string text, and 4784 handling of backslash-escaping in them has been clarified. 4749 4785 (<xref target="field.components"/>) 4750 4786 </t> … … 4768 4804 (Sections <xref format="counter" target="message.body"/> and 4769 4805 <xref format="counter" target="transfer.codings"/>) 4806 </t> 4807 <t> 4808 The algorithm for determining the message body length has been clarified 4809 to indicate all of the special cases (e.g., driven by methods or status 4810 codes) that affect it, and that new protocol elements cannot define such 4811 special cases. 4812 (<xref target="message.body.length"/>) 4770 4813 </t> 4771 4814 <t> … … 4837 4880 </t> 4838 4881 <t> 4882 The meaning of the "deflate" content coding has been clarified. 4883 (<xref target="deflate.coding" />) 4884 </t> 4885 <t> 4839 4886 This specification now defines the Upgrade Token Registry, previously 4840 4887 defined in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/>. … … 4842 4889 </t> 4843 4890 <t> 4844 Empty list elements in list productions have been deprecated. 4891 Empty list elements in list productions (e.g., a list header containing 4892 ", ,") have been deprecated. 4845 4893 (<xref target="abnf.extension"/>) 4894 </t> 4895 <t> 4896 Issues with the Keep-Alive and Proxy-Connection headers in requests 4897 are pointed out, with use of the latter being discouraged altogether. 4898 (<xref target="compatibility.with.http.1.0.persistent.connections" />) 4846 4899 </t> 4847 4900 </section> -
draft-ietf-httpbis/latest/p2-semantics.html
r2023 r2024 449 449 } 450 450 @bottom-center { 451 content: "Expires June 2, 2013";451 content: "Expires June 3, 2013"; 452 452 } 453 453 @bottom-right { … … 496 496 <meta name="dct.creator" content="Reschke, J. F."> 497 497 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 498 <meta name="dct.issued" scheme="ISO8601" content="2012-11- 29">498 <meta name="dct.issued" scheme="ISO8601" content="2012-11-30"> 499 499 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 500 500 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 524 524 <tr> 525 525 <td class="left">Intended status: Standards Track</td> 526 <td class="right">November 29, 2012</td>526 <td class="right">November 30, 2012</td> 527 527 </tr> 528 528 <tr> 529 <td class="left">Expires: June 2, 2013</td>529 <td class="left">Expires: June 3, 2013</td> 530 530 <td class="right"></td> 531 531 </tr> … … 555 555 in progress”. 556 556 </p> 557 <p>This Internet-Draft will expire on June 2, 2013.</p>557 <p>This Internet-Draft will expire on June 3, 2013.</p> 558 558 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 559 559 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 4087 4087 </p> 4088 4088 <h1 id="rfc.section.C"><a href="#rfc.section.C">C.</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h1> 4089 <p id="rfc.section.C.p.1"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus 4089 <p id="rfc.section.C.p.1">The term "representation" is introduced, replacing both "entity" and "variant."</p> 4090 <p id="rfc.section.C.p.2"> <a href="#header.content-location" class="smpl">Content-Location</a> no longer sets a base URI, due to poor implementation support (which was caused by too many broken servers emitting bogus 4090 4091 Content-Location header fields, and also the potentially undesirable effect of potentially breaking relative links in content-negotiated 4091 4092 resources). (<a href="#header.content-location" id="rfc.xref.header.content-location.5" title="Content-Location">Section 3.1.4.2</a>) 4092 4093 </p> 4093 <p id="rfc.section.C.p.2">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4094 </p> 4095 <p id="rfc.section.C.p.3">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4096 </p> 4097 <p id="rfc.section.C.p.4">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 5.3.4</a>) 4098 </p> 4099 <p id="rfc.section.C.p.5">The CONNECT method is now defined by this specification, taking over from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 5.3.6</a>) 4100 </p> 4101 <p id="rfc.section.C.p.6">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 5.3.6</a>) 4102 </p> 4103 <p id="rfc.section.C.p.7">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 5.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section 5.3.8</a>) 4104 </p> 4105 <p id="rfc.section.C.p.8">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4094 <p id="rfc.section.C.p.3">Rules for identifying the payload of a message have been defined. (<a href="#identifying.payload" title="Identifying a Representation">Section 3.1.4.1</a>) 4095 </p> 4096 <p id="rfc.section.C.p.4">GET requests can have a body; it just has no meaning. (<a href="#GET" id="rfc.xref.GET.4" title="GET">Section 5.3.1</a>) 4097 </p> 4098 <p id="rfc.section.C.p.5">The definition of POST has been clarified. (<a href="#POST" id="rfc.xref.POST.4" title="POST">Section 5.3.3</a>) 4099 </p> 4100 <p id="rfc.section.C.p.6">Servers are no longer required to handle all Content-* header fields in requests. (<a href="#PUT" id="rfc.xref.PUT.4" title="PUT">Section 5.3.4</a>) 4101 </p> 4102 <p id="rfc.section.C.p.7">Use of <a href="p5-range.html#header.content-range" class="smpl">Content-Range</a> is explicitly banned on PUT requests. (<a href="#PUT" id="rfc.xref.PUT.5" title="PUT">Section 5.3.4</a>) 4103 </p> 4104 <p id="rfc.section.C.p.8">The CONNECT method is now defined by this specification, taking over from <a href="#RFC2817" id="rfc.xref.RFC2817.2"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#CONNECT" id="rfc.xref.CONNECT.3" title="CONNECT">Section 5.3.6</a>) 4105 </p> 4106 <p id="rfc.section.C.p.9">The requirements upon and semantics of CONNECT request and response bodies have been clarified. (<a href="#CONNECT" id="rfc.xref.CONNECT.4" title="CONNECT">Section 5.3.6</a>) 4107 </p> 4108 <p id="rfc.section.C.p.10">The <a href="#OPTIONS" class="smpl">OPTIONS</a> and <a href="#TRACE" class="smpl">TRACE</a> request methods are now defined as being safe. (<a href="#OPTIONS" id="rfc.xref.OPTIONS.4" title="OPTIONS">Section 5.3.7</a> and <a href="#TRACE" id="rfc.xref.TRACE.5" title="TRACE">Section 5.3.8</a>) 4109 </p> 4110 <p id="rfc.section.C.p.11">The <a href="#header.max-forwards" class="smpl">Max-Forwards</a> header field is now restricted to the OPTIONS and TRACE methods (previously, extension methods could have used it as well). 4106 4111 (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section 6.1.1</a>) 4107 4112 </p> 4108 <p id="rfc.section.C.p. 9">The ABNF for the "<a href="#header.expect" class="smpl">Expect</a>" header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing4113 <p id="rfc.section.C.p.12">The ABNF for the "<a href="#header.expect" class="smpl">Expect</a>" header field has been both fixed (allowing parameters for value-less expectations as well) and simplified (allowing trailing 4109 4114 semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section 6.1.2</a>) 4110 4115 </p> 4111 <p id="rfc.section.C.p.10">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>) 4112 </p> 4113 <p id="rfc.section.C.p.11">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>) 4114 </p> 4115 <p id="rfc.section.C.p.12">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one). 4116 </p> 4117 <p id="rfc.section.C.p.13">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.3.4</a>) 4118 </p> 4119 <p id="rfc.section.C.p.14">Redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>) 4120 </p> 4121 <p id="rfc.section.C.p.15">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4116 <p id="rfc.section.C.p.13">Special casing for ISO-8859-1 in <a href="#header.accept-charset" class="smpl">Accept-Charset</a> has been removed. (<a href="#header.accept-charset" id="rfc.xref.header.accept-charset.4" title="Accept-Charset">Section 6.3.3</a>) 4117 </p> 4118 <p id="rfc.section.C.p.14">Requirements for sending the Date header field have been clarified. (<a href="#header.date" id="rfc.xref.header.date.4" title="Date">Section 8.1.1.2</a>) 4119 </p> 4120 <p id="rfc.section.C.p.15">The <a href="#header.referer" class="smpl">Referer</a> header field can now have a value of "about:blank" as an alternative to not sending a Referer header field. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 6.5.2</a>) 4121 </p> 4122 <p id="rfc.section.C.p.16">The <a href="#status.201" class="smpl">201 (Created)</a> status code can indicate that more than one resource has been created (as well as just one). 4123 </p> 4124 <p id="rfc.section.C.p.17">The definition of <a href="#status.203" class="smpl">203 (Non-Authoritative Information)</a> has been broadened to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section 7.3.4</a>) 4125 </p> 4126 <p id="rfc.section.C.p.18">Redirect status codes <a href="#status.301" class="smpl">301</a>, <a href="#status.302" class="smpl">302</a>, and <a href="#status.307" class="smpl">307</a> no longer have normative requirements on response payloads and user interaction. (<a href="#status.3xx" id="rfc.xref.status.3xx.1" title="Redirection 3xx">Section 7.4</a>) 4127 </p> 4128 <p id="rfc.section.C.p.19">The request methods that are safe to automatically redirect is no longer a closed set; user agents are able to make that determination 4122 4129 based upon the request method semantics. (<a href="#status.3xx" id="rfc.xref.status.3xx.2" title="Redirection 3xx">Section 7.4</a>) 4123 4130 </p> 4124 <p id="rfc.section.C.p. 16">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications4131 <p id="rfc.section.C.p.20">The syntax of the <a href="#header.location" class="smpl">Location</a> header field has been corrected to allow URI references (including relative references and fragments), along with some clarifications 4125 4132 as to when use of fragments would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section 8.1.2</a>) 4126 4133 </p> 4127 <p id="rfc.section.C.p. 17">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 7.4.4</a>)4128 </p> 4129 <p id="rfc.section.C.p. 18">User agents are now allowed to rewrite the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">7.4.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.4.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.4.7</a>)4130 </p> 4131 <p id="rfc.section.C.p. 19">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed4134 <p id="rfc.section.C.p.21">The 303 (See Other) status code is now cacheable, if explicit freshness information is available. (<a href="#status.303" id="rfc.xref.status.303.3" title="303 See Other">Section 7.4.4</a>) 4135 </p> 4136 <p id="rfc.section.C.p.22">User agents are now allowed to rewrite the method from POST to GET for status codes <a href="#status.301" class="smpl">301</a> and <a href="#status.302" class="smpl">302</a>. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">7.4.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.4.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.4.7</a>) 4137 </p> 4138 <p id="rfc.section.C.p.23">The <a href="#status.305" class="smpl">305 (Use Proxy)</a> status code is now deprecated, because user agents did not implement it. It used to indicate that the target resource needed 4132 4139 to be accessed through the proxy given by the <a href="#header.location" class="smpl">Location</a> field. The recipient was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section 7.4.5</a>) 4133 4140 </p> 4134 <p id="rfc.section.C.p.2 0">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 7.5.1</a>)4135 </p> 4136 <p id="rfc.section.C.p.2 1">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section 7.5.3</a>)4137 </p> 4138 <p id="rfc.section.C.p.2 2">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.5.15</a>)4139 </p> 4140 <p id="rfc.section.C.p.2 3"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>)4141 </p> 4142 <p id="rfc.section.C.p.2 4">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always4141 <p id="rfc.section.C.p.24">The <a href="#status.400" class="smpl">400 (Bad Request)</a> status code has been made more generic; it isn't limited to syntax errors. (<a href="#status.400" id="rfc.xref.status.400.3" title="400 Bad Request">Section 7.5.1</a>) 4142 </p> 4143 <p id="rfc.section.C.p.25">The <a href="#status.403" class="smpl">403 (Forbidden)</a> status code has been clarified, especially with regards to authentication. (<a href="#status.403" id="rfc.xref.status.403.3" title="403 Forbidden">Section 7.5.3</a>) 4144 </p> 4145 <p id="rfc.section.C.p.26">The <a href="#status.426" class="smpl">426 (Upgrade Required)</a> status code has been incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.3"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section 7.5.15</a>) 4146 </p> 4147 <p id="rfc.section.C.p.27"> <a href="#header.allow" class="smpl">Allow</a> has been reclassified as a response header field, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section 8.4.1</a>) 4148 </p> 4149 <p id="rfc.section.C.p.28">Requirements relating to the content of the Allow header have been relaxed; correspondingly, clients are not required to always 4143 4150 trust its value. (<a href="#header.allow" id="rfc.xref.header.allow.5" title="Allow">Section 8.4.1</a>) 4144 4151 </p> 4145 <p id="rfc.section.C.p.2 5">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>)4146 </p> 4147 <p id="rfc.section.C.p. 26">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>)4148 </p> 4149 <p id="rfc.section.C.p. 27">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition4152 <p id="rfc.section.C.p.29">The requirement to produce a <a href="p1-messaging.html#header.via" class="smpl">Via</a> header field has been moved from the description of the <a href="#header.server" class="smpl">Server</a> header field to <a href="p1-messaging.html#header.via" title="Via">Section 5.7</a> of <a href="#Part1" id="rfc.xref.Part1.44"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section 8.4.2</a>) 4153 </p> 4154 <p id="rfc.section.C.p.30">The contexts that charset is used in have been clarified. (<a href="#charset" title="Charset">Section 3.1.1.2</a>) 4155 </p> 4156 <p id="rfc.section.C.p.31">The default charset of "ISO-8859-1" for text media types has been removed; the default now is whatever the media type definition 4150 4157 says. (<a href="#canonicalization.and.text.defaults" title="Canonicalization and Text Defaults">Section 3.1.1.3</a>) 4151 4158 </p> 4152 <p id="rfc.section.C.p. 28">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>)4153 </p> 4154 <p id="rfc.section.C.p. 29">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses,4159 <p id="rfc.section.C.p.32">Registration of Content Codings now requires IETF Review. (<a href="#content.coding.registry" title="Content Coding Registry">Section 9.4</a>) 4160 </p> 4161 <p id="rfc.section.C.p.33">The Content-MD5 header field has been removed, because it was inconsistently implemented with respect to partial responses, 4155 4162 and also because of known deficiencies in the hash algorithm itself (see <a href="#RFC6151" id="rfc.xref.RFC6151.1"><cite title="Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms">[RFC6151]</cite></a> for details). 4156 4163 </p> 4157 <p id="rfc.section.C.p.3 0">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>)4158 </p> 4159 <p id="rfc.section.C.p.3 1">The Status Code Registry is now defined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 9.2</a>)4160 </p> 4161 <p id="rfc.section.C.p.3 2">References to the "identity" transfer-coding value token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>)4162 </p> 4163 <p id="rfc.section.C.p.3 3">The Content-Disposition header field is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix B</a>)4164 <p id="rfc.section.C.p.34">This specification introduces a Method Registry. (<a href="#method.registry" title="Method Registry">Section 9.1</a>) 4165 </p> 4166 <p id="rfc.section.C.p.35">The Status Code Registry is now defined by this specification; previously, it was defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>. (<a href="#status.code.registry" title="Status Code Registry">Section 9.2</a>) 4167 </p> 4168 <p id="rfc.section.C.p.36">References to the "identity" transfer-coding value token have been removed. (<a href="#no.content-transfer-encoding" id="rfc.xref.no.content-transfer-encoding.1" title="No Content-Transfer-Encoding">Appendix A.5</a>) 4169 </p> 4170 <p id="rfc.section.C.p.37">The Content-Disposition header field is now defined by <a href="#RFC6266" id="rfc.xref.RFC6266.2"><cite title="Use of the Content-Disposition Header Field in the Hypertext Transfer Protocol (HTTP)">[RFC6266]</cite></a>. (<a href="#additional.features" title="Additional Features">Appendix B</a>) 4164 4171 </p> 4165 4172 <h1 id="rfc.section.D"><a href="#rfc.section.D">D.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 4414 4421 </li> 4415 4422 <li><a id="rfc.index.D" href="#rfc.index.D"><b>D</b></a><ul> 4416 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">8.1</a>, <a href="#rfc.iref.d.3"><b>8.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a> </li>4423 <li>Date header field <a href="#rfc.xref.header.date.1">3.3</a>, <a href="#rfc.xref.header.date.2">8.1</a>, <a href="#rfc.iref.d.3"><b>8.1.1.2</b></a>, <a href="#rfc.xref.header.date.3">9.3.2</a>, <a href="#rfc.xref.header.date.4">C</a></li> 4417 4424 <li>deflate (content coding) <a href="#rfc.iref.d.1"><b>3.1.2.1</b></a></li> 4418 4425 <li>DELETE method <a href="#rfc.xref.DELETE.1">5.1</a>, <a href="#rfc.iref.d.2"><b>5.3.5</b></a>, <a href="#rfc.xref.DELETE.2">9.1.3</a></li> … … 4433 4440 </li> 4434 4441 <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul> 4435 <li>GET method <a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.g.18"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a> </li>4442 <li>GET method <a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">5.1</a>, <a href="#rfc.iref.g.18"><b>5.3.1</b></a>, <a href="#rfc.xref.GET.3">9.1.3</a>, <a href="#rfc.xref.GET.4">C</a></li> 4436 4443 <li><tt>Grammar</tt> 4437 4444 <ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2023 r2024 5652 5652 <section title="Changes from RFC 2616" anchor="changes.from.rfc.2616"> 5653 5653 <t> 5654 The term "representation" is introduced, replacing both "entity" and 5655 "variant." 5656 </t> 5657 <t> 5654 5658 <x:ref>Content-Location</x:ref> no longer sets a base URI, due to poor 5655 5659 implementation support (which was caused by too many broken servers emitting … … 5660 5664 </t> 5661 5665 <t> 5666 Rules for identifying the payload of a message have been defined. 5667 (<xref target="identifying.payload" />) 5668 </t> 5669 <t> 5670 GET requests can have a body; it just has no meaning. 5671 (<xref target="GET"/>) 5672 </t> 5673 <t> 5662 5674 The definition of POST has been clarified. 5663 5675 (<xref target="POST"/>) … … 5704 5716 removed. 5705 5717 (<xref target="header.accept-charset"/>) 5718 </t> 5719 <t> 5720 Requirements for sending the Date header field have been clarified. 5721 (<xref target="header.date"/>) 5706 5722 </t> 5707 5723 <t> -
draft-ietf-httpbis/latest/p4-conditional.html
r2022 r2024 449 449 } 450 450 @bottom-center { 451 content: "Expires June 2, 2013";451 content: "Expires June 3, 2013"; 452 452 } 453 453 @bottom-right { … … 491 491 <meta name="dct.creator" content="Reschke, J. F."> 492 492 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 493 <meta name="dct.issued" scheme="ISO8601" content="2012-11- 29">493 <meta name="dct.issued" scheme="ISO8601" content="2012-11-30"> 494 494 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 495 495 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false."> … … 517 517 </tr> 518 518 <tr> 519 <td class="left">Expires: June 2, 2013</td>520 <td class="right">November 29, 2012</td>519 <td class="left">Expires: June 3, 2013</td> 520 <td class="right">November 30, 2012</td> 521 521 </tr> 522 522 </tbody> … … 545 545 in progress”. 546 546 </p> 547 <p>This Internet-Draft will expire on June 2, 2013.</p>547 <p>This Internet-Draft will expire on June 3, 2013.</p> 548 548 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 549 549 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1300 1300 <p id="rfc.section.A.p.3">The <a href="#header.etag" class="smpl">ETag</a> header field ABNF has been changed to not use quoted-string, thus avoiding escaping issues. (<a href="#header.etag" id="rfc.xref.header.etag.3" title="ETag">Section 2.3</a>) 1301 1301 </p> 1302 <p id="rfc.section.A.p.4">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section 5</a>) 1302 <p id="rfc.section.A.p.4">ETag is defined to provide an entity tag for the selected representation, thereby clarifying what it applies to in various 1303 situations (such as a PUT response). (<a href="#header.etag" id="rfc.xref.header.etag.4" title="ETag">Section 2.3</a>) 1304 </p> 1305 <p id="rfc.section.A.p.5">The precedence for evaluation of conditional requests has been defined. (<a href="#precedence" title="Precedence">Section 5</a>) 1303 1306 </p> 1304 1307 <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a> <a id="imported.abnf" href="#imported.abnf">Imported ABNF</a></h1> … … 1383 1386 </li> 1384 1387 <li><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul> 1385 <li>ETag header field <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a> </li>1388 <li>ETag header field <a href="#rfc.xref.header.etag.1">2</a>, <a href="#rfc.iref.e.1"><b>2.3</b></a>, <a href="#rfc.xref.header.etag.2">6.2</a>, <a href="#rfc.xref.header.etag.3">A</a>, <a href="#rfc.xref.header.etag.4">A</a></li> 1386 1389 </ul> 1387 1390 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r2022 r2024 1381 1381 </t> 1382 1382 <t> 1383 ETag is defined to provide an entity tag for the selected representation, 1384 thereby clarifying what it applies to in various situations (such as a 1385 PUT response). 1386 (<xref target="header.etag" />) 1387 </t> 1388 <t> 1383 1389 The precedence for evaluation of conditional requests has been defined. 1384 1390 (<xref target="precedence" />)
Note: See TracChangeset
for help on using the changeset viewer.