Ignore:
Timestamp:
Jan 11, 2008, 9:09:10 PM (12 years ago)
Author:
fielding@…
Message:

editorial: make introductions more active and consistent

Location:
draft-ietf-httpbis/latest
Files:
12 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r157 r163  
    618618      </ul>
    619619      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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>.
    622639      </p>
    623640      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<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.
    636642         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
    637643         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>.
    638644      </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,
    640646         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.
    641647      </p>
    … …  
    19361942      </p>
    19371943      <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, Scott
     1944      <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
    19391945         Lawrence, and Larry Masinter for their help. And thanks go particularly to Jeff Mogul and Scott Lawrence for performing the
    19401946         "MUST/MAY/SHOULD" audit.
    … …  
    23812387      <h2 id="rfc.section.E.1"><a href="#rfc.section.E.1">E.1</a>&nbsp;Since RFC2616
    23822388      </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>.
    23842390      </p>
    23852391      <h2 id="rfc.section.E.2"><a href="#rfc.section.E.2">E.2</a>&nbsp;Since draft-ietf-httpbis-p1-messaging-00
    … …  
    26712677                  <li class="indline1"><em>RFC1808</em>&nbsp;&nbsp;<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>
    26722678                  <li class="indline1"><em>RFC1900</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC1945.1">1</a>, <a class="iref" href="#RFC1945"><b>12.2</b></a></li>
    26742680                  <li class="indline1"><em>RFC2045</em>&nbsp;&nbsp;<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>
    26752681                  <li class="indline1"><em>RFC2047</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2047.1">2.2</a>, <a class="iref" href="#RFC2047"><b>12.1</b></a></li>
    … …  
    26852691                     </ul>
    26862692                  </li>
    2687                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">11</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>&nbsp;&nbsp;<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>
    26882694                  <li class="indline1"><em>RFC2821</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2821.1">1.1</a>, <a class="iref" href="#RFC2821"><b>12.2</b></a></li>
    26892695                  <li class="indline1"><em>RFC2822</em>&nbsp;&nbsp;<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  
    227227<section title="Introduction" anchor="introduction">
    228228<t>
    229    This document will define aspects of HTTP related to overall network
    230    operation, message framing, interaction with transport protocols, and
    231    URI schemes. Right now it only includes the extracted relevant sections
    232    of <xref target="RFC2616"/>.
    233 </t>
    234 <section title="Purpose" anchor="intro.purpose">
    235 <t>
    236229   The Hypertext Transfer Protocol (HTTP) is an application-level
    237230   protocol for distributed, collaborative, hypermedia information
    238231   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
    240233   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
    242236   the protocol by allowing messages to be in the format of MIME-like
    243    messages, containing metainformation about the data transferred and
    244    modifiers on the request/response semantics. However, HTTP/1.0 does
     237   messages, containing metadata about the data transferred and
     238   modifiers on the request/response semantics. However, HTTP/1.0 did
    245239   not sufficiently take into consideration the effects of hierarchical
    246    proxies, caching, the need for persistent connections, or virtual
    247    hosts. In addition, the proliferation of incompletely-implemented
    248    applications calling themselves "HTTP/1.0" has necessitated a
     240   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
    249243   protocol version change in order for two communicating applications
    250244   to determine each other's true capabilities.
    251245</t>
    252246<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">
    257270<t>
    258271   Practical information systems require more functionality than simple

  • draft-ietf-httpbis/latest/p3-payload.html

    r161 r163  
    565565      </ul>
    566566      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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 payload
    568          is intended to be interpreted by a recipient, the request header fields that may influence content selection, and the various
    569          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.
    570570      </p>
    571571      <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  
    214214<section title="Introduction" anchor="introduction">
    215215<t>
    216    This document defines HTTP message payloads (a.k.a., content), the
     216   This document defines HTTP/1.1 message payloads (a.k.a., content), the
    217217   associated metadata header fields that define how the payload is intended
    218218   to be interpreted by a recipient, the request header fields that

  • draft-ietf-httpbis/latest/p4-conditional.html

    r160 r163  
    521521      </ul>
    522522      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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>.
    525535      </p>
    526536      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    … …  
    756766         header <em class="bcp14">MUST</em> be ignored.
    757767      </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.
    759769      </p>
    760770      <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.
    … …  
    837847         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&nbsp;5</a> for a discussion of server behavior when both If-Modified-Since and If-None-Match appear in the same request.)
    838848      </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.
    840850      </p>
    841851      <p id="rfc.section.6.4.p.9">Examples:</p>
    … …  
    10641074                     </ul>
    10651075                  </li>
    1066                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.2">6.2</a>, <a class="iref" href="#rfc.xref.Part6.3">6.4</a></li>
    10681078                     </ul>
    10691079                  </li>

  • draft-ietf-httpbis/latest/p4-conditional.xml

    r160 r163  
    1616  <!ENTITY ID-YEAR "2008">
    1717  <!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'/>">
    1819  <!ENTITY header-if-range            "<xref target='Part5' x:rel='#header.if-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    1920  <!ENTITY header-range               "<xref target='Part5' x:rel='#header.range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    … …  
    208209<section title="Introduction" anchor="introduction">
    209210<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"/>.
    214230</t>
    215231

  • draft-ietf-httpbis/latest/p5-range.html

    r159 r163  
    530530         to be rendered by a device with limited local storage.
    531531      </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 media
    533          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 normal
    534          GET request without impacting interoperability. Partial responses are indicated by a distinct status code to not be mistaken
    535          for 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.1 range request mechanism is designed to allow for extensible range types, this specification only defines
     532      <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
    538538         requests for byte ranges.
    539539      </p>

  • draft-ietf-httpbis/latest/p5-range.xml

    r159 r163  
    215215</t>
    216216<t>
    217    This document defines aspects of HTTP/1.1 related to range requests,
     217   This document defines HTTP/1.1 range requests,
    218218   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,
    220220   designed so resources or recipients that do not implement this feature
    221221   can respond as if it is a normal GET request without impacting
    … …  
    225225</t>
    226226<t>
    227    Although the HTTP/1.1 range request mechanism is designed to allow for
     227   Although the HTTP range request mechanism is designed to allow for
    228228   extensible range types, this specification only defines requests for
    229229   byte ranges.

  • draft-ietf-httpbis/latest/p6-cache.html

    r157 r163  
    573573      </ul>
    574574      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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.
    580579      </p>
    581580      <div id="rfc.iref.c.1"></div>

  • draft-ietf-httpbis/latest/p6-cache.xml

    r157 r163  
    218218<t>
    219219   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.
    228225</t>
    229226

  • draft-ietf-httpbis/latest/p7-auth.html

    r156 r163  
    517517      </ul>
    518518      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<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.
    521522      </p>
    522523      <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
    523524         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.
    525526      </p>
    526527      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
    … …  
    538539         refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has
    539540         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>.
    541542      </p>
    542543      <div id="rfc.iref.1"></div>
    … …  
    544545      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="status.407" href="#status.407">407 Proxy Authentication Required</a></h2>
    545546      <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&nbsp;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&nbsp;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&nbsp;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&nbsp;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>.
    547548      </p>
    548549      <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
    … …  
    556557      </p>
    557558      <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,
    559560         such as credentials that vary according to a challenge value or using synchronized clocks).
    560561      </p>
    … …  
    579580      </p>
    580581      <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 requesting
     582</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
    582583         them from the downstream client, which in some circumstances will appear as if the proxy is forwarding the Proxy-Authenticate
    583584         header field.
    … …  
    591592      </p>
    592593      <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 authentication
     594</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
    594595         using the Proxy-Authenticate field. When multiple proxies are used in a chain, the Proxy-Authorization header field is consumed
    595596         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
    … …  
    603604      </p>
    604605      <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 one
     606</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
    606607         challenge, or if more than one WWW-Authenticate header field is provided, the contents of a challenge itself can contain a
    607608         comma-separated list of authentication parameters.
    … …  
    771772                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>7.1</b></a></li>
    772773                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>
    774775               </ul>
    775776            </li>

  • draft-ietf-httpbis/latest/p7-auth.xml

    r156 r163  
    202202<section title="Introduction" anchor="introduction">
    203203<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.
    207211</t>
    208212<t>
Note: See TracChangeset for help on using the changeset viewer.