Changeset 697 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 25/09/09 14:43:16 (13 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r695 r697 399 399 <meta name="DC.Creator" content="Reschke, J. F."> 400 400 <meta name="DC.Identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09- 16">401 <meta name="DC.Date.Issued" scheme="ISO8601" content="2009-09-25"> 402 402 <meta name="DC.Relation.Replaces" content="urn:ietf:rfc:2616"> 403 403 <meta name="DC.Description.Abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. HTTP has been in use by the World Wide Web global information initiative since 1990. This document is Part 2 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 2 defines the semantics of HTTP messages as expressed by request methods, request-header fields, response status codes, and response-header fields."> … … 436 436 </tr> 437 437 <tr> 438 <td class="header left">Expires: March 2 0, 2010</td>438 <td class="header left">Expires: March 29, 2010</td> 439 439 <td class="header right">H. Frystyk</td> 440 440 </tr> … … 485 485 <tr> 486 486 <td class="header left"></td> 487 <td class="header right">September 16, 2009</td>487 <td class="header right">September 25, 2009</td> 488 488 </tr> 489 489 </table> … … 509 509 <p>The list of Internet-Draft Shadow Directories can be accessed at <<a href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a>>. 510 510 </p> 511 <p>This Internet-Draft will expire in March 2 0, 2010.</p>511 <p>This Internet-Draft will expire in March 29, 2010.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2009 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1503 1503 <div id="rfc.iref.h.2"></div> 1504 1504 <h2 id="rfc.section.9.1"><a href="#rfc.section.9.1">9.1</a> <a id="header.allow" href="#header.allow">Allow</a></h2> 1505 <p id="rfc.section.9.1.p.1">The response-header field "Allow"lists the set of methods advertised as supported by the resource identified by the request-target.1505 <p id="rfc.section.9.1.p.1">The "Allow" response-header field lists the set of methods advertised as supported by the resource identified by the request-target. 1506 1506 The purpose of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header 1507 1507 field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. … … 1518 1518 <div id="rfc.iref.h.3"></div> 1519 1519 <h2 id="rfc.section.9.2"><a href="#rfc.section.9.2">9.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1520 <p id="rfc.section.9.2.p.1">The request-header field "Expect"is used to indicate that particular server behaviors are required by the client.</p>1520 <p id="rfc.section.9.2.p.1">The "Expect" request-header field is used to indicate that particular server behaviors are required by the client.</p> 1521 1521 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.11"></span><span id="rfc.iref.g.12"></span><span id="rfc.iref.g.13"></span><span id="rfc.iref.g.14"></span><span id="rfc.iref.g.15"></span> <a href="#header.expect" class="smpl">Expect</a> = "Expect" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.expect" class="smpl">Expect-v</a> 1522 1522 <a href="#header.expect" class="smpl">Expect-v</a> = 1#<a href="#header.expect" class="smpl">expectation</a> … … 1544 1544 <div id="rfc.iref.h.4"></div> 1545 1545 <h2 id="rfc.section.9.3"><a href="#rfc.section.9.3">9.3</a> <a id="header.from" href="#header.from">From</a></h2> 1546 <p id="rfc.section.9.3.p.1">The request-header field "From", 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>:1546 <p id="rfc.section.9.3.p.1">The "From" request-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>: 1547 1547 </p> 1548 1548 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.16"></span><span id="rfc.iref.g.17"></span> <a href="#header.from" class="smpl">From</a> = "From" ":" <a href="#core.rules" class="smpl">OWS</a> <a href="#header.from" class="smpl">From-v</a> … … 1566 1566 <div id="rfc.iref.h.5"></div> 1567 1567 <h2 id="rfc.section.9.4"><a href="#rfc.section.9.4">9.4</a> <a id="header.location" href="#header.location">Location</a></h2> 1568 <p id="rfc.section.9.4.p.1">The response-header field "Location"is used for the identification of a new resource or to redirect the recipient to a location1568 <p id="rfc.section.9.4.p.1">The "Location" response-header field is used for the identification of a new resource or to redirect the recipient to a location 1569 1569 other than the request-target for completion of the request. For 201 (Created) responses, the Location is that of the new 1570 1570 resource which was created by the request. For 3xx responses, the location <em class="bcp14">SHOULD</em> indicate the server's preferred URI for automatic redirection to the resource. The field value consists of a single URI. … … 1587 1587 <div id="rfc.iref.h.6"></div> 1588 1588 <h2 id="rfc.section.9.5"><a href="#rfc.section.9.5">9.5</a> <a id="header.max-forwards" href="#header.max-forwards">Max-Forwards</a></h2> 1589 <p id="rfc.section.9.5.p.1">The request-header "Max-Forwards"field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be1589 <p id="rfc.section.9.5.p.1">The "Max-Forwards" request-header field provides a mechanism with the TRACE (<a href="#TRACE" id="rfc.xref.TRACE.2" title="TRACE">Section 7.8</a>) and OPTIONS (<a href="#OPTIONS" id="rfc.xref.OPTIONS.2" title="OPTIONS">Section 7.2</a>) methods to limit the number of proxies or gateways that can forward the request to the next inbound server. This can be 1590 1590 useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. 1591 1591 </p> … … 1601 1601 <div id="rfc.iref.h.7"></div> 1602 1602 <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> 1603 <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 the1603 <p id="rfc.section.9.6.p.1">The "Referer" [sic] request-header field allows the client to specify, for the server's benefit, the address (URI) of the 1604 1604 resource from which the request-target was obtained (the "referrer", although the header field is misspelled.). 1605 1605 </p> … … 1640 1640 <div id="rfc.iref.h.9"></div> 1641 1641 <h2 id="rfc.section.9.8"><a href="#rfc.section.9.8">9.8</a> <a id="header.server" href="#header.server">Server</a></h2> 1642 <p id="rfc.section.9.8.p.1">The response-header field "Server"contains information about the software used by the origin server to handle the request.1642 <p id="rfc.section.9.8.p.1">The "Server" response-header field contains information about the software used by the origin server to handle the request. 1643 1643 The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.25"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the server and any significant subproducts. The product tokens are listed in order of their significance 1644 1644 for identifying the application. … … 1660 1660 <div id="rfc.iref.h.10"></div> 1661 1661 <h2 id="rfc.section.9.9"><a href="#rfc.section.9.9">9.9</a> <a id="header.user-agent" href="#header.user-agent">User-Agent</a></h2> 1662 <p id="rfc.section.9.9.p.1">The request-header field "User-Agent"contains information about the user agent originating the request. This is for statistical1662 <p id="rfc.section.9.9.p.1">The "User-Agent" request-header field contains information about the user agent originating the request. This is for statistical 1663 1663 purposes, the tracing of protocol violations, and automated recognition of user agents for the sake of tailoring responses 1664 1664 to avoid particular user agent limitations. User agents <em class="bcp14">SHOULD</em> include this field with requests. The field can contain multiple product tokens (<a href="p1-messaging.html#product.tokens" title="Product Tokens">Section 6.3</a> of <a href="#Part1" id="rfc.xref.Part1.27"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) and comments identifying the agent and any subproducts which form a significant part of the user agent. By convention, the
Note: See TracChangeset
for help on using the changeset viewer.