![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 135 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 01/01/08 17:15:17 (14 years ago)
- File:
-
- 1 edited
-
draft-ietf-httpbis/latest/p2-semantics.html (modified) (15 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r133 r135 628 628 space. By convention, the products are listed in order of their significance for identifying the application. 629 629 </p> 630 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> 631 630 <div id="rfc.figure.u.1"></div><pre class="inline"><span id="rfc.iref.g.1"></span><span id="rfc.iref.g.2"></span> product = token ["/" product-version] 631 product-version = token 632 632 </pre><p id="rfc.section.2.p.3">Examples:</p> 633 633 <div id="rfc.figure.u.2"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3 … … 637 637 <h1 id="rfc.section.3"><a href="#rfc.section.3">3.</a> <a id="method" href="#method">Method</a></h1> 638 638 <p id="rfc.section.3.p.1">The Method token indicates the method to be performed on the resource identified by the Request-URI. The method is case-sensitive.</p> 639 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> 640 641 642 643 644 645 646 647 648 639 <div id="rfc.figure.u.3"></div><pre class="inline"><span id="rfc.iref.g.3"></span><span id="rfc.iref.g.4"></span> Method = "OPTIONS" ; <a href="#OPTIONS" id="rfc.xref.OPTIONS.1" title="OPTIONS">Section 8.2</a> 640 | "GET" ; <a href="#GET" id="rfc.xref.GET.1" title="GET">Section 8.3</a> 641 | "HEAD" ; <a href="#HEAD" id="rfc.xref.HEAD.1" title="HEAD">Section 8.4</a> 642 | "POST" ; <a href="#POST" id="rfc.xref.POST.1" title="POST">Section 8.5</a> 643 | "PUT" ; <a href="#PUT" id="rfc.xref.PUT.1" title="PUT">Section 8.6</a> 644 | "DELETE" ; <a href="#DELETE" id="rfc.xref.DELETE.1" title="DELETE">Section 8.7</a> 645 | "TRACE" ; <a href="#TRACE" id="rfc.xref.TRACE.1" title="TRACE">Section 8.8</a> 646 | "CONNECT" ; <a href="#CONNECT" id="rfc.xref.CONNECT.1" title="CONNECT">Section 8.9</a> 647 | extension-method 648 extension-method = token 649 649 </pre><p id="rfc.section.3.p.3">The list of methods allowed by a resource can be specified in an Allow header field (<a href="#header.allow" id="rfc.xref.header.allow.1" title="Allow">Section 10.1</a>). The return code of the response always notifies the client whether a method is currently allowed on a resource, since the 650 650 set of allowed methods can change dynamically. An origin server <em class="bcp14">SHOULD</em> return the status code 405 (Method Not Allowed) if the method is known by the origin server but not allowed for the requested … … 657 657 method invocation. 658 658 </p> 659 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> 660 661 662 663 664 665 666 667 668 669 670 671 672 673 674 675 676 677 659 <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span> request-header = Accept ; <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a> 660 | Accept-Charset ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a> 661 | Accept-Encoding ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a> 662 | Accept-Language ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a> 663 | Authorization ; <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a> 664 | Expect ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section 10.2</a> 665 | From ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section 10.3</a> 666 | Host ; <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> 667 | If-Match ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a> 668 | If-Modified-Since ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a> 669 | If-None-Match ; <a href="#Part4" id="rfc.xref.Part4.3"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-none-match" title="If-None-Match">Section 6.4</a> 670 | If-Range ; <a href="#Part5" id="rfc.xref.Part5.1"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.if-range" title="If-Range">Section 5.3</a> 671 | If-Unmodified-Since ; <a href="#Part4" id="rfc.xref.Part4.4"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-unmodified-since" title="If-Unmodified-Since">Section 6.5</a> 672 | Max-Forwards ; <a href="#header.max-forwards" id="rfc.xref.header.max-forwards.1" title="Max-Forwards">Section 10.5</a> 673 | Proxy-Authorization ; <a href="#Part7" id="rfc.xref.Part7.2"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authorization" title="Proxy-Authorization">Section 3.3</a> 674 | Range ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a> 675 | Referer ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section 10.6</a> 676 | TE ; <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a> 677 | User-Agent ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section 10.9</a> 678 678 </pre><p id="rfc.section.4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new 679 679 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of request-header fields if all parties in the communication recognize them to be request-header fields. … … 688 688 are presented below. The reason phrases listed here are only recommendations -- they <em class="bcp14">MAY</em> be replaced by local equivalents without affecting the protocol. 689 689 </p> 690 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> 690 <div id="rfc.figure.u.5"></div><pre class="inline"><span id="rfc.iref.g.6"></span><span id="rfc.iref.g.7"></span><span id="rfc.iref.g.8"></span> Status-Code = 691 691 "100" ; <a href="#status.100" id="rfc.xref.status.100.1" title="100 Continue">Section 9.1.1</a>: Continue 692 692 | "101" ; <a href="#status.101" id="rfc.xref.status.101.1" title="101 Switching Protocols">Section 9.1.2</a>: Switching Protocols … … 731 731 | extension-code 732 732 733 734 733 extension-code = 3DIGIT 734 Reason-Phrase = *<TEXT, excluding CR, LF> 735 735 </pre><p id="rfc.section.5.p.4">HTTP status codes are extensible. HTTP applications are not required to understand the meaning of all registered status codes, 736 736 though such understanding is obviously desirable. However, applications <em class="bcp14">MUST</em> understand the class of any status code, as indicated by the first digit, and treat any unrecognized response as being equivalent … … 744 744 the Request-URI. 745 745 </p> 746 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> 747 748 749 750 751 752 753 754 746 <div id="rfc.figure.u.6"></div><pre class="inline"><span id="rfc.iref.g.9"></span> response-header = Accept-Ranges ; <a href="#Part5" id="rfc.xref.Part5.3"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.accept-ranges" title="Accept-Ranges">Section 5.1</a> 747 | Age ; <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.age" title="Age">Section 3.1</a> 748 | ETag ; <a href="#Part4" id="rfc.xref.Part4.5"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> 749 | Location ; <a href="#header.location" id="rfc.xref.header.location.1" title="Location">Section 10.4</a> 750 | Proxy-Authenticate ; <a href="#Part7" id="rfc.xref.Part7.3"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.proxy-authenticate" title="Proxy-Authenticate">Section 3.2</a> 751 | Retry-After ; <a href="#header.retry-after" id="rfc.xref.header.retry-after.1" title="Retry-After">Section 10.7</a> 752 | Server ; <a href="#header.server" id="rfc.xref.header.server.1" title="Server">Section 10.8</a> 753 | Vary ; <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.vary" title="Vary">Section 3.5</a> 754 | WWW-Authenticate ; <a href="#Part7" id="rfc.xref.Part7.4"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.www-authenticate" title="WWW-Authenticate">Section 3.4</a> 755 755 </pre><p id="rfc.section.6.p.3">Response-header field names can be extended reliably only in combination with a change in the protocol version. However, new 756 756 or experimental header fields <em class="bcp14">MAY</em> be given the semantics of response-header fields if all parties in the communication recognize them to be response-header … … 1354 1354 of this field is strictly to inform the recipient of valid methods associated with the resource. An Allow header field <em class="bcp14">MUST</em> be present in a 405 (Method Not Allowed) response. 1355 1355 </p> 1356 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.11"></span> 1356 <div id="rfc.figure.u.7"></div><pre class="inline"><span id="rfc.iref.g.11"></span> Allow = "Allow" ":" #Method 1357 1357 </pre><p id="rfc.section.10.1.p.3">Example of use:</p> 1358 1358 <div id="rfc.figure.u.8"></div><pre class="text"> Allow: GET, HEAD, PUT … … 1369 1369 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="header.expect" href="#header.expect">Expect</a></h2> 1370 1370 <p id="rfc.section.10.2.p.1">The Expect request-header field is used to indicate that particular server behaviors are required by the client.</p> 1371 <div id="rfc.figure.u.9"></div><pre class="inline"><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> 1372 1373 1374 1375 1376 1371 <div id="rfc.figure.u.9"></div><pre class="inline"><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> Expect = "Expect" ":" 1#expectation 1372 1373 expectation = "100-continue" | expectation-extension 1374 expectation-extension = token [ "=" ( token | quoted-string ) 1375 *expect-params ] 1376 expect-params = ";" token [ "=" ( token | quoted-string ) ] 1377 1377 </pre><p id="rfc.section.10.2.p.3">A server that does not understand or is unable to comply with any of the expectation values in the Expect field of a request <em class="bcp14">MUST</em> respond with appropriate error status. The server <em class="bcp14">MUST</em> respond with a 417 (Expectation Failed) status if any of the expectations cannot be met or, if there are other problems with 1378 1378 the request, some other 4xx status. … … 1395 1395 <p id="rfc.section.10.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/rfc2822#section-3.4">Section 3.4</a> of <a href="#RFC2822" id="rfc.xref.RFC2822.1"><cite title="Internet Message Format">[RFC2822]</cite></a>: 1396 1396 </p> 1397 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> 1397 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.16"></span> From = "From" ":" mailbox 1398 1398 </pre><p id="rfc.section.10.3.p.3">An example is:</p> 1399 1399 <div id="rfc.figure.u.11"></div><pre class="text"> From: webmaster@example.org … … 1417 1417 URI. 1418 1418 </p> 1419 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span> 1419 <div id="rfc.figure.u.12"></div><pre class="inline"><span id="rfc.iref.g.17"></span> Location = "Location" ":" absoluteURI [ "#" fragment ] 1420 1420 </pre><p id="rfc.section.10.4.p.3">An example is:</p> 1421 1421 <div id="rfc.figure.u.13"></div><pre class="text"> Location: http://www.example.org/pub/WWW/People.html … … 1440 1440 useful when the client is attempting to trace a request chain which appears to be failing or looping in mid-chain. 1441 1441 </p> 1442 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.18"></span> 1442 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.18"></span> Max-Forwards = "Max-Forwards" ":" 1*DIGIT 1443 1443 </pre><p id="rfc.section.10.5.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message may be forwarded.</p> 1444 1444 <p id="rfc.section.10.5.p.4">Each proxy or gateway recipient of a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the recipient <em class="bcp14">MUST NOT</em> forward the request; instead, it <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, then the forwarded message <em class="bcp14">MUST</em> contain an updated Max-Forwards field with a value decremented by one (1). … … 1455 1455 obsolete or mistyped links to be traced for maintenance. The Referer field <em class="bcp14">MUST NOT</em> be sent if the Request-URI was obtained from a source that does not have its own URI, such as input from the user keyboard. 1456 1456 </p> 1457 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span> 1457 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.19"></span> Referer = "Referer" ":" ( absoluteURI | relativeURI ) 1458 1458 </pre><p id="rfc.section.10.6.p.3">Example:</p> 1459 1459 <div id="rfc.figure.u.16"></div><pre class="text"> Referer: http://www.example.org/hypertext/Overview.html … … 1468 1468 the time of the response. 1469 1469 </p> 1470 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.20"></span> 1470 <div id="rfc.figure.u.17"></div><pre class="inline"><span id="rfc.iref.g.20"></span> Retry-After = "Retry-After" ":" ( HTTP-date | delta-seconds ) 1471 1471 </pre><p id="rfc.section.10.7.p.3">Two examples of its use are</p> 1472 1472 <div id="rfc.figure.u.18"></div><pre class="text"> Retry-After: Fri, 31 Dec 1999 23:59:59 GMT … … 1480 1480 for identifying the application. 1481 1481 </p> 1482 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.21"></span> 1482 <div id="rfc.figure.u.19"></div><pre class="inline"><span id="rfc.iref.g.21"></span> Server = "Server" ":" 1*( product | comment ) 1483 1483 </pre><p id="rfc.section.10.8.p.3">Example:</p> 1484 1484 <div id="rfc.figure.u.20"></div><pre class="text"> Server: CERN/3.0 libwww/2.17 … … 1499 1499 product tokens are listed in order of their significance for identifying the application. 1500 1500 </p> 1501 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span> 1501 <div id="rfc.figure.u.21"></div><pre class="inline"><span id="rfc.iref.g.22"></span> User-Agent = "User-Agent" ":" 1*( product | comment ) 1502 1502 </pre><p id="rfc.section.10.9.p.3">Example:</p> 1503 1503 <div id="rfc.figure.u.22"></div><pre class="text"> User-Agent: CERN-LineMode/2.15 libwww/2.17b3
Note: See TracChangeset
for help on using the changeset viewer.
