Changeset 163 for draft-ietf-httpbis/latest
- Timestamp:
- 12/01/08 05:09:10 (15 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 12 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r157 r163 618 618 </ul> 619 619 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 620 <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to overall network operation, message framing, interaction with transport 621 protocols, and URI schemes. Right now it only includes the extracted relevant sections of <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 620 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 621 systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, commonly 622 referred to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet with only a single method and no 623 metadata. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metadata about the data 624 transferred and modifiers on the request/response semantics. However, HTTP/1.0 did not sufficiently take into consideration 625 the effects of hierarchical proxies, caching, the need for persistent connections, or name-based virtual hosts. In addition, 626 the proliferation of incompletely-implemented applications calling themselves "HTTP/1.0" necessitated a protocol version change 627 in order for two communicating applications to determine each other's true capabilities. 628 </p> 629 <p id="rfc.section.1.p.2">This document is Part 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1", obsoleting <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent requirements that enable reliable implementations 630 and adding only those new features that will either be safely ignored by an HTTP/1.0 recipient or only sent when communicating 631 with a party advertising compliance with HTTP/1.1. Part 1 defines those aspects of HTTP/1.1 related to overall network operation, 632 message framing, interaction with transport protocols, and URI schemes. 633 </p> 634 <p id="rfc.section.1.p.3">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller 635 errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will 636 be organized according to the typical process of deciding when to use HTTP (URI schemes), overall network operation, connection 637 management, message framing, and generic message parsing. The current mess reflects how widely dispersed these topics and 638 associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 622 639 </p> 623 640 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.purpose" href="#intro.purpose">Purpose</a></h2> 624 <p id="rfc.section.1.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information 625 systems. HTTP has been in use by the World-Wide Web global information initiative since 1990. The first version of HTTP, referred 626 to as HTTP/0.9, was a simple protocol for raw data transfer across the Internet. HTTP/1.0, as defined by <a href="#RFC1945" id="rfc.xref.RFC1945.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.0">[RFC1945]</cite></a>, improved the protocol by allowing messages to be in the format of MIME-like messages, containing metainformation about the 627 data transferred and modifiers on the request/response semantics. However, HTTP/1.0 does not sufficiently take into consideration 628 the effects of hierarchical proxies, caching, the need for persistent connections, or virtual hosts. In addition, the proliferation 629 of incompletely-implemented applications calling themselves "HTTP/1.0" has necessitated a protocol version change in order 630 for two communicating applications to determine each other's true capabilities. 631 </p> 632 <p id="rfc.section.1.1.p.2">This specification defines the protocol referred to as "HTTP/1.1". This protocol includes more stringent requirements than 633 HTTP/1.0 in order to ensure reliable implementation of its features. 634 </p> 635 <p id="rfc.section.1.1.p.3">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. 641 <p id="rfc.section.1.1.p.1">Practical information systems require more functionality than simple retrieval, including search, front-end update, and annotation. 636 642 HTTP allows an open-ended set of methods and headers that indicate the purpose of a request <a href="#RFC2324" id="rfc.xref.RFC2324.1"><cite title="Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)">[RFC2324]</cite></a>. It builds on the discipline of reference provided by the Uniform Resource Identifier (URI) <a href="#RFC1630" id="rfc.xref.RFC1630.1"><cite title="Universal Resource Identifiers in WWW: A Unifying Syntax for the Expression of Names and Addresses of Objects on the Network as used in the World-Wide Web">[RFC1630]</cite></a>, as a location (URL) <a href="#RFC1738" id="rfc.xref.RFC1738.1"><cite title="Uniform Resource Locators (URL)">[RFC1738]</cite></a> or name (URN) <a href="#RFC1737" id="rfc.xref.RFC1737.1"><cite title="Functional Requirements for Uniform Resource Names">[RFC1737]</cite></a>, for indicating the resource to which a method is to be applied. Messages are passed in a format similar to that used by 637 643 Internet mail <a href="#RFC2822" id="rfc.xref.RFC2822.1"><cite title="Internet Message Format">[RFC2822]</cite></a> as defined by the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a>. 638 644 </p> 639 <p id="rfc.section.1.1.p. 4">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems,645 <p id="rfc.section.1.1.p.2">HTTP is also used as a generic protocol for communication between user agents and proxies/gateways to other Internet systems, 640 646 including those supported by the SMTP <a href="#RFC2821" id="rfc.xref.RFC2821.1"><cite title="Simple Mail Transfer Protocol">[RFC2821]</cite></a>, NNTP <a href="#RFC3977" id="rfc.xref.RFC3977.1"><cite title="Network News Transfer Protocol (NNTP)">[RFC3977]</cite></a>, FTP <a href="#RFC959" id="rfc.xref.RFC959.1"><cite title="File Transfer Protocol">[RFC959]</cite></a>, Gopher <a href="#RFC1436" id="rfc.xref.RFC1436.1"><cite title="The Internet Gopher Protocol (a distributed document search and retrieval protocol)">[RFC1436]</cite></a>, and WAIS <a href="#WAIS" id="rfc.xref.WAIS.1"><cite title="WAIS Interface Protocol Prototype Functional Specification (v1.5)">[WAIS]</cite></a> protocols. In this way, HTTP allows basic hypermedia access to resources available from diverse applications. 641 647 </p> … … 1936 1942 </p> 1937 1943 <p id="rfc.section.11.p.5">Thanks to the "cave men" of Palo Alto. You know who you are.</p> 1938 <p id="rfc.section.11.p.6">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616. 2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott1944 <p id="rfc.section.11.p.6">Jim Gettys (the editor of <a href="#RFC2616" id="rfc.xref.RFC2616.3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>) wishes particularly to thank Roy Fielding, the editor of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>, along with John Klensin, Jeff Mogul, Paul Leach, Dave Kristol, Koen Holtman, John Franks, Josh Cohen, Alex Hopmann, Scott 1939 1945 Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the 1940 1946 "MUST/MAY/SHOULD" audit. … … 2381 2387 <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a> Since RFC2616 2382 2388 </h2> 2383 <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616. 3"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.2389 <p id="rfc.section.E.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.4"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 2384 2390 </p> 2385 2391 <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a> Since draft-ietf-httpbis-p1-messaging-00 … … 2671 2677 <li class="indline1"><em>RFC1808</em> <a class="iref" href="#rfc.xref.RFC1808.1">3.2.1</a>, <a class="iref" href="#rfc.xref.RFC1808.2">3.2.1</a>, <a class="iref" href="#RFC1808"><b>12.2</b></a></li> 2672 2678 <li class="indline1"><em>RFC1900</em> <a class="iref" href="#rfc.xref.RFC1900.1">3.2.2</a>, <a class="iref" href="#rfc.xref.RFC1900.2">10.4</a>, <a class="iref" href="#RFC1900"><b>12.2</b></a></li> 2673 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">1 .1</a>, <a class="iref" href="#RFC1945"><b>12.2</b></a></li>2679 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">1</a>, <a class="iref" href="#RFC1945"><b>12.2</b></a></li> 2674 2680 <li class="indline1"><em>RFC2045</em> <a class="iref" href="#rfc.xref.RFC2045.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2045.2">3.4</a>, <a class="iref" href="#rfc.xref.RFC2045.3">11</a>, <a class="iref" href="#RFC2045"><b>12.1</b></a></li> 2675 2681 <li class="indline1"><em>RFC2047</em> <a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li> … … 2685 2691 </ul> 2686 2692 </li> 2687 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1 1</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a></li>2693 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">1</a>, <a class="iref" href="#rfc.xref.RFC2616.3">11</a>, <a class="iref" href="#RFC2616"><b>12.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.4">E.1</a></li> 2688 2694 <li class="indline1"><em>RFC2821</em> <a class="iref" href="#rfc.xref.RFC2821.1">1.1</a>, <a class="iref" href="#RFC2821"><b>12.2</b></a></li> 2689 2695 <li class="indline1"><em>RFC2822</em> <a class="iref" href="#rfc.xref.RFC2822.1">1.1</a>, <a class="iref" href="#rfc.xref.RFC2822.2">4.1</a>, <a class="iref" href="#rfc.xref.RFC2822.3">4.2</a>, <a class="iref" href="#rfc.xref.RFC2822.4">8.3</a>, <a class="iref" href="#rfc.xref.RFC2822.5">8.9</a>, <a class="iref" href="#RFC2822"><b>12.2</b></a><ul class="ind"> -
draft-ietf-httpbis/latest/p1-messaging.xml
r155 r163 227 227 <section title="Introduction" anchor="introduction"> 228 228 <t> 229 This document will define aspects of HTTP related to overall network230 operation, message framing, interaction with transport protocols, and231 URI schemes. Right now it only includes the extracted relevant sections232 of <xref target="RFC2616"/>.233 </t>234 <section title="Purpose" anchor="intro.purpose">235 <t>236 229 The Hypertext Transfer Protocol (HTTP) is an application-level 237 230 protocol for distributed, collaborative, hypermedia information 238 231 systems. HTTP has been in use by the World-Wide Web global 239 information initiative since 1990. The first version of HTTP, 232 information initiative since 1990. The first version of HTTP, commonly 240 233 referred to as HTTP/0.9, was a simple protocol for raw data transfer 241 across the Internet. HTTP/1.0, as defined by <xref target="RFC1945"/>, improved 234 across the Internet with only a single method and no metadata. 235 HTTP/1.0, as defined by <xref target="RFC1945"/>, improved 242 236 the protocol by allowing messages to be in the format of MIME-like 243 messages, containing meta informationabout the data transferred and244 modifiers on the request/response semantics. However, HTTP/1.0 d oes237 messages, containing metadata about the data transferred and 238 modifiers on the request/response semantics. However, HTTP/1.0 did 245 239 not sufficiently take into consideration the effects of hierarchical 246 proxies, caching, the need for persistent connections, or virtual247 hosts. In addition, the proliferation of incompletely-implemented248 applications calling themselves "HTTP/1.0" hasnecessitated a240 proxies, caching, the need for persistent connections, or name-based 241 virtual hosts. In addition, the proliferation of incompletely-implemented 242 applications calling themselves "HTTP/1.0" necessitated a 249 243 protocol version change in order for two communicating applications 250 244 to determine each other's true capabilities. 251 245 </t> 252 246 <t> 253 This specification defines the protocol referred to as "HTTP/1.1". 254 This protocol includes more stringent requirements than HTTP/1.0 in 255 order to ensure reliable implementation of its features. 256 </t> 247 This document is Part 1 of the seven-part specification that defines 248 the protocol referred to as "HTTP/1.1", obsoleting <xref target="RFC2616"/>. 249 HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent 250 requirements that enable reliable implementations and adding only 251 those new features that will either be safely ignored by an HTTP/1.0 252 recipient or only sent when communicating with a party advertising 253 compliance with HTTP/1.1. 254 Part 1 defines those aspects of HTTP/1.1 related to overall network 255 operation, message framing, interaction with transport protocols, and 256 URI schemes. 257 </t> 258 <t> 259 This document is currently disorganized in order to minimize the changes 260 between drafts and enable reviewers to see the smaller errata changes. 261 The next draft will reorganize the sections to better reflect the content. 262 In particular, the sections will be organized according to the typical 263 process of deciding when to use HTTP (URI schemes), overall network operation, 264 connection management, message framing, and generic message parsing. 265 The current mess reflects how widely dispersed these topics and associated 266 requirements had become in <xref target="RFC2616"/>. 267 </t> 268 269 <section title="Purpose" anchor="intro.purpose"> 257 270 <t> 258 271 Practical information systems require more functionality than simple -
draft-ietf-httpbis/latest/p3-payload.html
r161 r163 565 565 </ul> 566 566 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 567 <p id="rfc.section.1.p.1">This document defines HTTP message payloads (a.k.a., content), the associated metadata header fields that define how the payload568 is intended to be interpreted by a recipient, the request header fields that may influence content selection, and the various569 selection algorithms that are collectively referred to as HTTP content negotiation.567 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 message payloads (a.k.a., content), the associated metadata header fields that define how the 568 payload is intended to be interpreted by a recipient, the request header fields that may influence content selection, and 569 the various selection algorithms that are collectively referred to as HTTP content negotiation. 570 570 </p> 571 571 <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller -
draft-ietf-httpbis/latest/p3-payload.xml
r161 r163 214 214 <section title="Introduction" anchor="introduction"> 215 215 <t> 216 This document defines HTTP message payloads (a.k.a., content), the216 This document defines HTTP/1.1 message payloads (a.k.a., content), the 217 217 associated metadata header fields that define how the payload is intended 218 218 to be interpreted by a recipient, the request header fields that -
draft-ietf-httpbis/latest/p4-conditional.html
r160 r163 521 521 </ul> 522 522 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 523 <p id="rfc.section.1.p.1">This document defines aspects of HTTP related to conditional request messages based on time stamps and entity-tags. Right 524 now it only includes the extracted relevant sections of <a href="#RFC2616">RFC 2616</a> <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">[RFC2616]</cite> with only minor changes. This introduction will be revised in the next draft. 523 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 response metadata for indicating potential changes to payload content, including modification 524 time stamps and opaque entity-tags, and the HTTP conditional request mechanisms that allow preconditions to be placed on a 525 request method. Conditional GET requests allow for efficient cache updates. Other conditional request methods are used to 526 protect against overwriting or misunderstanding the state of a resource that has been changed unbeknownst to the requesting 527 client. 528 </p> 529 <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller 530 errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections on 531 resource metadata will be discussed first and then followed by each conditional request-header, concluding with a definition 532 of precedence and the expectation of ordering strong validator checks before weak validator checks. It is likely that more 533 content from <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> will migrate to this part, where appropriate. The current mess reflects how widely dispersed these topics and associated requirements 534 had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>. 525 535 </p> 526 536 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 756 766 header <em class="bcp14">MUST</em> be ignored. 757 767 </p> 758 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6. 1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist.768 <p id="rfc.section.6.2.p.7">The meaning of "If-Match: *" is that the method <em class="bcp14">SHOULD</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">MUST NOT</em> be performed if the representation does not exist. 759 769 </p> 760 770 <p id="rfc.section.6.2.p.8">A request intended to update a resource (e.g., a PUT) <em class="bcp14">MAY</em> include an If-Match header field to signal that the request method <em class="bcp14">MUST NOT</em> be applied if the entity corresponding to the If-Match value (a single entity tag) is no longer a representation of that resource. … … 837 847 If-None-Match header <em class="bcp14">MUST</em> be ignored. (See <a href="#rules.for.when.to.use.entity.tags.and.last-modified.dates" title="Rules for When to Use Entity Tags and Last-Modified Dates">Section 5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.) 838 848 </p> 839 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6. 2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations.849 <p id="rfc.section.6.4.p.8">The meaning of "If-None-Match: *" is that the method <em class="bcp14">MUST NOT</em> be performed if the representation selected by the origin server (or by a cache, possibly using the Vary mechanism, see <a href="p6-cache.html#header.vary" title="Vary">Section 15.5</a> of <a href="#Part6" id="rfc.xref.Part6.3"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) exists, and <em class="bcp14">SHOULD</em> be performed if the representation does not exist. This feature is intended to be useful in preventing races between PUT operations. 840 850 </p> 841 851 <p id="rfc.section.6.4.p.9">Examples:</p> … … 1064 1074 </ul> 1065 1075 </li> 1066 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1"> 6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind">1067 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6. 1">6.2</a>, <a class="iref" href="#rfc.xref.Part6.2">6.4</a></li>1076 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1</a>, <a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a>, <a class="iref" href="#Part6"><b>10.1</b></a><ul class="ind"> 1077 <li class="indline1"><em>Section 15.5</em> <a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li> 1068 1078 </ul> 1069 1079 </li> -
draft-ietf-httpbis/latest/p4-conditional.xml
r160 r163 16 16 <!ENTITY ID-YEAR "2008"> 17 17 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 <!ENTITY caching "<xref target='Part6' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY header-if-range "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 20 <!ENTITY header-range "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 208 209 <section title="Introduction" anchor="introduction"> 209 210 <t> 210 This document defines aspects of HTTP related to conditional 211 request messages based on time stamps and entity-tags. Right now it 212 only includes the extracted relevant sections of <xref target="RFC2616">RFC 2616</xref> 213 with only minor changes. This introduction will be revised in the next draft. 211 This document defines HTTP/1.1 response metadata for indicating potential 212 changes to payload content, including modification time stamps and opaque 213 entity-tags, and the HTTP conditional request mechanisms that allow 214 preconditions to be placed on a request method. Conditional GET requests 215 allow for efficient cache updates. Other conditional request methods are 216 used to protect against overwriting or misunderstanding the state of a 217 resource that has been changed unbeknownst to the requesting client. 218 </t> 219 <t> 220 This document is currently disorganized in order to minimize the changes 221 between drafts and enable reviewers to see the smaller errata changes. 222 The next draft will reorganize the sections to better reflect the content. 223 In particular, the sections on resource metadata will be discussed first 224 and then followed by each conditional request-header, concluding with a 225 definition of precedence and the expectation of ordering strong validator 226 checks before weak validator checks. It is likely that more content from 227 &caching; will migrate to this part, where appropriate. 228 The current mess reflects how widely dispersed these topics and associated 229 requirements had become in <xref target="RFC2616"/>. 214 230 </t> 215 231 -
draft-ietf-httpbis/latest/p5-range.html
r159 r163 530 530 to be rendered by a device with limited local storage. 531 531 </p> 532 <p id="rfc.section.1.p.2">This document defines aspects of HTTP/1.1 related to range requests, partial responses, and the multipart/byteranges media533 type. The protocol for range requests is an <em class="bcp14">OPTIONAL</em> feature of HTTP/1.1, designed so resources or recipients that do not implement this feature can respond as if it is a normal534 GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken535 f or full responses by intermediate caches that might not implement the feature.536 </p> 537 <p id="rfc.section.1.p.3">Although the HTTP /1.1range request mechanism is designed to allow for extensible range types, this specification only defines532 <p id="rfc.section.1.p.2">This document defines HTTP/1.1 range requests, partial responses, and the multipart/byteranges media type. The protocol for 533 range requests is an <em class="bcp14">OPTIONAL</em> feature of HTTP, designed so resources or recipients that do not implement this feature can respond as if it is a normal GET 534 request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken for 535 full responses by intermediate caches that might not implement the feature. 536 </p> 537 <p id="rfc.section.1.p.3">Although the HTTP range request mechanism is designed to allow for extensible range types, this specification only defines 538 538 requests for byte ranges. 539 539 </p> -
draft-ietf-httpbis/latest/p5-range.xml
r159 r163 215 215 </t> 216 216 <t> 217 This document defines aspects of HTTP/1.1 related torange requests,217 This document defines HTTP/1.1 range requests, 218 218 partial responses, and the multipart/byteranges media type. 219 The protocol for range requests is an &OPTIONAL; feature of HTTP /1.1,219 The protocol for range requests is an &OPTIONAL; feature of HTTP, 220 220 designed so resources or recipients that do not implement this feature 221 221 can respond as if it is a normal GET request without impacting … … 225 225 </t> 226 226 <t> 227 Although the HTTP /1.1range request mechanism is designed to allow for227 Although the HTTP range request mechanism is designed to allow for 228 228 extensible range types, this specification only defines requests for 229 229 byte ranges. -
draft-ietf-httpbis/latest/p6-cache.html
r157 r163 573 573 </ul> 574 574 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="caching" href="#caching">Introduction</a></h1> 575 <p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches. 576 The HTTP/1.1 protocol includes a number of elements intended to make caching work as well as possible. Because these elements 577 are inextricable from other aspects of the protocol, and because they interact with each other, it is useful to describe the 578 basic caching design of HTTP separately from the detailed descriptions of methods, headers, response codes, etc. This document 579 defines aspects of HTTP related to caching response messages. 575 <p id="rfc.section.1.p.1">HTTP is typically used for distributed information systems, where performance can be improved by the use of response caches, 576 and includes a number of elements intended to make caching work as well as possible. Because these elements interact with 577 each other, it is useful to describe the caching design of HTTP separately. This document defines aspects of HTTP/1.1 related 578 to caching and reusing response messages. 580 579 </p> 581 580 <div id="rfc.iref.c.1"></div> -
draft-ietf-httpbis/latest/p6-cache.xml
r157 r163 218 218 <t> 219 219 HTTP is typically used for distributed information systems, where 220 performance can be improved by the use of response caches. The 221 HTTP/1.1 protocol includes a number of elements intended to make 222 caching work as well as possible. Because these elements are 223 inextricable from other aspects of the protocol, and because they 224 interact with each other, it is useful to describe the basic caching 225 design of HTTP separately from the detailed descriptions of methods, 226 headers, response codes, etc. This document defines aspects of HTTP 227 related to caching response messages. 220 performance can be improved by the use of response caches, and includes 221 a number of elements intended to make caching work as well as possible. 222 Because these elements interact with each other, it is useful to describe 223 the caching design of HTTP separately. This document defines aspects of 224 HTTP/1.1 related to caching and reusing response messages. 228 225 </t> 229 226 -
draft-ietf-httpbis/latest/p7-auth.html
r156 r163 517 517 </ul> 518 518 <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a> <a id="introduction" href="#introduction">Introduction</a></h1> 519 <p id="rfc.section.1.p.1">This document defines aspects of HTTP related to access control and authentication. Right now it only includes the extracted 520 relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> with editorial changes. 519 <p id="rfc.section.1.p.1">This document defines HTTP/1.1 access control and authentication. Right now it includes the extracted relevant sections of <cite title="Hypertext Transfer Protocol -- HTTP/1.1" id="rfc.xref.RFC2616.1">RFC 2616</cite> with only minor changes. The intention is to move the general framework for HTTP authentication here, as currently specified 520 in <a href="#RFC2617" id="rfc.xref.RFC2617.1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>, and allow the individual authentication mechanisms to be defined elsewhere. This introduction will be rewritten when that 521 occurs. 521 522 </p> 522 523 <p id="rfc.section.1.p.2">HTTP provides several <em class="bcp14">OPTIONAL</em> challenge-response authentication mechanisms which can be used by a server to challenge a client request and by a client to 523 524 provide authentication information. The general framework for access authentication, and the specification of "basic" and 524 "digest" authentication, are specified in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 1"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. This specification adopts the definitions of "challenge" and "credentials" from that specification.525 "digest" authentication, are specified in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. This specification adopts the definitions of "challenge" and "credentials" from that specification. 525 526 </p> 526 527 <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a> <a id="intro.requirements" href="#intro.requirements">Requirements</a></h2> … … 538 539 refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has 539 540 already attempted authentication at least once, then the user <em class="bcp14">SHOULD</em> be presented the entity that was given in the response, since that entity might include relevant diagnostic information. HTTP 540 access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 2"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.541 access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.3"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 541 542 </p> 542 543 <div id="rfc.iref.1"></div> … … 544 545 <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a> <a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2> 545 546 <p id="rfc.section.2.2.p.1">This code is similar to 401 (Unauthorized), but indicates that the client must first authenticate itself with the proxy. The 546 proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 3.2</a>) containing a challenge applicable to the proxy for the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 3"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>.547 proxy <em class="bcp14">MUST</em> return a Proxy-Authenticate header field (<a href="#header.proxy-authenticate" id="rfc.xref.header.proxy-authenticate.1" title="Proxy-Authenticate">Section 3.2</a>) containing a challenge applicable to the proxy for the requested resource. The client <em class="bcp14">MAY</em> repeat the request with a suitable Proxy-Authorization header field (<a href="#header.proxy-authorization" id="rfc.xref.header.proxy-authorization.1" title="Proxy-Authorization">Section 3.3</a>). HTTP access authentication is explained in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 547 548 </p> 548 549 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="header.fields" href="#header.fields">Header Field Definitions</a></h1> … … 556 557 </p> 557 558 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span> Authorization = "Authorization" ":" credentials 558 </pre><p id="rfc.section.3.1.p.3">HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 4"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 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,559 </pre><p id="rfc.section.3.1.p.3">HTTP access authentication is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. 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, 559 560 such as credentials that vary according to a challenge value or using synchronized clocks). 560 561 </p> … … 579 580 </p> 580 581 <div id="rfc.figure.u.2"></div><pre class="inline"><span id="rfc.iref.g.2"></span> Proxy-Authenticate = "Proxy-Authenticate" ":" 1#challenge 581 </pre><p id="rfc.section.3.2.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 5"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and <em class="bcp14">SHOULD NOT</em> be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting582 </pre><p id="rfc.section.3.2.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. Unlike WWW-Authenticate, the Proxy-Authenticate header field applies only to the current connection and <em class="bcp14">SHOULD NOT</em> be passed on to downstream clients. However, an intermediate proxy might need to obtain its own credentials by requesting 582 583 them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate 583 584 header field. … … 591 592 </p> 592 593 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span> Proxy-Authorization = "Proxy-Authorization" ":" credentials 593 </pre><p id="rfc.section.3.3.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 6"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication594 </pre><p id="rfc.section.3.3.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.7"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. Unlike Authorization, the Proxy-Authorization header field applies only to the next outbound proxy that demanded authentication 594 595 using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed 595 596 by the first outbound proxy that was expecting to receive credentials. A proxy <em class="bcp14">MAY</em> relay the credentials from the client request to the next proxy if that is the mechanism by which the proxies cooperatively … … 603 604 </p> 604 605 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.4"></span> WWW-Authenticate = "WWW-Authenticate" ":" 1#challenge 605 </pre><p id="rfc.section.3.4.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617. 7"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one606 </pre><p id="rfc.section.3.4.p.3">The HTTP access authentication process is described in "HTTP Authentication: Basic and Digest Access Authentication" <a href="#RFC2617" id="rfc.xref.RFC2617.8"><cite title="HTTP Authentication: Basic and Digest Access Authentication">[RFC2617]</cite></a>. User agents are advised to take special care in parsing the WWW-Authenticate field value as it might contain more than one 606 607 challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a 607 608 comma-separated list of authentication parameters. … … 771 772 <li class="indline1"><em>RFC2119</em> <a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>7.1</b></a></li> 772 773 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>7.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li> 773 <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">1</a>, <a class="iref" href="#rfc.xref.RFC2617.2"> 2.1</a>, <a class="iref" href="#rfc.xref.RFC2617.3">2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.4">3.1</a>, <a class="iref" href="#rfc.xref.RFC2617.5">3.2</a>, <a class="iref" href="#rfc.xref.RFC2617.6">3.3</a>, <a class="iref" href="#rfc.xref.RFC2617.7">3.4</a>, <a class="iref" href="#RFC2617"><b>7.1</b></a></li>774 <li class="indline1"><em>RFC2617</em> <a class="iref" href="#rfc.xref.RFC2617.1">1</a>, <a class="iref" href="#rfc.xref.RFC2617.2">1</a>, <a class="iref" href="#rfc.xref.RFC2617.3">2.1</a>, <a class="iref" href="#rfc.xref.RFC2617.4">2.2</a>, <a class="iref" href="#rfc.xref.RFC2617.5">3.1</a>, <a class="iref" href="#rfc.xref.RFC2617.6">3.2</a>, <a class="iref" href="#rfc.xref.RFC2617.7">3.3</a>, <a class="iref" href="#rfc.xref.RFC2617.8">3.4</a>, <a class="iref" href="#RFC2617"><b>7.1</b></a></li> 774 775 </ul> 775 776 </li> -
draft-ietf-httpbis/latest/p7-auth.xml
r156 r163 202 202 <section title="Introduction" anchor="introduction"> 203 203 <t> 204 This document defines aspects of HTTP related to access control and 205 authentication. Right now it only includes the extracted relevant sections 206 of <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with editorial changes. 204 This document defines HTTP/1.1 access control and authentication. Right now it 205 includes the extracted relevant sections of 206 <xref target="RFC2616" x:fmt="none">RFC 2616</xref> with only minor changes. 207 The intention is to move the general framework for HTTP authentication here, 208 as currently specified in <xref target="RFC2617"/>, and allow the individual 209 authentication mechanisms to be defined elsewhere. This introduction will 210 be rewritten when that occurs. 207 211 </t> 208 212 <t>
Note: See TracChangeset
for help on using the changeset viewer.