Changeset 593 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 13/06/09 07:12:22 (12 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r591 r593 471 471 <tr> 472 472 <td class="header left"></td> 473 <td class="header right">June 4, 2009</td>473 <td class="header right">June 13, 2009</td> 474 474 </tr> 475 475 </table> … … 1572 1572 <h2 id="rfc.section.9.6"><a href="#rfc.section.9.6">9.6</a> <a id="header.referer" href="#header.referer">Referer</a></h2> 1573 1573 <p id="rfc.section.9.6.p.1">The request-header field "Referer" [sic] allows the client to specify, for the server's benefit, the address (URI) of the 1574 resource from which the request-target was obtained (the "referrer", although the header field is misspelled.) The Referer 1575 request-header allows a server to generate lists of back-links to resources for interest, logging, optimized caching, etc. 1576 It also allows obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the request-target was obtained from a source that does not have its own URI, such as input from the user keyboard. 1574 resource from which the request-target was obtained (the "referrer", although the header field is misspelled.). 1575 </p> 1576 <p id="rfc.section.9.6.p.2">The Referer header allows servers to generate lists of back-links to resources for interest, logging, optimized caching, etc. 1577 It also allows obsolete or mistyped links to be traced for maintenance. Some servers use Referer as a means of controlling 1578 where they allow links from (so-called "deep linking"), but it should be noted that legitimate requests are not required to 1579 contain a Referer header field. 1580 </p> 1581 <p id="rfc.section.9.6.p.3">If the request-target was obtained from a source that does not have its own URI (e.g., input from the user keyboard), the 1582 Referer field MUST either be sent with the value "about:blank", or not be sent at all. Note that this requirement does not 1583 apply to sources with non-HTTP URIs (e.g., FTP). 1577 1584 </p> 1578 1585 <div id="rfc.figure.u.20"></div><pre class="inline"><span id="rfc.iref.g.22"></span><span id="rfc.iref.g.23"></span> <a href="#header.referer" class="smpl">Referer</a> = "Referer" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.referer" class="smpl">Referer-v</a> 1579 1586 <a href="#header.referer" class="smpl">Referer-v</a> = <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1580 </pre><p id="rfc.section.9.6.p. 3">Example:</p>1587 </pre><p id="rfc.section.9.6.p.5">Example:</p> 1581 1588 <div id="rfc.figure.u.21"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html 1582 </pre><p id="rfc.section.9.6.p. 5">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations.1589 </pre><p id="rfc.section.9.6.p.7">If the field value is a relative URI, it <em class="bcp14">SHOULD</em> be interpreted relative to the request-target. The URI <em class="bcp14">MUST NOT</em> include a fragment. See <a href="#encoding.sensitive.information.in.uris" title="Encoding Sensitive Information in URIs">Section 11.2</a> for security considerations. 1583 1590 </p> 1584 1591 <div id="rfc.iref.r.2"></div> … … 2243 2250 as to when it would not be appropriate. (<a href="#header.location" id="rfc.xref.header.location.4" title="Location">Section 9.4</a>) 2244 2251 </p> 2245 <p id="rfc.section.A.2.p.7">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2252 <p id="rfc.section.A.2.p.7">Allow Referer value of "about:blank" as alternative to not specifying it. (<a href="#header.referer" id="rfc.xref.header.referer.3" title="Referer">Section 9.6</a>) 2253 </p> 2254 <p id="rfc.section.A.2.p.8">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly 2246 2255 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.28"><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 9.8</a>) 2247 2256 </p> … … 2481 2490 <p id="rfc.section.C.8.p.1">Closed issues: </p> 2482 2491 <ul> 2492 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/144">http://tools.ietf.org/wg/httpbis/trac/ticket/144</a>>: "Clarify when Referer is sent" 2493 </li> 2483 2494 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/164">http://tools.ietf.org/wg/httpbis/trac/ticket/164</a>>: "status codes vs methods" 2484 2495 </li> … … 2613 2624 <li class="indline1">Location <a class="iref" href="#rfc.xref.header.location.1">5</a>, <a class="iref" href="#rfc.xref.header.location.2">7.5</a>, <a class="iref" href="#rfc.iref.h.5"><b>9.4</b></a>, <a class="iref" href="#rfc.xref.header.location.3">10.3</a>, <a class="iref" href="#rfc.xref.header.location.4">A.2</a></li> 2614 2625 <li class="indline1">Max-Forwards <a class="iref" href="#rfc.xref.header.max-forwards.1">3</a>, <a class="iref" href="#rfc.xref.header.max-forwards.2">7.8</a>, <a class="iref" href="#rfc.iref.h.6"><b>9.5</b></a>, <a class="iref" href="#rfc.xref.header.max-forwards.3">10.3</a></li> 2615 <li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.referer.2">10.3</a> </li>2626 <li class="indline1">Referer <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.h.7"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.referer.2">10.3</a>, <a class="iref" href="#rfc.xref.header.referer.3">A.2</a></li> 2616 2627 <li class="indline1">Retry-After <a class="iref" href="#rfc.xref.header.retry-after.1">5</a>, <a class="iref" href="#rfc.iref.h.8"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.retry-after.2">10.3</a></li> 2617 2628 <li class="indline1">Server <a class="iref" href="#rfc.xref.header.server.1">5</a>, <a class="iref" href="#rfc.iref.h.9"><b>9.8</b></a>, <a class="iref" href="#rfc.xref.header.server.2">10.3</a>, <a class="iref" href="#rfc.xref.header.server.3">11.1</a>, <a class="iref" href="#rfc.xref.header.server.4">A.2</a></li> … … 2710 2721 </li> 2711 2722 <li class="indline0"><a id="rfc.index.R" href="#rfc.index.R"><b>R</b></a><ul class="ind"> 2712 <li class="indline1">Referer header <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.r.1"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.referer.2">10.3</a> </li>2723 <li class="indline1">Referer header <a class="iref" href="#rfc.xref.header.referer.1">3</a>, <a class="iref" href="#rfc.iref.r.1"><b>9.6</b></a>, <a class="iref" href="#rfc.xref.header.referer.2">10.3</a>, <a class="iref" href="#rfc.xref.header.referer.3">A.2</a></li> 2713 2724 <li class="indline1">Retry-After header <a class="iref" href="#rfc.xref.header.retry-after.1">5</a>, <a class="iref" href="#rfc.iref.r.2"><b>9.7</b></a>, <a class="iref" href="#rfc.xref.header.retry-after.2">10.3</a></li> 2714 2725 <li class="indline1"><em>RFC1945</em> <a class="iref" href="#rfc.xref.RFC1945.1">8.3.3</a>, <a class="iref" href="#RFC1945"><b>13.2</b></a></li>
Note: See TracChangeset
for help on using the changeset viewer.