Changeset 1446 for draft-ietf-httpbis/latest/p2-semantics.html
- Timestamp:
- 11/10/11 07:20:37 (11 years ago)
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p2-semantics.html
r1444 r1446 359 359 } 360 360 @bottom-center { 361 content: "Expires April 1 2, 2012";361 content: "Expires April 13, 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 0">411 <meta name="dct.issued" scheme="ISO8601" content="2011-10-11"> 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 2, 2012</td>442 <td class="left">Expires: April 13, 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 0, 2011</td>495 <td class="right">October 11, 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 2, 2012.</p>525 <p>This Internet-Draft will expire on April 13, 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> … … 869 869 </pre><p id="rfc.section.3.1.p.7">Authors of specifications defining new header fields are advised to consider documenting: </p> 870 870 <ul> 871 <li>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 872 </li> 873 <li>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses 874 to a particular request method. 875 </li> 876 <li>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 877 </li> 878 <li>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</li> 879 <li>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 880 </li> 881 <li>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 882 </li> 883 <li>Whether the header field should be preserved across redirects.</li> 871 <li> 872 <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#Part1" id="rfc.xref.Part1.19"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 873 </p> 874 <p>If it does not use the list syntax, how to treat messages where the header field occurs multiple times (a sensible default 875 would be to ignore the header field, but this might not always be the right choice). 876 </p> 877 </li> 878 <li> 879 <p>Under what conditions the header field can be used; e.g., only in responses or requests, in all messages, only on responses 880 to a particular request method. 881 </p> 882 </li> 883 <li> 884 <p>Whether it is appropriate to list the field-name in the Connection header (i.e., if the header is to be hop-by-hop, see <a href="p1-messaging.html#header.connection" title="Connection">Section 8.1</a> of <a href="#Part1" id="rfc.xref.Part1.20"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 885 </p> 886 </li> 887 <li> 888 <p>Under what conditions intermediaries are allowed to modify the header field's value, insert or delete it.</p> 889 </li> 890 <li> 891 <p>How the header might interact with caching (see <a href="#Part6" id="rfc.xref.Part6.2"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>). 892 </p> 893 </li> 894 <li> 895 <p>Whether the header field is useful or allowable in trailers (see <a href="p1-messaging.html#chunked.encoding" title="Chunked Transfer Coding">Section 5.1.1</a> of <a href="#Part1" id="rfc.xref.Part1.21"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). 896 </p> 897 </li> 898 <li> 899 <p>Whether the header field should be preserved across redirects.</p> 900 </li> 884 901 </ul> 885 902 <h2 id="rfc.section.3.2"><a href="#rfc.section.3.2">3.2</a> <a id="request.header.fields" href="#request.header.fields">Request Header Fields</a></h2>
Note: See TracChangeset
for help on using the changeset viewer.