![(please configure the [header_logo] section in trac.ini)](https://www.ietf.org/images/ietflogotrans.gif)
Changeset 1448 for draft-ietf-httpbis
- Timestamp:
- 16/10/11 12:32:05 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 2 edited
-
p2-semantics.html (modified) (14 diffs)
-
p2-semantics.xml (modified) (3 diffs)
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1446 r1448 359 359 } 360 360 @bottom-center { 361 content: "Expires April 1 3, 2012";361 content: "Expires April 18, 2012"; 362 362 } 363 363 @bottom-right { … … 409 409 <meta name="dct.creator" content="Reschke, J. F."> 410 410 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-1 1">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-16"> 412 412 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 413 413 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypertext 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."> … … 440 440 </tr> 441 441 <tr> 442 <td class="left">Expires: April 1 3, 2012</td>442 <td class="left">Expires: April 18, 2012</td> 443 443 <td class="right">HP</td> 444 444 </tr> … … 493 493 <tr> 494 494 <td class="left"></td> 495 <td class="right">October 1 1, 2011</td>495 <td class="right">October 16, 2011</td> 496 496 </tr> 497 497 </tbody> … … 523 523 in progress”. 524 524 </p> 525 <p>This Internet-Draft will expire on April 1 3, 2012.</p>525 <p>This Internet-Draft will expire on April 18, 2012.</p> 526 526 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 527 527 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 867 867 "http://without-a-comma.example.com/" 868 868 Example-Date-Field: "Sat, 04 May 1996", "Wed, 14 Sep 2005" 869 </pre><p id="rfc.section.3.1.p.7">Authors of specifications defining new header fields are advised to consider documenting: </p> 869 </pre><p id="rfc.section.3.1.p.7">Many header fields use a format including named parameters (for instance, Content-Type, defined in <a href="p3-payload.html#header.content-type" title="Content-Type">Section 6.8</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). Allowing both unquoted (token) and quoted (quoted-string) syntax for the parameter value enables recipients to use existing 870 parser components. Also, the meaning of a value ought to be independent of the syntax variant used for it (for an example, 871 see the notes on parameter handling for media types in <a href="p3-payload.html#media.types" title="Media Types">Section 2.3</a> of <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 872 </p> 873 <p id="rfc.section.3.1.p.8">Authors of specifications defining new header fields are advised to consider documenting: </p> 870 874 <ul> 871 875 <li> … … 916 920 <tr> 917 921 <td class="left">Accept</td> 918 <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3. 1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>922 <td class="left"><a href="p3-payload.html#header.accept" title="Accept">Section 6.1</a> of <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 919 923 </tr> 920 924 <tr> 921 925 <td class="left">Accept-Charset</td> 922 <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3. 2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>926 <td class="left"><a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 6.2</a> of <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 923 927 </tr> 924 928 <tr> 925 929 <td class="left">Accept-Encoding</td> 926 <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3. 3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>930 <td class="left"><a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 6.3</a> of <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 927 931 </tr> 928 932 <tr> 929 933 <td class="left">Accept-Language</td> 930 <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3. 4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td>934 <td class="left"><a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 6.4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a></td> 931 935 </tr> 932 936 <tr> … … 1315 1319 <p id="rfc.section.5.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer a representation if not otherwise restricted by the request method or response status code. A representation consists 1316 1320 of metadata (representation header fields) and data (representation body). When a complete or partial representation is enclosed 1317 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3. 5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.1321 in an HTTP message, it is referred to as the payload of the message. HTTP representations are defined in <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>. 1318 1322 </p> 1319 1323 <p id="rfc.section.5.p.2">A representation body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 3.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>. The representation body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied … … 1455 1459 a Location header field (see <a href="#header.location" id="rfc.xref.header.location.2" title="Location">Section 9.5</a>). 1456 1460 </p> 1457 <p id="rfc.section.6.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3. 6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests.1461 <p id="rfc.section.6.5.p.5">Responses to POST requests are only cacheable when they include explicit freshness information (see <a href="p6-cache.html#calculating.freshness.lifetime" title="Calculating Freshness Lifetime">Section 2.3.1</a> of <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). A cached POST response with a Content-Location header field (see <a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) whose value is the effective Request URI <em class="bcp14">MAY</em> be used to satisfy subsequent GET and HEAD requests. 1458 1462 </p> 1459 1463 <p id="rfc.section.6.5.p.6">Note that POST caching is not widely implemented. However, the 303 (See Other) response can be used to direct the user agent … … 1743 1747 </li> 1744 1748 <li> 1745 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3. 7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices).1749 <p>Redirection offering a choice of matching resources for use by agent-driven content negotiation (<a href="p3-payload.html#agent-driven.negotiation" title="Agent-driven Negotiation">Section 5.2</a> of <a href="#Part3" id="rfc.xref.Part3.9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). This is status code 300 (Multiple Choices). 1746 1750 </p> 1747 1751 </li> … … 1769 1773 <h3 id="rfc.section.7.3.1"><a href="#rfc.section.7.3.1">7.3.1</a> <a id="status.300" href="#status.300">300 Multiple Choices</a></h3> 1770 1774 <p id="rfc.section.7.3.1.p.1">The target resource has more than one representation, each with its own specific location, and agent-driven negotiation information 1771 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3. 8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that1775 (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 5</a> of <a href="#Part3" id="rfc.xref.Part3.10"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation by redirecting its request to that 1772 1776 location. 1773 1777 </p> … … 1909 1913 <h3 id="rfc.section.7.4.7"><a href="#rfc.section.7.4.7">7.4.7</a> <a id="status.406" href="#status.406">406 Not Acceptable</a></h3> 1910 1914 <p id="rfc.section.7.4.7.p.1">The resource identified by the request is only capable of generating response representations which have content characteristics 1911 not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3. 9"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>).1915 not acceptable according to the Accept and Accept-* header fields sent in the request (see <a href="p3-payload.html#header.field.definitions" title="Header Field Definitions">Section 6</a> of <a href="#Part3" id="rfc.xref.Part3.11"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>). 1912 1916 </p> 1913 1917 <p id="rfc.section.7.4.7.p.2">Unless it was a HEAD request, the response <em class="bcp14">SHOULD</em> include a representation containing a list of available representation characteristics and location(s) from which the user … … 2274 2278 </div> 2275 2279 <div class="note" id="rfc.section.9.5.p.9"> 2276 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.1 0"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation.2280 <p> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 6.7</a> of <a href="#Part3" id="rfc.xref.Part3.12"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the most specific resource corresponding to the enclosed representation. 2277 2281 It is therefore possible for a response to contain header fields for both Location and Content-Location. 2278 2282 </p> … … 3570 3574 </ul> 3571 3575 </li> 3572 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.2</a>, <a href="#rfc.xref.Part3.2">3.2</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">5</a>, <a href="#rfc.xref.Part3.6">6.5</a>, <a href="#rfc.xref.Part3.7">7.3</a>, <a href="#rfc.xref.Part3.8">7.3.1</a>, <a href="#rfc.xref.Part3.9">7.4.7</a>, <a href="#rfc.xref.Part3.10">9.5</a>, <a href="#Part3"><b>13.1</b></a><ul> 3573 <li><em>Section 5</em> <a href="#rfc.xref.Part3.8">7.3.1</a></li> 3574 <li><em>Section 5.2</em> <a href="#rfc.xref.Part3.7">7.3</a></li> 3575 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.1">3.2</a></li> 3576 <li><em>Section 6</em> <a href="#rfc.xref.Part3.9">7.4.7</a></li> 3577 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.2">3.2</a></li> 3578 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.3">3.2</a></li> 3579 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.4">3.2</a></li> 3580 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.6">6.5</a>, <a href="#rfc.xref.Part3.10">9.5</a></li> 3576 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">3.1</a>, <a href="#rfc.xref.Part3.2">3.1</a>, <a href="#rfc.xref.Part3.3">3.2</a>, <a href="#rfc.xref.Part3.4">3.2</a>, <a href="#rfc.xref.Part3.5">3.2</a>, <a href="#rfc.xref.Part3.6">3.2</a>, <a href="#rfc.xref.Part3.7">5</a>, <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.9">7.3</a>, <a href="#rfc.xref.Part3.10">7.3.1</a>, <a href="#rfc.xref.Part3.11">7.4.7</a>, <a href="#rfc.xref.Part3.12">9.5</a>, <a href="#Part3"><b>13.1</b></a><ul> 3577 <li><em>Section 2.3</em> <a href="#rfc.xref.Part3.2">3.1</a></li> 3578 <li><em>Section 5</em> <a href="#rfc.xref.Part3.10">7.3.1</a></li> 3579 <li><em>Section 5.2</em> <a href="#rfc.xref.Part3.9">7.3</a></li> 3580 <li><em>Section 6.1</em> <a href="#rfc.xref.Part3.3">3.2</a></li> 3581 <li><em>Section 6</em> <a href="#rfc.xref.Part3.11">7.4.7</a></li> 3582 <li><em>Section 6.2</em> <a href="#rfc.xref.Part3.4">3.2</a></li> 3583 <li><em>Section 6.3</em> <a href="#rfc.xref.Part3.5">3.2</a></li> 3584 <li><em>Section 6.4</em> <a href="#rfc.xref.Part3.6">3.2</a></li> 3585 <li><em>Section 6.7</em> <a href="#rfc.xref.Part3.8">6.5</a>, <a href="#rfc.xref.Part3.12">9.5</a></li> 3586 <li><em>Section 6.8</em> <a href="#rfc.xref.Part3.1">3.1</a></li> 3581 3587 </ul> 3582 3588 </li> -
draft-ietf-httpbis/latest/p2-semantics.xml
r1446 r1448 49 49 <!ENTITY header-content-location "<xref target='Part3' x:rel='#header.content-location' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 50 50 <!ENTITY header-content-range "<xref target='Part5' x:rel='#header.content-range' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 51 <!ENTITY header-content-type "<xref target='Part3' x:rel='#header.content-type' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 51 52 <!ENTITY header-etag "<xref target='Part4' x:rel='#header.etag' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 52 53 <!ENTITY header-expires "<xref target='Part6' x:rel='#header.expires' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 68 69 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 69 70 <!ENTITY header-www-authenticate "<xref target='Part7' x:rel='#header.www-authenticate' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 71 <!ENTITY media-types "<xref target='Part3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 70 72 <!ENTITY message-body "<xref target='Part1' x:rel='#message.body' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 71 73 <!ENTITY product-tokens "<xref target='Part1' x:rel='#product.tokens' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 522 524 </artwork></figure> 523 525 <t> 526 Many header fields use a format including named parameters (for instance, 527 Content-Type, defined in &header-content-type;). Allowing both unquoted 528 (token) and quoted (quoted-string) syntax for the parameter value enables 529 recipients to use existing parser components. Also, the meaning of a value 530 ought to be independent of the syntax variant used for it (for an example, 531 see the notes on parameter handling for media types in &media-types;). 532 </t> 533 <t> 524 534 Authors of specifications defining new header fields are advised to consider 525 535 documenting:
Note: See TracChangeset
for help on using the changeset viewer.
