Ignore:
Timestamp:
31/01/12 21:30:47 (11 years ago)
Author:
julian.reschke@…
Message:

relax payload requirements for 301/302/307 (addresses #332)

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

Legend:

Unmodified
Added
Removed

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

    r1520 r1521  
    358358  }
    359359  @bottom-center {
    360        content: "Expires August 1, 2012";
     360       content: "Expires August 3, 2012";
    361361  }
    362362  @bottom-right {
    … …  
    410410      <meta name="dct.creator" content="Reschke, J. F.">
    411411      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    412       <meta name="dct.issued" scheme="ISO8601" content="2012-01-29">
     412      <meta name="dct.issued" scheme="ISO8601" content="2012-01-31">
    413413      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    414414      <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.">
    … …  
    441441            </tr>
    442442            <tr>
    443                <td class="left">Expires: August 1, 2012</td>
     443               <td class="left">Expires: August 3, 2012</td>
    444444               <td class="right">HP</td>
    445445            </tr>
    … …  
    494494            <tr>
    495495               <td class="left"></td>
    496                <td class="right">January 29, 2012</td>
     496               <td class="right">January 31, 2012</td>
    497497            </tr>
    498498         </tbody>
    … …  
    524524         in progress”.
    525525      </p>
    526       <p>This Internet-Draft will expire on August 1, 2012.</p>
     526      <p>This Internet-Draft will expire on August 3, 2012.</p>
    527527      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    528528      <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    18181818      <p id="rfc.section.7.3.2.p.2">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.17"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 301 responses.
    18191819      </p>
    1820       <p id="rfc.section.7.3.2.p.3">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 representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     1820      <p id="rfc.section.7.3.2.p.3">The new permanent URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
     1821         the new URI(s).
    18211822      </p>
    18221823      <p id="rfc.section.7.3.2.p.4">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;6.1.1</a>, then the request <em class="bcp14">MAY</em> 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
    … …  
    18331834      <p id="rfc.section.7.3.3.p.1">The target resource resides temporarily under a different URI. Since the redirection might be altered on occasion, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18341835      </p>
    1835       <p id="rfc.section.7.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 representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     1836      <p id="rfc.section.7.3.3.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
     1837         the new URI(s).
    18361838      </p>
    18371839      <p id="rfc.section.7.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;6.1.1</a>, then the request <em class="bcp14">MAY</em> 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
    … …  
    18841886      <p id="rfc.section.7.3.8.p.1">The target resource resides temporarily under a different URI. Since the redirection can change over time, the client <em class="bcp14">SHOULD</em> continue to use the effective request URI for future requests.
    18851887      </p>
    1886       <p id="rfc.section.7.3.8.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 representation of the response <em class="bcp14">SHOULD</em> contain a short hypertext note with a hyperlink to the new URI(s).
     1888      <p id="rfc.section.7.3.8.p.2">The temporary URI <em class="bcp14">SHOULD</em> be given by the Location field in the response. A response payload can contain a short hypertext note with a hyperlink to
     1889         the new URI(s).
    18871890      </p>
    18881891      <p id="rfc.section.7.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;6.1.1</a>, then the request <em class="bcp14">MAY</em> 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
    … …  
    30023005      <p id="rfc.section.A.p.5">Broadened the definition of 203 (Non-Authoritative Information) to include cases of payload transformations as well. (<a href="#status.203" id="rfc.xref.status.203.3" title="203 Non-Authoritative Information">Section&nbsp;7.2.4</a>)
    30033006      </p>
    3004       <p id="rfc.section.A.p.6">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
     3007      <p id="rfc.section.A.p.6">Removed the normative requirements on response payloads for status codes 301, 302, and 307. (<a href="#status.3xx" title="Redirection 3xx">Section&nbsp;7.3</a>)
     3008      </p>
     3009      <p id="rfc.section.A.p.7">Failed to consider that there are many other request methods that are safe to automatically redirect, and further that the
    30053010         user agent is able to make that determination based on the request method semantics. Furthermore, allow user agents to rewrite
    30063011         the method from POST to GET for status codes 301 and 302. (Sections <a href="#status.301" id="rfc.xref.status.301.3" title="301 Moved Permanently">7.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.3" title="302 Found">7.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.3" title="307 Temporary Redirect">7.3.8</a>)
    30073012      </p>
    3008       <p id="rfc.section.A.p.7">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
     3013      <p id="rfc.section.A.p.8">Deprecate 305 Use Proxy status code, because user agents did not implement it. It used to indicate that the target resource
    30093014         must be accessed through the proxy given by the Location field. The Location field gave the URI of the proxy. The recipient
    30103015         was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.3" title="305 Use Proxy">Section&nbsp;7.3.6</a>)
    30113016      </p>
    3012       <p id="rfc.section.A.p.8">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;7.4.19</a>)
    3013       </p>
    3014       <p id="rfc.section.A.p.9">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
    3015       </p>
    3016       <p id="rfc.section.A.p.10">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
     3017      <p id="rfc.section.A.p.9">Define status 426 (Upgrade Required) (this was incorporated from <a href="#RFC2817" id="rfc.xref.RFC2817.4"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a>). (<a href="#status.426" id="rfc.xref.status.426.3" title="426 Upgrade Required">Section&nbsp;7.4.19</a>)
     3018      </p>
     3019      <p id="rfc.section.A.p.10">Change ABNF productions for header fields to only define the field value. (<a href="#header.field.definitions" title="Header Field Definitions">Section&nbsp;9</a>)
     3020      </p>
     3021      <p id="rfc.section.A.p.11">Reclassify "Allow" as response header field, removing the option to specify it in a PUT request. Relax the server requirement
    30173022         on the contents of the Allow header field and remove requirement on clients to always trust the header field value. (<a href="#header.allow" id="rfc.xref.header.allow.4" title="Allow">Section&nbsp;9.1</a>)
    30183023      </p>
    3019       <p id="rfc.section.A.p.11">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
     3024      <p id="rfc.section.A.p.12">The ABNF for the Expect header field has been both fixed (allowing parameters for value-less expectations as well) and simplified
    30203025         (allowing trailing semicolons after "100-continue" when they were invalid before). (<a href="#header.expect" id="rfc.xref.header.expect.4" title="Expect">Section&nbsp;9.3</a>)
    30213026      </p>
    3022       <p id="rfc.section.A.p.12">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
     3027      <p id="rfc.section.A.p.13">Correct syntax of Location header field to allow URI references (including relative references and fragments), as referred
    30233028         symbol "absoluteURI" wasn't what was expected, and add some clarifications as to when use of fragments would not be appropriate.
    30243029         (<a href="#header.location" id="rfc.xref.header.location.5" title="Location">Section&nbsp;9.5</a>)
    30253030      </p>
    3026       <p id="rfc.section.A.p.13">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.6</a>)
    3027       </p>
    3028       <p id="rfc.section.A.p.14">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.7</a>)
    3029       </p>
    3030       <p id="rfc.section.A.p.15">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
     3031      <p id="rfc.section.A.p.14">Restrict Max-Forwards header field to OPTIONS and TRACE (previously, extension methods could have used it as well). (<a href="#header.max-forwards" id="rfc.xref.header.max-forwards.5" title="Max-Forwards">Section&nbsp;9.6</a>)
     3032      </p>
     3033      <p id="rfc.section.A.p.15">Allow Referer field value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section&nbsp;9.7</a>)
     3034      </p>
     3035      <p id="rfc.section.A.p.16">In the description of the Server header field, the Via field was described as a SHOULD. The requirement was and is stated
    30313036         correctly in the description of the Via header field in <a href="p1-messaging.html#header.via" title="Via">Section 8.8</a> of <a href="#Part1" id="rfc.xref.Part1.45"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.4" title="Server">Section&nbsp;9.9</a>)
    30323037      </p>
    … …  
    34403445      <p id="rfc.section.C.20.p.1">Closed issues: </p>
    34413446      <ul>
     3447         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/332">http://tools.ietf.org/wg/httpbis/trac/ticket/332</a>&gt;: "relax requirements on hypertext in 3/4/5xx error responses"
     3448         </li>
    34423449         <li> &lt;<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/333">http://tools.ietf.org/wg/httpbis/trac/ticket/333</a>&gt;: "example for 426 response should have a payload"
    34433450         </li>

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

    r1520 r1521  
    17701770<t>
    17711771   The new permanent URI &SHOULD; be given by the Location field in the
    1772    response. Unless the request method was HEAD, the representation of the
    1773    response &SHOULD; contain a short hypertext note with a hyperlink to
    1774    the new URI(s).
     1772   response. A response payload can contain a short hypertext note with a
     1773   hyperlink to the new URI(s).
    17751774</t>
    17761775<t>
    … …  
    18021801<t>
    18031802   The temporary URI &SHOULD; be given by the Location field in the
    1804    response. Unless the request method was HEAD, the representation of the
    1805    response &SHOULD; contain a short hypertext note with a hyperlink to
    1806    the new URI(s).
     1803   response. A response payload can contain a short hypertext note with a
     1804   hyperlink to the new URI(s).
    18071805</t>
    18081806<t>
    … …  
    19061904<t>
    19071905   The temporary URI &SHOULD; be given by the Location field in the
    1908    response. Unless the request method was HEAD, the representation of the
    1909    response &SHOULD; contain a short hypertext note with a hyperlink to
    1910    the new URI(s).
     1906   response. A response payload can contain a short hypertext note with a
     1907   hyperlink to the new URI(s).
    19111908</t>
    19121909<t>
    … …  
    39883985</t>
    39893986<t>
     3987  Removed the normative requirements on response payloads for status codes
     3988  301, 302, and 307.
     3989  (<xref target="status.3xx"/>)
     3990</t>
     3991<t>
    39903992  Failed to consider that there are many other request methods that are safe
    39913993  to automatically redirect, and further that the user agent is able to make
    … …  
    47584760  <list style="symbols">
    47594761    <t>
     4762      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/332"/>:
     4763      "relax requirements on hypertext in 3/4/5xx error responses"
     4764    </t>
     4765    <t>
    47604766      <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/333"/>:
    47614767      "example for 426 response should have a payload"
Note: See TracChangeset for help on using the changeset viewer.