Changeset 2481


Ignore:
Timestamp:
09/11/13 01:30:29 (7 years ago)
Author:
fielding@…
Message:

(editorial) slight wording change to [2427] for idempotent methods; see #501

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r2477 r2481  
    445445  }
    446446  @bottom-center {
    447        content: "Expires May 9, 2014";
     447       content: "Expires May 12, 2014";
    448448  }
    449449  @bottom-right {
     
    490490      <meta name="dct.creator" content="Reschke, J. F.">
    491491      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    492       <meta name="dct.issued" scheme="ISO8601" content="2013-11-05">
     492      <meta name="dct.issued" scheme="ISO8601" content="2013-11-08">
    493493      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    494494      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation.">
     
    518518            <tr>
    519519               <td class="left">Intended status: Standards Track</td>
    520                <td class="right">November 5, 2013</td>
     520               <td class="right">November 8, 2013</td>
    521521            </tr>
    522522            <tr>
    523                <td class="left">Expires: May 9, 2014</td>
     523               <td class="left">Expires: May 12, 2014</td>
    524524               <td class="right"></td>
    525525            </tr>
     
    550550            in progress”.
    551551         </p>
    552          <p>This Internet-Draft will expire on May 9, 2014.</p>
     552         <p>This Internet-Draft will expire on May 12, 2014.</p>
    553553      </div>
    554554      <div id="rfc.copyrightnotice">
     
    14331433               <div id="rfc.iref.i.1"></div>
    14341434               <h3 id="rfc.section.4.2.2"><a href="#rfc.section.4.2.2">4.2.2</a>&nbsp;<a href="#idempotent.methods">Idempotent Methods</a></h3>
    1435                <p id="rfc.section.4.2.2.p.1">Request methods are considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect of multiple identical requests on the server is the same as for a single request. Of the request
    1436                   methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
     1435               <p id="rfc.section.4.2.2.p.1">A request method is considered "<dfn id="idempotent">idempotent</dfn>" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single
     1436                  such request. Of the request methods defined by this specification, PUT, DELETE, and safe request methods are idempotent.
    14371437               </p>
    14381438               <p id="rfc.section.4.2.2.p.2">Like the definition of safe, the idempotent property only applies to what has been requested by the user; a server is free
     
    14421442               <p id="rfc.section.4.2.2.p.3">Idempotent methods are distinguished because the request can be repeated automatically if a communication failure occurs before
    14431443                  the client is able to read the server's response. For example, if a client sends a PUT request and the underlying connection
    1444                   is closed before any response is received, then it can establish a new connection and retry the idempotent request because
    1445                   it knows that repeating the request will have the same effect even if the original request succeeded (response codes might
    1446                   vary, though). Note, however, that repeated failures would indicate a problem within the server.
     1444                  is closed before any response is received, then the client can establish a new connection and retry the idempotent request
     1445                  because it knows that repeating the request will have the same effect (even if the original request succeeded, though the
     1446                  status codes might differ in response). Note, however, that repeated communication failures might indicate that the server
     1447                  has failed in general, or that something in the request is triggering a connection drop.
    14471448               </p>
    14481449            </div>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r2477 r2481  
    12401240<iref item="idempotent" primary="true"/>
    12411241<t>
    1242    Request methods are considered "<x:dfn anchor="idempotent">idempotent</x:dfn>"
    1243    if the intended effect of multiple identical requests on the server is the
    1244    same as for a single request. Of the request methods defined by this
     1242   A request method is considered
     1243   "<x:dfn anchor="idempotent">idempotent</x:dfn>"
     1244   if the intended effect on the server of multiple identical requests with
     1245   that method is the same as the effect for a single such request.
     1246   Of the request methods defined by this
    12451247   specification, PUT, DELETE, and safe request methods are idempotent.
    12461248</t>
     
    12561258   able to read the server's response.  For example, if a client sends a PUT
    12571259   request and the underlying connection is closed before any response is
    1258    received, then it can establish a new connection and retry the idempotent
    1259    request because it knows that repeating the request will have the same
    1260    effect even if the original request succeeded (response codes might vary,
    1261    though).  Note, however, that repeated failures would indicate a problem
    1262    within the server.
     1260   received, then the client can establish a new connection and retry the
     1261   idempotent request because it knows that repeating the request will have
     1262   the same effect (even if the original request succeeded, though the
     1263   status codes might differ in response).
     1264   Note, however, that repeated communication failures might indicate that
     1265   the server has failed in general, or that something in the request is
     1266   triggering a connection drop.
    12631267</t>
    12641268</section>
Note: See TracChangeset for help on using the changeset viewer.