Ignore:
Timestamp:
Jul 19, 2010, 4:52:42 AM (9 years ago)
Author:
fielding@…
Message:

regenerate html

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p3-payload.html

    r854 r857  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-07-17">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 3 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
     
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: January 18, 2011</td>
     429               <td class="left">Expires: January 20, 2011</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
     
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">July 17, 2010</td>
     486               <td class="right">July 19, 2010</td>
    487487            </tr>
    488488         </tbody>
     
    510510         in progress”.
    511511      </p>
    512       <p>This Internet-Draft will expire in January 18, 2011.</p>
     512      <p>This Internet-Draft will expire in January 20, 2011.</p>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    650650      </p>
    651651      <ul class="empty">
    652          <li>The mechanism for selecting the appropriate representation when servicing a request. The representation of entities in any
    653             response can be negotiated (including error responses).
    654          </li>
    655       </ul>
    656       <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.e.1"></span>  <dfn>entity</dfn> 
     652         <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can
     653            be negotiated (including error responses).
     654         </li>
     655      </ul>
     656      <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.p.1"></span>  <dfn>payload</dfn> 
    657657      </p>
    658658      <ul class="empty">
    659          <li>The information transferred as the payload of a request or response. An entity consists of metadata in the form of entity-header
    660             fields and content in the form of an entity-body.
     659         <li>The information transferred within a given message is called the payload, consisting of optional payload metadata and an optional
     660            payload body. The payload in HTTP is always a partial or complete representation of some resource, though which resource is
     661            represented is dependent on the type of message (request or response), the request method, and the response status code.
    661662         </li>
    662663      </ul>
     
    664665      </p>
    665666      <ul class="empty">
    666          <li>An entity included with a response that is subject to content negotiation. There may exist multiple representations associated
    667             with a particular response status.
    668          </li>
    669       </ul>
    670       <p id="rfc.section.1.1.p.5"> <span id="rfc.iref.v.1"></span>  <dfn>variant</dfn> 
    671       </p>
    672       <ul class="empty">
    673          <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations
    674             is termed a "variant". Use of the term "variant" does not necessarily imply that the resource is subject to content negotiation.
     667         <li>A representation is information in a format that can be readily communicated from one party to another. For our purposes,
     668            a representation is binary data and its associated metadata. A representation of a resource is information that reflects the
     669            state of that resource, as observed at some point in the past or to be desired at some point in the future.
    675670         </li>
    676671      </ul>
     
    12671262      <div id="rfc.iref.h.7"></div>
    12681263      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<a id="header.content-location" href="#header.content-location">Content-Location</a></h2>
    1269       <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field is used to supply a URI for the entity in the message when it is accessible from
    1270          a location separate from the requested resource's URI.
    1271       </p>
    1272       <p id="rfc.section.5.7.p.2">A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity, especially in the case where a resource has
    1273          multiple entities associated with it, and those entities actually have separate locations by which they might be individually
    1274          accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned.
     1264      <p id="rfc.section.5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this
     1265         message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response
     1266         would contain the same representation that is enclosed as payload in this message.
    12751267      </p>
    12761268      <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span>  <a href="#header.content-location" class="smpl">Content-Location</a>   = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a>
     
    12781270  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12791271                    <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a>
    1280 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request.
    1281          Future requests <em class="bcp14">MAY</em> may be addressed to the Content-Location URI if the desire is to identify the source of that particular entity.
    1282       </p>
    1283       <p id="rfc.section.5.7.p.5"> <a href="p2-semantics.html#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> describes how clients may process the Content-Location header field.
    1284       </p>
    1285       <p id="rfc.section.5.7.p.6">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond
    1286          to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple
    1287          entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>.
    1288       </p>
    1289       <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Effective Request URI.</p>
    1290       <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p>
     1272</pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME
     1273         body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients.
     1274      </p>
     1275      <p id="rfc.section.5.7.p.4">If Content-Location is included in a response message and its value is the same as the Effective Request URI, then the response
     1276         payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics
     1277         when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's
     1278         response contains the new representation of that resource, thereby distinguishing it from representations that might only
     1279         report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the
     1280         need for a subsequent GET request.
     1281      </p>
     1282      <p id="rfc.section.5.7.p.5">If Content-Location is included in a response message and its value differs from the Effective Request URI, then the origin
     1283         server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD
     1284         request, this is an indication that the Effective Request URI identifies a resource that is subject to content negotiation
     1285         and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location
     1286         indicates that this representation contains a report on the action's status and the same report is available (for future access
     1287         with GET) at the given URI. For example, a purchase transaction made via the POST method may include a receipt document as
     1288         the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt
     1289         in the future.
     1290      </p>
     1291      <p id="rfc.section.5.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed
     1292         representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is
     1293         providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated
     1294         resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected
     1295         to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse
     1296         content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the
     1297         latter semantics, it would have applied the PUT directly to the Content-Location URI.
     1298      </p>
     1299      <p id="rfc.section.5.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use
     1300         in other contexts, such as within source links or other metadata.
     1301      </p>
     1302      <p id="rfc.section.5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used
     1303         to respond to later requests on that Content-Location URI.
     1304      </p>
     1305      <p id="rfc.section.5.7.p.9">If the Content-Location value is a partial URI, it is interpreted relative to the Effective Request URI.</p>
    12911306      <div id="rfc.iref.c.10"></div>
    12921307      <div id="rfc.iref.h.8"></div>
     
    17551770      </p>
    17561771      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2>
    1757       <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
     1772      <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not
    17581773         fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
    17591774         and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.
     
    18021817      </p>
    18031818      <p id="rfc.section.C.1.p.3">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce
    1804          it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>.
     1819         it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.3"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>.
    18051820      </p>
    18061821      <p id="rfc.section.C.1.p.4">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section&nbsp;2.2</a>)
    18071822      </p>
    1808       <p id="rfc.section.C.1.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p.1"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
     1823      <p id="rfc.section.C.1.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p.2"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.
    18091824      </p>
    18101825      <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
     
    20732088      </ul>
    20742089      <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1>
    2075       <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>
     2090      <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a>
    20762091      </p>
    20772092      <div class="print2col">
     
    21132128                  <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
    21142129                  <li class="indline1">Derived-From header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.2"><b>C.1</b></a></li>
    2115                </ul>
    2116             </li>
    2117             <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">
    2118                   <li class="indline1">entity&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1">1.1</a></li>
    21192130               </ul>
    21202131            </li>
     
    22282239                     </ul>
    22292240                  </li>
    2230                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#rfc.xref.Part2.2">5.7</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
    2231                         <li class="indline1"><em>Section 6.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">5.7</a></li>
     2241                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
    22322242                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a></li>
    22332243                     </ul>
     
    22412251                     </ul>
    22422252                  </li>
    2243                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#rfc.xref.Part6.4">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">
    2244                         <li class="indline1"><em>Section 2.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">5.7</a></li>
     2253                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind">
    22452254                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li>
    22462255                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.1</a></li>
    22472256                     </ul>
    22482257                  </li>
    2249                   <li class="indline1">Public header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>C.1</b></a></li>
     2258                  <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">1.1</a></li>
     2259                  <li class="indline1">Public header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>C.1</b></a></li>
    22502260               </ul>
    22512261            </li>
     
    22802290                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>
    22812291                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li>
    2282                   <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li>
     2292                  <li class="indline1"><em>RFC2557</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a>, <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.3">C.1</a><ul class="ind">
     2293                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a></li>
     2294                     </ul>
     2295                  </li>
    22832296                  <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">5.4</a>, <a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind">
    22842297                        <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">5.4</a></li>
     
    23142327               </ul>
    23152328            </li>
    2316             <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind">
    2317                   <li class="indline1">variant&nbsp;&nbsp;<a class="iref" href="#rfc.iref.v.1">1.1</a></li>
    2318                </ul>
    2319             </li>
    23202329         </ul>
    23212330      </div>
Note: See TracChangeset for help on using the changeset viewer.