Changeset 240 for draft-ietf-httpbis/latest
- Timestamp:
- 10/04/08 06:16:47 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r237 r240 447 447 <tr> 448 448 <td class="header left"></td> 449 <td class="header right">April 3, 2008</td>449 <td class="header right">April 9, 2008</td> 450 450 </tr> 451 451 </table> … … 1383 1383 <div id="rfc.iref.h.2"></div> 1384 1384 <h2 id="rfc.section.10.1"><a href="#rfc.section.10.1">10.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1385 <p id="rfc.section.10.1.p.1">The Allow response-header field lists the set of methods supported by the resource identified by the Request-URI. The purpose 1386 of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. 1385 <p id="rfc.section.10.1.p.1">The Allow response-header field lists the set of methods advertised as supported by the resource identified by the Request-URI. 1386 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header 1387 field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. 1387 1388 </p> 1388 1389 <div id="rfc.figure.u.13"></div><pre class="inline"><span id="rfc.iref.g.9"></span> <a href="#header.allow" class="smpl">Allow</a> = "Allow" ":" #<a href="#method" class="smpl">Method</a> 1389 1390 </pre><p id="rfc.section.10.1.p.3">Example of use:</p> 1390 1391 <div id="rfc.figure.u.14"></div><pre class="text"> Allow: GET, HEAD, PUT 1391 </pre><p id="rfc.section.10.1.p.5">This field cannot prevent a client from trying other methods. However, the indications given by the Allow header field value <em class="bcp14">SHOULD</em> be followed. The actual set of allowed methods is defined by the origin server at the time of each request. 1392 </p> 1392 </pre><p id="rfc.section.10.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 1393 1393 <p id="rfc.section.10.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field even if it does not understand all the methods specified, since the user agent might have other 1394 1394 means of communicating with the origin server. … … 1712 1712 was expected to repeat this single request via the proxy. (<a href="#status.305" id="rfc.xref.status.305.2" title="305 Use Proxy">Section 9.3.6</a>) 1713 1713 </p> 1714 <p id="rfc.section.A.2.p.4">Reclassify Allow header as response header, removing the option to specify it in a PUT request. (<a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 10.1</a>) 1714 <p id="rfc.section.A.2.p.4">Reclassify Allow header as response header, removing the option to specify it in a PUT request. Relax the server requirement 1715 on the contents of the Allow header and remove requirement on clients to always trust the header value. (<a href="#header.allow" id="rfc.xref.header.allow.3" title="Allow">Section 10.1</a>) 1715 1716 </p> 1716 1717 <p id="rfc.section.A.2.p.5">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications … … 1772 1773 <p id="rfc.section.B.4.p.1">Closed issues: </p> 1773 1774 <ul> 1775 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24</a>>: "Requiring Allow in 405 responses" 1776 </li> 1774 1777 <li> <<a href="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61">http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61</a>>: "Redirection vs. Location" 1775 1778 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r237 r240 1727 1727 <x:anchor-alias value="Allow"/> 1728 1728 <t> 1729 The Allow response-header field lists the set of methods supported1730 by the resource identified by the Request-URI. The purpose of this1731 field is strictly to inform the recipient of valid methods1729 The Allow response-header field lists the set of methods advertised as 1730 supported by the resource identified by the Request-URI. The purpose of 1731 this field is strictly to inform the recipient of valid methods 1732 1732 associated with the resource. An Allow header field &MUST; be 1733 1733 present in a 405 (Method Not Allowed) response. … … 1743 1743 </artwork></figure> 1744 1744 <t> 1745 This field cannot prevent a client from trying other methods. 1746 However, the indications given by the Allow header field value 1747 &SHOULD; be followed. The actual set of allowed methods is defined 1745 The actual set of allowed methods is defined 1748 1746 by the origin server at the time of each request. 1749 1747 </t> … … 2647 2645 Reclassify Allow header as response header, removing the option to 2648 2646 specify it in a PUT request. 2647 Relax the server requirement on the contents of the Allow header and 2648 remove requirement on clients to always trust the header value. 2649 2649 (<xref target="header.allow"/>) 2650 2650 </t> … … 2761 2761 <list style="symbols"> 2762 2762 <t> 2763 <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/24"/>: 2764 "Requiring Allow in 405 responses" 2765 </t> 2766 <t> 2763 2767 <eref target="http://www3.tools.ietf.org/wg/httpbis/trac/ticket/61"/>: 2764 2768 "Redirection vs. Location"
Note: See TracChangeset
for help on using the changeset viewer.