Ignore:
Timestamp:
22/12/07 00:30:59 (13 years ago)
Author:
fielding@…
Message:

Regenerate HTML after the following changes applied to XML drafts:

Resolve #1: HTTP Version should be case sensitive
Resolve #2: 'unsafe' characters
Resolve #3: Chunk Size Definition
Resolve #4: Message Length
Resolve #5: Via is a MUST
Resolve #6: Fragments allowed in Location
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #8: Media type registrations, by updating to RFC 4288
Resolve #9: Trailer
Resolve #11: URI includes query
Resolve #12: Invalidation after Update or Delete
Resolve #17: Revise description of the POST method
Resolve #18: Cache validators in 206 responses
Resolve #49: Connection header text
Resolve #14: Clarification regarding quoting of charset values
Resolve #47: inconsistency in date format explanation
Resolve #48: Date reference typo
Resolve #48: remove unnecessary reference to RFC1123

for consistency with draft-lafon

Resolve #16: Remove 'identity' token references
Resolve #15: No close on 1xx responses
(editorial) fix typo of varriant
Resolve #10: Safe Methods vs Redirection
Resolve #45: RFC977 reference
Resolve #42: RFC2606 compliance
Resolve #46: references to RFC1700

File:
1 edited

Legend:

Unmodified
Added
Removed

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

    r62 r92  
    825825      <div id="rfc.iref.m.4"></div>
    826826      <h2 id="rfc.section.8.5"><a href="#rfc.section.8.5">8.5</a>&nbsp;<a id="POST" href="#POST">POST</a></h2>
    827       <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as a new subordinate of
    828          the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the following
    829          functions:
     827      <p id="rfc.section.8.5.p.1">The POST method is used to request that the origin server accept the entity enclosed in the request as data to be processed
     828         by the resource identified by the Request-URI in the Request-Line. POST is designed to allow a uniform method to cover the
     829         following functions:
    830830      </p>
    831831      <ul>
    … …  
    835835         <li>Extending a database through an append operation.</li>
    836836      </ul>
    837       <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.
    838          The posted entity is subordinate to that URI in the same way that a file is subordinate to a directory containing it, a news
    839          article is subordinate to a newsgroup to which it is posted, or a record is subordinate to a database.
    840       </p>
     837      <p id="rfc.section.8.5.p.2">The actual function performed by the POST method is determined by the server and is usually dependent on the Request-URI.</p>
    841838      <p id="rfc.section.8.5.p.3">The action performed by the POST method might not result in a resource that can be identified by a URI. In this case, either
    842839         200 (OK) or 204 (No Content) is the appropriate response status, depending on whether or not the response includes an entity
    … …  
    10511048      <p id="rfc.section.9.3.2.p.2">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    10521049      </p>
    1053       <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1050      <p id="rfc.section.9.3.2.p.3">If the 301 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    10541051         the request was issued.
    10551052      </p>
    … …  
    10681065      <p id="rfc.section.9.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. Unless the request method was HEAD, the entity of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
    10691066      </p>
    1070       <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1067      <p id="rfc.section.9.3.3.p.3">If the 302 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    10711068         the request was issued.
    10721069      </p>
    … …  
    11221119         the 307 status. Therefore, the note <em class="bcp14">SHOULD</em> contain the information necessary for a user to repeat the original request on the new URI.
    11231120      </p>
    1124       <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request other than GET or HEAD, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
     1121      <p id="rfc.section.9.3.8.p.3">If the 307 status code is received in response to a request method that is known to be "safe", as defined in <a href="#safe.methods" title="Safe Methods">Section&nbsp;8.1.1</a>, then the request MAY be automatically redirected by the user agent without confirmation. Otherwise, the user agent <em class="bcp14">MUST NOT</em> automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which
    11251122         the request was issued.
    11261123      </p>
    … …  
    13711368      <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span>    From   = "From" ":" mailbox
    13721369</pre><p id="rfc.section.10.3.p.3">An example is:</p>
    1373       <div id="rfc.figure.u.11"></div><pre class="text">    From: webmaster@w3.org
     1370      <div id="rfc.figure.u.11"></div><pre class="text">    From: webmaster@example.org
    13741371</pre><p id="rfc.section.10.3.p.5">This header field <em class="bcp14">MAY</em> be used for logging purposes and as a means for identifying the source of invalid or unwanted requests. It <em class="bcp14">SHOULD NOT</em> be used as an insecure form of access protection. The interpretation of this field is that the request is being performed
    13751372         on behalf of the person given, who accepts responsibility for the method performed. In particular, robot agents <em class="bcp14">SHOULD</em> include this header so that the person responsible for running the robot can be contacted if problems occur on the receiving
    … …  
    13911388         URI.
    13921389      </p>
    1393       <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span>    Location       = "Location" ":" absoluteURI
     1390      <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span>    Location       = "Location" ":" absoluteURI [ "#" fragment ]
    13941391</pre><p id="rfc.section.10.4.p.3">An example is:</p>
    1395       <div id="rfc.figure.u.13"></div><pre class="text">    Location: http://www.w3.org/pub/WWW/People.html
     1392      <div id="rfc.figure.u.13"></div><pre class="text">    Location: http://www.example.org/pub/WWW/People.html
    13961393</pre><p id="rfc.section.10.4.p.5"> </p>
    13971394      <dl class="empty">
    … …  
    14231420      <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span>    Referer        = "Referer" ":" ( absoluteURI | relativeURI )
    14241421</pre><p id="rfc.section.10.6.p.3">Example:</p>
    1425       <div id="rfc.figure.u.16"></div><pre class="text">    Referer: http://www.w3.org/hypertext/DataSources/Overview.html
     1422      <div id="rfc.figure.u.16"></div><pre class="text">    Referer: http://www.example.org/hypertext/Overview.html
    14261423</pre><p id="rfc.section.10.6.p.5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the Request-URI. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URI's">Section&nbsp;12.2</a> for security considerations.
    14271424      </p>
    … …  
    14491446</pre><p id="rfc.section.10.8.p.3">Example:</p>
    14501447      <div id="rfc.figure.u.20"></div><pre class="text">    Server: CERN/3.0 libwww/2.17
    1451 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">SHOULD</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1448</pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    14521449      </p>
    14531450      <dl class="empty">
Note: See TracChangeset for help on using the changeset viewer.