Changeset 2054 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 17/12/12 03:09:16 (9 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r2052 r2054 449 449 } 450 450 @bottom-center { 451 content: "Expires June 1 8, 2013";451 content: "Expires June 19, 2013"; 452 452 } 453 453 @bottom-right { … … 495 495 <meta name="dct.creator" content="Reschke, J. F."> 496 496 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-1 5">497 <meta name="dct.issued" scheme="ISO8601" content="2012-12-16"> 498 498 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 499 499 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation."> … … 523 523 <tr> 524 524 <td class="left">Intended status: Standards Track</td> 525 <td class="right">December 1 5, 2012</td>525 <td class="right">December 16, 2012</td> 526 526 </tr> 527 527 <tr> 528 <td class="left">Expires: June 1 8, 2013</td>528 <td class="left">Expires: June 19, 2013</td> 529 529 <td class="right"></td> 530 530 </tr> … … 554 554 in progress”. 555 555 </p> 556 <p>This Internet-Draft will expire on June 1 8, 2013.</p>556 <p>This Internet-Draft will expire on June 19, 2013.</p> 557 557 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 558 558 <p>Copyright © 2012 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 2041 2041 <div id="rfc.iref.f.1"></div> 2042 2042 <h3 id="rfc.section.5.5.1"><a href="#rfc.section.5.5.1">5.5.1</a> <a id="header.from" href="#header.from">From</a></h3> 2043 <p id="rfc.section.5.5.1.p.1">The "From" header field, if given, <em class="bcp14">SHOULD</em> contain an Internet e-mail address for the human user who controls the requesting user agent. The address <em class="bcp14">SHOULD</em> be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2043 <p id="rfc.section.5.5.1.p.1">The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address 2044 ought to be machine-usable, as defined by "mailbox" in <a href="http://tools.ietf.org/html/rfc5322#section-3.4">Section 3.4</a> of <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a>: 2044 2045 </p> 2045 2046 <div id="rfc.figure.u.34"></div><pre class="inline"><span id="rfc.iref.g.34"></span> <a href="#header.from" class="smpl">From</a> = <a href="#header.from" class="smpl">mailbox</a> … … 2048 2049 </pre><p id="rfc.section.5.5.1.p.3">An example is:</p> 2049 2050 <div id="rfc.figure.u.35"></div><pre class="text"> From: webmaster@example.org 2050 </pre><p id="rfc.section.5.5.1.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 2051 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 field so that the person responsible for running the robot can be contacted if problems occur on the receiving 2052 end. 2053 </p> 2054 <p id="rfc.section.5.5.1.p.6">The Internet e-mail address in this field <em class="bcp14">MAY</em> be separate from the Internet host which issued the request. For example, when a request is passed through a proxy the original 2055 issuer's address <em class="bcp14">SHOULD</em> be used. 2056 </p> 2057 <p id="rfc.section.5.5.1.p.7">The client <em class="bcp14">SHOULD NOT</em> send the From header field without the user's approval, as it might conflict with the user's privacy interests or their site's 2058 security policy. It is strongly recommended that the user be able to disable, enable, and modify the value of this field at 2059 any time prior to a request. 2051 </pre><p id="rfc.section.5.5.1.p.5">The From header field is rarely sent by non-robotic user agents. A user agent <em class="bcp14">SHOULD NOT</em> send a From header field without explicit configuration by the user, since that might conflict with the user's privacy interests 2052 or their site's security policy. 2053 </p> 2054 <p id="rfc.section.5.5.1.p.6">Robotic user agents <em class="bcp14">SHOULD</em> send a valid From header field so that the person responsible for running the robot can be contacted if problems occur on 2055 servers, such as if the robot is sending excessive, unwanted, or invalid requests. 2056 </p> 2057 <p id="rfc.section.5.5.1.p.7">Servers <em class="bcp14">SHOULD NOT</em> use the From header field for access control or authentication, since most recipients will assume that the field value is 2058 public information. 2060 2059 </p> 2061 2060 <div id="rfc.iref.r.2"></div>
Note: See TracChangeset
for help on using the changeset viewer.