Changeset 2054 for draft-ietf-httpbis
- Timestamp:
- 17/12/12 03:09:16 (10 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 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> -
draft-ietf-httpbis/latest/p2-semantics.xml
r2052 r2054 2327 2327 <x:anchor-alias value="mailbox"/> 2328 2328 <t> 2329 The "From" header field , if given, &SHOULD; contain an Internet2330 e-mail address for the human user who controls the requesting user2331 agent. The address &SHOULD; bemachine-usable, as defined by "mailbox"2329 The "From" header field contains an Internet email address for a human 2330 user who controls the requesting user agent. The address ought to be 2331 machine-usable, as defined by "mailbox" 2332 2332 in <xref x:sec="3.4" x:fmt="of" target="RFC5322"/>: 2333 2333 </t> … … 2344 2344 </artwork></figure> 2345 2345 <t> 2346 This header field &MAY; be used for logging purposes and as a means for 2347 identifying the source of invalid or unwanted requests. It &SHOULD-NOT; 2348 be used as an insecure form of access protection. The interpretation 2349 of this field is that the request is being performed on behalf of the 2350 person given, who accepts responsibility for the method performed. In 2351 particular, robot agents &SHOULD; include this header field so that the 2346 The From header field is rarely sent by non-robotic user agents. 2347 A user agent &SHOULD-NOT; send a From header field without explicit 2348 configuration by the user, since that might conflict with the user's 2349 privacy interests or their site's security policy. 2350 </t> 2351 <t> 2352 Robotic user agents &SHOULD; send a valid From header field so that the 2352 2353 person responsible for running the robot can be contacted if problems 2353 occur on the receiving end. 2354 </t> 2355 <t> 2356 The Internet e-mail address in this field &MAY; be separate from the 2357 Internet host which issued the request. For example, when a request 2358 is passed through a proxy the original issuer's address &SHOULD; be 2359 used. 2360 </t> 2361 <t> 2362 The client &SHOULD-NOT; send the From header field without the user's 2363 approval, as it might conflict with the user's privacy interests or 2364 their site's security policy. It is strongly recommended that the 2365 user be able to disable, enable, and modify the value of this field 2366 at any time prior to a request. 2354 occur on servers, such as if the robot is sending excessive, unwanted, 2355 or invalid requests. 2356 </t> 2357 <t> 2358 Servers &SHOULD-NOT; use the From header field for access control or 2359 authentication, since most recipients will assume that the field value is 2360 public information. 2367 2361 </t> 2368 2362 </section>
Note: See TracChangeset
for help on using the changeset viewer.