Ignore:
Timestamp:
10/01/13 13:17:23 (10 years ago)
Author:
fielding@…
Message:

(editorial) add 1xx and 2xx definitions in prose; add description of payload in 200 response to unusual methods; clarify that ETag and Last-Modified provide metadata about the state of the selected representation at the conclusion of handling a response

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

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.html

    r2104 r2105  
    23832383      <div id="rfc.iref.70"></div>
    23842384      <div id="rfc.iref.s.2"></div>
    2385       <p id="rfc.section.6.2.p.1">This class of status code indicates an interim response, consisting only of the status-line and optional header fields, and
    2386          is terminated by an empty line. There are no required header fields for this class of status code. Since HTTP/1.0 did not
    2387          define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
    2388       </p>
    2389       <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a regular response, even if the client does not expect a <a href="#status.100" class="smpl">100
    2390             (Continue)</a> status message. Unexpected 1xx status responses <em class="bcp14">MAY</em> be ignored by a user agent.
     2385      <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
     2386         the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
     2387         and thus are terminated by the empty line at the end of the header block. There are no required header fields for this class
     2388         of status code. Since HTTP/1.0 did not define any 1xx status codes, servers <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client except under experimental conditions.
     2389      </p>
     2390      <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be prepared to accept one or more 1xx status responses prior to a final response, even if the client does not expect a <a href="#status.100" class="smpl">100 (Continue)</a> status message. A user agent <em class="bcp14">MAY</em> ignore unexpected 1xx status responses.
    23912391      </p>
    23922392      <p id="rfc.section.6.2.p.3">Proxies <em class="bcp14">MUST</em> forward 1xx responses, unless the connection between the proxy and its client has been closed, or unless the proxy itself
    2393          requested the generation of the 1xx response. (For example, if a proxy adds an "Expect: 100-continue" field when it forwards
    2394          a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).)
     2393         requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" field when it forwards
     2394         a request, then it need not forward the corresponding <a href="#status.100" class="smpl">100 (Continue)</a> response(s).
    23952395      </p>
    23962396      <div id="rfc.iref.71"></div>
    … …  
    24152415      <div id="rfc.iref.71"></div>
    24162416      <div id="rfc.iref.s.3"></div>
    2417       <p id="rfc.section.6.3.p.1">This class of status code indicates that the client's request was successfully received, understood, and accepted.</p>
     2417      <p id="rfc.section.6.3.p.1">The <dfn>2xx (Successful)</dfn> class of status code indicates that the client's request was successfully received, understood, and accepted.
     2418      </p>
    24182419      <div id="rfc.iref.72"></div>
    24192420      <h3 id="rfc.section.6.3.1"><a href="#rfc.section.6.3.1">6.3.1</a>&nbsp;<a id="status.200" href="#status.200">200 OK</a></h3>
    24202421      <p id="rfc.section.6.3.1.p.1">The <dfn>200 (OK)</dfn> status code indicates that the request has succeeded. The meaning of a payload sent in the response depends on the request
    2421          method, as follows:
     2422         method. For the methods defined by this specification, the payload can be summarized as:
    24222423      </p>
    24232424      <dl>
    … …  
    24282429         <dd>the same representation as GET, but without the representation data;</dd>
    24292430         <dt>POST</dt>
    2430          <dd>a representation describing or containing the result of the action;</dd>
     2431         <dd>a representation of the status of, or results obtained from, the action;</dd>
     2432         <dt>PUT, DELETE</dt>
     2433         <dd>a representation of the status of the action;</dd>
     2434         <dt>OPTIONS</dt>
     2435         <dd>a representation of the communications options;</dd>
    24312436         <dt>TRACE</dt>
    2432          <dd>a representation containing the request message as received by the end server.</dd>
     2437         <dd>a representation of the request message as received by the end server.</dd>
    24332438      </dl>
    2434       <p id="rfc.section.6.3.1.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
     2439      <p id="rfc.section.6.3.1.p.2">Aside from responses to CONNECT, a 200 response always has a payload, though an origin server <em class="bcp14">MAY</em> generate a payload body of zero length. If no payload is desired, an origin server ought to send <dfn>204 (No Content)</dfn> instead. For CONNECT, no payload is allowed because the successful result is a tunnel, which begins immediately after the
     2440         200 response header block.
     2441      </p>
     2442      <p id="rfc.section.6.3.1.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 4.1.2</a> of <a href="#Part6" id="rfc.xref.Part6.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[Part6]</cite></a>) to determine freshness for 200 responses.
    24352443      </p>
    24362444      <div id="rfc.iref.72"></div>
    24372445      <h3 id="rfc.section.6.3.2"><a href="#rfc.section.6.3.2">6.3.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
    2438       <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created.
    2439       </p>
    2440       <p id="rfc.section.6.3.2.p.2">Newly created resources are typically linked to from the response payload, with the most relevant URI also being carried in
    2441          the <a href="#header.location" class="smpl">Location</a> header field. If the newly created resource's URI is the same as the effective request URI, the Location field can be omitted.
    2442       </p>
    2443       <p id="rfc.section.6.3.2.p.3">If an <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> header field is present in a 201 response, its field value is the entity-tag for the representation created, which is the
    2444          new representation of the resource identified by either the <a href="#header.location" class="smpl">Location</a> header field or, if no Location header field is received, by the effective request URI (see <a href="p4-conditional.html#header.etag" title="ETag">Section 2.3</a> of <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>).
     2446      <p id="rfc.section.6.3.2.p.1">The <dfn>201 (Created)</dfn> status code indicates that the request has been fulfilled and has resulted in one or more new resources being created. The
     2447         primary resource created by the request is identified by either a <a href="#header.location" class="smpl">Location</a> header field in the response or, if no <a href="#header.location" class="smpl">Location</a> field is received, by the effective request URI.
     2448      </p>
     2449      <p id="rfc.section.6.3.2.p.2">The 201 response payload typically describes and links to the resource(s) created. See <a href="#selected.representation" title="Selected Representation Header Fields">Section&nbsp;7.2</a> for discussion of the meaning and purpose of selected representation header fields, such as <a href="p4-conditional.html#header.etag" class="smpl">ETag</a> and Last-Modified, in a 201 response.
    24452450      </p>
    24462451      <div id="rfc.iref.72"></div>
    … …  
    24752480         that the user agent does not need to traverse away from its current "document view" (if any). The server assumes that the
    24762481         user agent will provide some indication of the success to its user, in accord with its own interface, and apply any new or
    2477          updated metadata in the response to the active representation.
     2482         updated metadata in the response to its active representation.
    24782483      </p>
    24792484      <p id="rfc.section.6.3.5.p.4">For example, a 204 status code is commonly used with document editing interfaces corresponding to a "save" action, such that
    … …  
    29942999      <div id="rfc.iref.s.7"></div>
    29953000      <h2 id="rfc.section.7.2"><a href="#rfc.section.7.2">7.2</a>&nbsp;<a id="selected.representation" href="#selected.representation">Selected Representation Header Fields</a></h2>
    2996       <p id="rfc.section.7.2.p.1">We use the term "<dfn>selected representation</dfn>" to refer to the the current representation of the <a href="#resources" class="smpl">target resource</a> that would have been selected in a successful response if the same request had used the method GET and excluded any conditional
    2997          request header fields.
    2998       </p>
    2999       <p id="rfc.section.7.2.p.2">Additional header fields define metadata about the selected representation, which might differ from the representation included
    3000          in the message for responses to some state-changing methods. The following header fields are defined as selected representation
    3001          metadata:
     3001      <p id="rfc.section.7.2.p.1">We use the term "<dfn>selected representation</dfn>" to refer to the representation of the <a href="#resources" class="smpl">target resource</a> in a <a href="#status.200" class="smpl">200 (OK)</a> response to <a href="#GET" class="smpl">GET</a>, or the representation that would have been selected in a successful response if the request had used the method <a href="#GET" class="smpl">GET</a> and excluded any conditional request header fields.
     3002      </p>
     3003      <p id="rfc.section.7.2.p.2">The following header fields define metadata about the selected representation at the conclusion of handling the request. In
     3004         other words, for a successful response to a state-changing method, these fields describe the new representation that has replaced
     3005         the prior selected representation. For example, an ETag header field in a 201 response communicates the entity-tag of the
     3006         newly created resource's representation, so that it can be used in later conditional requests to prevent the "lost update"
     3007         problem <a href="#Part4" id="rfc.xref.Part4.10"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests">[Part4]</cite></a>.
    30023008      </p>
    30033009      <div id="rfc.table.u.11">
    … …  
    44934499            </li>
    44944500            <li><a id="rfc.index.G" href="#rfc.index.G"><b>G</b></a><ul>
    4495                   <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
     4501                  <li>GET method&nbsp;&nbsp;<a href="#rfc.xref.GET.1">3.3</a>, <a href="#rfc.xref.GET.2">4.1</a>, <a href="#rfc.iref.g.16"><b>4.3.1</b></a>, <a href="#rfc.extref.g.4">7.2</a>, <a href="#rfc.extref.g.5">7.2</a>, <a href="#rfc.xref.GET.3">8.1.3</a>, <a href="#rfc.xref.GET.4">B</a></li>
    44964502                  <li><tt>Grammar</tt>&nbsp;&nbsp;
    44974503                     <ul>
    … …  
    46124618                     </ul>
    46134619                  </li>
    4614                   <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
     4620                  <li><em>Part4</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.1">4.3.1</a>, <a href="#rfc.xref.Part4.2">5.2</a>, <a href="#rfc.xref.Part4.3">5.2</a>, <a href="#rfc.xref.Part4.4">5.2</a>, <a href="#rfc.xref.Part4.5">5.2</a>, <a href="#rfc.xref.Part4.6">5.2</a>, <a href="#rfc.xref.Part4.7">6.1</a>, <a href="#rfc.xref.Part4.8">6.1</a>, <a href="#rfc.xref.Part4.9">6.1</a>, <a href="#rfc.xref.Part4.10">7.2</a>, <a href="#rfc.xref.Part4.11">7.2</a>, <a href="#rfc.xref.Part4.12">7.2</a>, <a href="#rfc.xref.Part4.13">8.1.2</a>, <a href="#Part4"><b>11.1</b></a><ul>
    46154621                        <li><em>Section 2.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.12">7.2</a></li>
    4616                         <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.10">6.3.2</a>, <a href="#rfc.xref.Part4.11">7.2</a></li>
     4622                        <li><em>Section 2.3</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.11">7.2</a></li>
    46174623                        <li><em>Section 3.1</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.3">5.2</a></li>
    46184624                        <li><em>Section 3.2</em>&nbsp;&nbsp;<a href="#rfc.xref.Part4.4">5.2</a></li>

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2104 r2105  
    26332633  <iref primary="true" item="Status Codes Classes" subitem="1xx Informational" x:for-anchor=""/>
    26342634<t>
    2635    This class of status code indicates an interim response,
    2636    consisting only of the status-line and optional header fields, and is
    2637    terminated by an empty line. There are no required header fields for this
    2638    class of status code. Since HTTP/1.0 did not define any 1xx status
    2639    codes, servers &MUST-NOT; send a 1xx response to an HTTP/1.0 client
    2640    except under experimental conditions.
     2635   The <x:dfn>1xx (Informational)</x:dfn> class of status code indicates an
     2636   interim response for communicating connection status or request progress
     2637   prior to completing the requested action and sending a final response.
     2638   All 1xx responses consist of only the status-line and optional header
     2639   fields, and thus are terminated by the empty line at the end of the header
     2640   block. There are no required header fields for this class of status code.
     2641   Since HTTP/1.0 did not define any 1xx status codes, servers &MUST-NOT; send
     2642   a 1xx response to an HTTP/1.0 client except under experimental conditions.
    26412643</t>
    26422644<t>
    26432645   A client &MUST; be prepared to accept one or more 1xx status responses
    2644    prior to a regular response, even if the client does not expect a <x:ref>100
    2645    (Continue)</x:ref> status message. Unexpected 1xx status responses &MAY; be
    2646    ignored by a user agent.
     2646   prior to a final response, even if the client does not expect a
     2647   <x:ref>100 (Continue)</x:ref> status message.
     2648   A user agent &MAY; ignore unexpected 1xx status responses.
    26472649</t>
    26482650<t>
    26492651   Proxies &MUST; forward 1xx responses, unless the connection between the
    26502652   proxy and its client has been closed, or unless the proxy itself
    2651    requested the generation of the 1xx response. (For example, if a
     2653   requested the generation of the 1xx response. For example, if a
    26522654   proxy adds an "Expect: 100-continue" field when it forwards a request,
    26532655   then it need not forward the corresponding <x:ref>100 (Continue)</x:ref>
    2654    response(s).)
     2656   response(s).
    26552657</t>
    26562658
    … …  
    27062708  <iref primary="true" item="Status Codes Classes" subitem="2xx Successful" x:for-anchor=""/>
    27072709<t>
    2708    This class of status code indicates that the client's request was
    2709    successfully received, understood, and accepted.
     2710   The <x:dfn>2xx (Successful)</x:dfn> class of status code indicates that
     2711   the client's request was successfully received, understood, and accepted.
    27102712</t>
    27112713
    … …  
    27162718   The <x:dfn>200 (OK)</x:dfn> status code indicates that the request has
    27172719   succeeded. The meaning of a payload sent in the response depends on the
    2718    request method, as follows:
     2720   request method. For the methods defined by this specification, the payload
     2721   can be summarized as:
    27192722  <list style="hanging">
    27202723    <t hangText="GET">
    … …  
    27252728    </t>
    27262729    <t hangText="POST">
    2727       a representation describing or containing the result of the action;
     2730      a representation of the status of, or results obtained from, the action;
     2731    </t>
     2732    <t hangText="PUT, DELETE">
     2733      a representation of the status of the action;
     2734    </t>
     2735    <t hangText="OPTIONS">
     2736      a representation of the communications options;
    27282737    </t>
    27292738    <t hangText="TRACE">
    2730       a representation containing the request message as received by the
     2739      a representation of the request message as received by the
    27312740      end server.
    27322741    </t>
    … …  
    27342743</t>
    27352744<t>
     2745   Aside from responses to CONNECT, a 200 response always has a payload,
     2746   though an origin server &MAY; generate a payload body of zero length.
     2747   If no payload is desired, an origin server ought to send
     2748   <x:dfn>204 (No Content)</x:dfn> instead.
     2749   For CONNECT, no payload is allowed because the successful result is a
     2750   tunnel, which begins immediately after the 200 response header block.
     2751</t>
     2752<t>
    27362753   Caches &MAY; use a heuristic (see &p6-heuristic;) to determine
    27372754   freshness for 200 responses.
    … …  
    27442761<t>
    27452762   The <x:dfn>201 (Created)</x:dfn> status code indicates that the request has
    2746    been fulfilled and has resulted in one or more new resources being created.
    2747 </t>
    2748 <t>
    2749    Newly created resources are typically linked to from the response payload,
    2750    with the most relevant URI also being carried in the <x:ref>Location</x:ref>
    2751    header field. If the newly created resource's URI is the same as the
    2752    effective request URI, the Location field can be omitted.
    2753 </t>
    2754 <t>
    2755    If an <x:ref>ETag</x:ref> header field is present in a 201 response, its
    2756    field value is the entity-tag for the representation created, which
    2757    is the new representation of the resource identified by either the
    2758    <x:ref>Location</x:ref> header field or, if no Location header field
    2759    is received, by the effective request URI (see &header-etag;).
     2763   been fulfilled and has resulted in one or more new resources being created.
     2764   The primary resource created by the request is identified by either a
     2765   <x:ref>Location</x:ref> header field in the response or, if no
     2766   <x:ref>Location</x:ref> field is received, by the effective request URI.
     2767</t>
     2768<t>
     2769   The 201 response payload typically describes and links to the resource(s)
     2770   created. See <xref target="selected.representation"/> for discussion of the
     2771   meaning and purpose of selected representation header fields, such as
     2772   <x:ref>ETag</x:ref> and <x:ref>Last-Modified</x:ref>, in a 201 response.
    27602773</t>
    27612774</section>
    … …  
    28262839   (if any).  The server assumes that the user agent will provide some
    28272840   indication of the success to its user, in accord with its own interface,
    2828    and apply any new or updated metadata in the response to the active
     2841   and apply any new or updated metadata in the response to its active
    28292842   representation.
    28302843</t>
    … …  
    38593872<t>
    38603873   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
    3861    the current representation of the <x:ref>target resource</x:ref> that would have been
    3862    selected in a successful response if the same request had used the
    3863    method GET and excluded any conditional request header fields.
    3864 </t>
    3865 <t>
    3866    Additional header fields define metadata about the selected
    3867    representation, which might differ from the representation included
    3868    in the message for responses to some state-changing methods.
    3869    The following header fields are defined as selected representation
    3870    metadata:
     3874   representation of the <x:ref>target resource</x:ref> in a
     3875   <x:ref>200 (OK)</x:ref> response to <x:ref>GET</x:ref>, or the
     3876   representation that would have been selected in a successful response if
     3877   the request had used the method <x:ref>GET</x:ref> and excluded any
     3878   conditional request header fields.
     3879</t>
     3880<t>
     3881   The following header fields define metadata about the selected
     3882   representation at the conclusion of handling the request. In other words,
     3883   for a successful response to a state-changing method, these fields describe
     3884   the new representation that has replaced the prior selected representation.
     3885   For example, an ETag header field in a 201 response communicates the
     3886   entity-tag of the newly created resource's representation, so that it can
     3887   be used in later conditional requests to prevent the "lost update"
     3888   problem <xref target="Part4"/>.
    38713889</t>
    38723890<texttable align="left">

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

    r2102 r2105  
    449449  }
    450450  @bottom-center {
    451        content: "Expires July 12, 2013";
     451       content: "Expires July 14, 2013";
    452452  }
    453453  @bottom-right {
    … …  
    491491      <meta name="dct.creator" content="Reschke, J. F.">
    492492      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    493       <meta name="dct.issued" scheme="ISO8601" content="2013-01-08">
     493      <meta name="dct.issued" scheme="ISO8601" content="2013-01-10">
    494494      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    495495      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false.">
    … …  
    517517            </tr>
    518518            <tr>
    519                <td class="left">Expires: July 12, 2013</td>
    520                <td class="right">January 8, 2013</td>
     519               <td class="left">Expires: July 14, 2013</td>
     520               <td class="right">January 10, 2013</td>
    521521            </tr>
    522522         </tbody>
    … …  
    545545         in progress”.
    546546      </p>
    547       <p>This Internet-Draft will expire on July 12, 2013.</p>
     547      <p>This Internet-Draft will expire on July 14, 2013.</p>
    548548      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    549549      <p>Copyright © 2013 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    705705      <div id="rfc.iref.l.1"></div>
    706706      <h2 id="rfc.section.2.2"><a href="#rfc.section.2.2">2.2</a>&nbsp;<a id="header.last-modified" href="#header.last-modified">Last-Modified</a></h2>
    707       <p id="rfc.section.2.2.p.1">The "Last-Modified" header field indicates the date and time at which the origin server believes the selected representation
    708          was last modified.
     707      <p id="rfc.section.2.2.p.1">The "Last-Modified" header field in a response provides a timestamp indicating the date and time at which the origin server
     708         believes the selected representation was last modified, as determined at the conclusion of handling the request.
    709709      </p>
    710710      <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span>  <a href="#header.last-modified" class="smpl">Last-Modified</a> = <a href="#imported.abnf" class="smpl">HTTP-date</a>
    … …  
    764764      <div id="rfc.iref.e.1"></div>
    765765      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="header.etag" href="#header.etag">ETag</a></h2>
    766       <p id="rfc.section.2.3.p.1">The "ETag" header field provides the current entity-tag for the selected representation. An entity-tag is an opaque validator
    767          for differentiating between multiple representations of the same resource, regardless of whether those multiple representations
    768          are due to resource state changes over time, content negotiation resulting in multiple representations being valid at the
    769          same time, or both. An entity-tag consists of an opaque quoted string, possibly prefixed by a weakness indicator.
     766      <p id="rfc.section.2.3.p.1">The "ETag" header field in a response provides the current entity-tag for the selected representation, as determined at the
     767         conclusion of handling the request. An entity-tag is an opaque validator for differentiating between multiple representations
     768         of the same resource, regardless of whether those multiple representations are due to resource state changes over time, content
     769         negotiation resulting in multiple representations being valid at the same time, or both. An entity-tag consists of an opaque
     770         quoted string, possibly prefixed by a weakness indicator.
    770771      </p>
    771772      <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.2"></span><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span>  <a href="#header.etag" class="smpl">ETag</a>       = <a href="#header.etag" class="smpl">entity-tag</a>

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

    r2102 r2105  
    290290  <x:anchor-alias value="Last-Modified"/>
    291291<t>
    292    The "Last-Modified" header field indicates the date and time at
    293    which the origin server believes the selected representation was
    294    last modified.
     292   The "Last-Modified" header field in a response provides a timestamp
     293   indicating the date and time at which the origin server believes the
     294   selected representation was last modified, as determined at the conclusion
     295   of handling the request.
    295296</t>
    296297<figure><artwork type="abnf2616"><iref primary="true" item="Grammar" subitem="Last-Modified"/>
    … …  
    406407  <x:anchor-alias value="etagc"/>
    407408<t>
    408    The "ETag" header field provides the current entity-tag for the
    409    selected representation.
     409   The "ETag" header field in a response provides the current entity-tag for
     410   the selected representation, as determined at the conclusion of handling
     411   the request.
    410412   An entity-tag is an opaque validator for differentiating between
    411413   multiple representations of the same resource, regardless of whether
Note: See TracChangeset for help on using the changeset viewer.