Ignore:
Timestamp:
Jul 3, 2012, 10:25:39 AM (7 years ago)
Author:
julian.reschke@…
Message:

tune conformance requirements (see #271)

File:
1 edited

Legend:

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

    r1697 r1707  
    449449  }
    450450  @bottom-center {
    451        content: "Expires January 2, 2013";
     451       content: "Expires January 4, 2013";
    452452  }
    453453  @bottom-right {
     
    497497      <meta name="dct.creator" content="Reschke, J. F.">
    498498      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    499       <meta name="dct.issued" scheme="ISO8601" content="2012-07-01">
     499      <meta name="dct.issued" scheme="ISO8601" content="2012-07-03">
    500500      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    501501      <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request header fields, response status codes, and response header fields. Furthermore, it defines HTTP message content, metadata, and content negotiation.">
     
    528528            </tr>
    529529            <tr>
    530                <td class="left">Expires: January 2, 2013</td>
     530               <td class="left">Expires: January 4, 2013</td>
    531531               <td class="right">greenbytes</td>
    532532            </tr>
    533533            <tr>
    534534               <td class="left"></td>
    535                <td class="right">July 1, 2012</td>
     535               <td class="right">July 3, 2012</td>
    536536            </tr>
    537537         </tbody>
     
    563563         in progress”.
    564564      </p>
    565       <p>This Internet-Draft will expire on January 2, 2013.</p>
     565      <p>This Internet-Draft will expire on January 4, 2013.</p>
    566566      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    567567      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
     
    941941         can specify that only zero-length bodies (as opposed to absent bodies) are allowed.
    942942      </p>
    943       <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular what conditions a cache may store the response, and under what conditions such a stored response may be used
    944          to satisfy a subsequent request.
     943      <p id="rfc.section.2.2.1.p.4">New method definitions need to indicate whether they are safe (<a href="#safe.methods" title="Safe Methods">Section&nbsp;2.1.1</a>), what semantics (if any) the request body has, and whether they are idempotent (<a href="#idempotent.methods" title="Idempotent Methods">Section&nbsp;2.1.2</a>). They also need to state whether they can be cached (<a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>); in particular under what conditions a cache can store the response, and under what conditions such a stored response can
     944         be used to satisfy a subsequent request.
    945945      </p>
    946946      <h2 id="rfc.section.2.3"><a href="#rfc.section.2.3">2.3</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h2>
     
    11531153         to reject the request.
    11541154      </p>
    1155       <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data may be discarded
    1156          if the eventual response is negative, and the connection may be reset with no response if more than one TCP segment is outstanding.
     1155      <p id="rfc.section.2.3.8.p.9">Similar to a pipelined HTTP/1.1 request, data to be tunneled from client to server <em class="bcp14">MAY</em> be sent immediately after the request (before a response is received). The usual caveats also apply: data can be discarded
     1156         if the eventual response is negative, and the connection can be reset with no response if more than one TCP segment is outstanding.
    11571157      </p>
    11581158      <p id="rfc.section.2.3.8.p.10">It might be the case that the proxy itself can only reach the requested origin server through another proxy. In this case,
     
    12301230         </li>
    12311231         <li>
    1232             <p>Whether the header field should be preserved across redirects.</p>
     1232            <p>Whether the header field ought to be preserved across redirects.</p>
    12331233         </li>
    12341234      </ul>
     
    18611861      <p id="rfc.section.4.5.4.p.1">The 303 status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI
    18621862         in the Location header field, that is intended to provide an indirect response to the original request. In order to satisfy
    1863          the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which may itself be redirected further,
     1863         the original request, a user agent <em class="bcp14">SHOULD</em> perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further,
    18641864         and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is
    18651865         not considered equivalent to the effective request URI.
Note: See TracChangeset for help on using the changeset viewer.