Changeset 114 for draft-ietf-httpbis/latest
- Timestamp:
- 28/12/07 16:30:47 (14 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r113 r114 1428 1428 </dd> 1429 1429 </dl> 1430 <p id="rfc.section.10.4.p.6">There are circumstances in which a fragment identifier in a Location URL would not be appropriate: </p> 1431 <ul> 1432 <li>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</li> 1433 <li>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment 1434 characteristics. 1435 </li> 1436 <li>With 305 Use Proxy.</li> 1437 </ul> 1430 1438 <div id="rfc.iref.m.9"></div> 1431 1439 <div id="rfc.iref.h.6"></div> … … 1664 1672 user agent is able to make that determination based on the request method semantics. (Sections <a href="#status.301" id="rfc.xref.status.301.2" title="301 Moved Permanently">9.3.2</a>, <a href="#status.302" id="rfc.xref.status.302.2" title="302 Found">9.3.3</a> and <a href="#status.307" id="rfc.xref.status.307.2" title="307 Temporary Redirect">9.3.8</a> ) 1665 1673 </p> 1666 <p id="rfc.section.A.2.p.3">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 1674 <p id="rfc.section.A.2.p.3">Correct syntax of Location header to allow fragment, as referred symbol wasn't what was expected, and add some clarifications 1675 as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.3" title="Location">Section 10.4</a>) 1676 </p> 1677 <p id="rfc.section.A.2.p.4">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 1667 1678 in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.12"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section 10.8</a>) 1668 1679 </p> … … 1811 1822 <li class="indline1">Expect <a class="iref" href="#rfc.xref.header.expect.1">4</a>, <a class="iref" href="#rfc.xref.header.expect.2">9.4.18</a>, <a class="iref" href="#rfc.iref.h.3"><b>10.2</b></a></li> 1812 1823 <li class="indline1">From <a class="iref" href="#rfc.xref.header.from.1">4</a>, <a class="iref" href="#rfc.iref.h.4"><b>10.3</b></a></li> 1813 <li class="indline1">Location <a class="iref" href="#rfc.xref.header.location.1">6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>10.4</b></a> </li>1824 <li class="indline1">Location <a class="iref" href="#rfc.xref.header.location.1">6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>10.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li> 1814 1825 <li class="indline1">Max-Forwards <a class="iref" href="#rfc.xref.header.max-forwards.1">4</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">8.8</a>, <a class="iref" href="#rfc.iref.h.6"><b>10.5</b></a></li> 1815 1826 <li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1">4</a>, <a class="iref" href="#rfc.iref.h.7"><b>10.6</b></a></li> … … 1823 1834 <li class="indline0"><a id="rfc.index.L" href="#rfc.index.L"><b>L</b></a><ul class="ind"> 1824 1835 <li class="indline1">LINK method <a class="iref" href="#rfc.iref.l.2"><b>A.1</b></a></li> 1825 <li class="indline1">Location header <a class="iref" href="#rfc.xref.header.location.1">6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.l.1"><b>10.4</b></a> </li>1836 <li class="indline1">Location header <a class="iref" href="#rfc.xref.header.location.1">6</a>, <a class="iref" href="#rfc.xref.header.location.2">8.5</a>, <a class="iref" href="#rfc.iref.l.1"><b>10.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">A.2</a></li> 1826 1837 <li class="indline1"><em>Luo1998</em> <a class="iref" href="#rfc.xref.Luo1998.1">8.9</a>, <a class="iref" href="#Luo1998"><b>14</b></a></li> 1827 1838 </ul> -
draft-ietf-httpbis/latest/p2-semantics.xml
r113 r114 1825 1825 </t></list> 1826 1826 </t> 1827 <t> 1828 There are circumstances in which a fragment identifier in a Location URL would not be appropriate: 1829 <list style="symbols"> 1830 <t>With a 201 Created response, because in this usage the Location header specifies the URL for the entire created resource.</t> 1831 <t>With a 300 Multiple Choices, since the choice decision is intended to be made on resource characteristics and not fragment characteristics.</t> 1832 <t>With 305 Use Proxy.</t> 1833 </list> 1834 </t> 1827 1835 </section> 1828 1836 … … 2565 2573 </t> 2566 2574 <t> 2575 Correct syntax of Location header to allow fragment, 2576 as referred symbol wasn't what was expected, and add some 2577 clarifications as to when it would not be appropriate. 2578 (<xref target="header.location"/>) 2579 </t> 2580 <t> 2567 2581 In the description of the Server header, the Via field 2568 2582 was described as a SHOULD. The requirement was and is stated
Note: See TracChangeset
for help on using the changeset viewer.