Changeset 1101 for draft-ietf-httpbis
- Timestamp:
- 08/01/11 14:27:21 (11 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 11 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r1099 r1101 404 404 <meta name="dct.creator" content="Reschke, J. F."> 405 405 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest"> 406 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">406 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 407 407 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 408 408 <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 1 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations."> … … 435 435 </tr> 436 436 <tr> 437 <td class="left">Expires: July 5, 2011</td>437 <td class="left">Expires: July 12, 2011</td> 438 438 <td class="right">HP</td> 439 439 </tr> … … 488 488 <tr> 489 489 <td class="left"></td> 490 <td class="right">January 1, 2011</td>490 <td class="right">January 8, 2011</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire on July 5, 2011.</p>518 <p>This Internet-Draft will expire on July 12, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 712 712 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 713 713 Uniform Resource Identifier (URI) standard <a href="#RFC3986" id="rfc.xref.RFC3986.1"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a> to indicate request targets and relationships between resources. Messages are passed in a format similar to that used by Internet 714 mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title=" Differences between HTTP and MIME">Appendix A</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> for the differences between HTTP and MIME messages).714 mail <a href="#RFC5322" id="rfc.xref.RFC5322.1"><cite title="Internet Message Format">[RFC5322]</cite></a> and the Multipurpose Internet Mail Extensions (MIME) <a href="#RFC2045" id="rfc.xref.RFC2045.1"><cite title="Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies">[RFC2045]</cite></a> (see <a href="p3-payload.html#differences.between.http.and.mime" title="ERROR: Anchor 'differences.between.http.and.mime' not found in p3-payload.xml.">Appendix ERROR: Anchor 'differences.between.http.and.mime' in Part3 not found in source file 'p3-payload.xml'.</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> for the differences between HTTP and MIME messages). 715 715 </p> 716 716 <p id="rfc.section.1.p.2">HTTP is a generic interface protocol for information systems. It is designed to hide the details of how a service is implemented … … 860 860 <div id="rfc.figure.u.12"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">request-header</a> = <request-header, defined in <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#request.header.fields" title="Request Header Fields">Section 3</a>> 861 861 <a href="#abnf.dependencies" class="smpl">response-header</a> = <response-header, defined in <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, <a href="p2-semantics.html#response.header.fields" title="Response Header Fields">Section 5</a>> 862 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in <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#mime-version" title=" MIME-Version">Appendix A.1</a>>862 </pre><div id="rfc.figure.u.13"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">MIME-Version</a> = <MIME-Version, defined in <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#mime-version" title="ERROR: Anchor 'mime-version' not found in p3-payload.xml.">Appendix ERROR: Anchor 'mime-version' in Part3 not found in source file 'p3-payload.xml'.</a>> 863 863 </pre><div id="rfc.figure.u.14"></div><pre class="inline"> <a href="#abnf.dependencies" class="smpl">Cache-Control</a> = <Cache-Control, defined in <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.pragma" title="Pragma">Section 3.4</a>> 864 864 <a href="#abnf.dependencies" class="smpl">Pragma</a> = <Pragma, defined in <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.pragma" title="Pragma">Section 3.4</a>> … … 1080 1080 would presumably be identified using a different URI scheme, just as the "https" scheme (below) is used for servers that require 1081 1081 an SSL/TLS transport layer on a connection. Other protocols might also be used to provide access to "http" identified resources 1082 ---it is only the authoritative interface used for mapping the namespace that is specific to TCP.1082 — it is only the authoritative interface used for mapping the namespace that is specific to TCP. 1083 1083 </p> 1084 1084 <p id="rfc.section.2.6.1.p.7">The URI generic syntax for authority also includes a deprecated userinfo subcomponent (<a href="#RFC3986" id="rfc.xref.RFC3986.15"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.2.1">Section 3.2.1</a>) for including user authentication information in the URI. The userinfo subcomponent (and its "@" delimiter) <em class="bcp14">MUST NOT</em> be used in an "http" URI. URI reference recipients <em class="bcp14">SHOULD</em> parse for the existence of userinfo and treat its presence as an error, likely indicating that the deprecated subcomponent … … 1313 1313 / <a href="#header.via" class="smpl">Via</a> ; <a href="#header.via" id="rfc.xref.header.via.1" title="Via">Section 9.9</a> 1314 1314 / <a href="#abnf.dependencies" class="smpl">Warning</a> ; <a href="#Part6" id="rfc.xref.Part6.8"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>, <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> 1315 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a> ; <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#mime-version" title=" MIME-Version">Appendix A.1</a>1315 / <a href="#abnf.dependencies" class="smpl">MIME-Version</a> ; <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#mime-version" title="ERROR: Anchor 'mime-version' not found in p3-payload.xml.">Appendix ERROR: Anchor 'mime-version' in Part3 not found in source file 'p3-payload.xml'.</a> 1316 1316 </pre><p id="rfc.section.3.4.p.3">General-header field names can be extended reliably only in combination with a change in the protocol version. However, new 1317 1317 or experimental header fields might be given the semantics of general header fields if all parties in the communication recognize … … 1707 1707 <li>Pointer to specification text</li> 1708 1708 </ul> 1709 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title=" Content Codings">Section 2.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>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>).1709 <p id="rfc.section.6.2.3.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p3-payload.html#content.codings" title="ERROR: Anchor 'content.codings' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.codings' in Part3 not found in source file 'p3-payload.xml'.</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>), unless the encoding transformation is identical (as it is the case for the compression codings defined in <a href="#compression.codings" title="Compression Codings">Section 6.2.2</a>). 1710 1710 </p> 1711 1711 <p id="rfc.section.6.2.3.p.4">Values to be added to this name space require a specification (see "Specification Required" in <a href="http://tools.ietf.org/html/rfc5226#section-4.1">Section 4.1</a> of <a href="#RFC5226" id="rfc.xref.RFC5226.1"><cite title="Guidelines for Writing an IANA Considerations Section in RFCs">[RFC5226]</cite></a>), and <em class="bcp14">MUST</em> conform to the purpose of transfer coding defined in this section. … … 1726 1726 </p> 1727 1727 <h2 id="rfc.section.6.4"><a href="#rfc.section.6.4">6.4</a> <a id="quality.values" href="#quality.values">Quality Values</a></h2> 1728 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title=" Content Negotiation">Section 5</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>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight1728 <p id="rfc.section.6.4.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 9.5</a>) and content negotiation (<a href="p3-payload.html#content.negotiation" title="ERROR: Anchor 'content.negotiation' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.negotiation' in Part3 not found in source file 'p3-payload.xml'.</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>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1729 1729 is normalized to a real number in the range 0 through 1, where 0 is the minimum and 1 the maximum value. If a parameter has 1730 1730 a quality value of 0, then content with this parameter is "not acceptable" for the client. HTTP/1.1 applications <em class="bcp14">MUST NOT</em> generate more than three digits after the decimal point. User configuration of these values <em class="bcp14">SHOULD</em> also be limited in this fashion. … … 2183 2183 <h2 id="rfc.section.9.7"><a href="#rfc.section.9.7">9.7</a> <a id="header.transfer-encoding" href="#header.transfer-encoding">Transfer-Encoding</a></h2> 2184 2184 <p id="rfc.section.9.7.p.1">The "Transfer-Encoding" general-header field indicates what transfer-codings (if any) have been applied to the message body. 2185 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title=" Content Codings">Section 2.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>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings2185 It differs from Content-Encoding (<a href="p3-payload.html#content.codings" title="ERROR: Anchor 'content.codings' not found in p3-payload.xml.">Appendix ERROR: Anchor 'content.codings' in Part3 not found in source file 'p3-payload.xml'.</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>) in that transfer-codings are a property of the message (and therefore are removed by intermediaries), whereas content-codings 2186 2186 are not. 2187 2187 </p> … … 2407 2407 </dd> 2408 2408 <dt>msgtype:</dt> 2409 <dd>The message type --"request" or "response". If not present, the type can be determined from the first line of the body.</dd>2409 <dd>The message type — "request" or "response". If not present, the type can be determined from the first line of the body.</dd> 2410 2410 </dl> 2411 2411 </dd> … … 2460 2460 </dd> 2461 2461 <dt>msgtype:</dt> 2462 <dd>The message type --"request" or "response". If not present, the type can be determined from the first line of the body.</dd>2462 <dd>The message type — "request" or "response". If not present, the type can be determined from the first line of the body.</dd> 2463 2463 </dl> 2464 2464 </dd> … … 2540 2540 </div> 2541 2541 <h2 id="rfc.section.10.5"><a href="#rfc.section.10.5">10.5</a> <a id="upgrade.token.registration" href="#upgrade.token.registration">Upgrade Token Registration</a></h2> 2542 <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> --is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 9.8.1</a> of this document.2542 <p id="rfc.section.10.5.p.1">The registration procedure for HTTP Upgrade Tokens — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.2">Section 7.2</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#upgrade.token.registry" title="Upgrade Token Registry">Section 9.8.1</a> of this document. 2543 2543 </p> 2544 2544 <p id="rfc.section.10.5.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-upgrade-tokens/">http://www.iana.org/assignments/http-upgrade-tokens/</a>> shall be updated with the registration below: … … 2631 2631 <p id="rfc.section.11.6.p.1">They exist. They are hard to defend against. Research continues. Beware.</p> 2632 2632 <h1 id="rfc.section.12"><a href="#rfc.section.12">12.</a> <a id="ack" href="#ack">Acknowledgments</a></h1> 2633 <p id="rfc.section.12.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community --the many people2634 who have participated on the www-talk mailing list --and it is that community which has been most responsible for the success2633 <p id="rfc.section.12.p.1">HTTP has evolved considerably over the years. It has benefited from a large and active developer community — the many people 2634 who have participated on the www-talk mailing list — and it is that community which has been most responsible for the success 2635 2635 of HTTP and of the World-Wide Web in general. Marc Andreessen, Robert Cailliau, Daniel W. Connolly, Bob Denny, John Franks, 2636 2636 Jean-Francois Groff, Phillip M. Hallam-Baker, Hakon W. Lie, Ari Luotonen, Rob McCool, Lou Montulli, Dave Raggett, Tony Sanders, … … 3261 3261 <li>Avoid underscore character in rule names ("http_URL" -> "http-URL", "abs_path" -> "path-absolute").</li> 3262 3262 <li>Add rules for terms imported from URI spec ("absoluteURI", "authority", "path-absolute", "port", "query", "relativeURI", "host) 3263 --these will have to be updated when switching over to RFC3986.3263 — these will have to be updated when switching over to RFC3986. 3264 3264 </li> 3265 3265 <li>Synchronize core rules with RFC5234.</li> … … 3725 3725 </li> 3726 3726 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a>, <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.5">6.4</a>, <a href="#rfc.xref.Part3.6">7.1.3.2</a>, <a href="#rfc.xref.Part3.7">9.7</a>, <a href="#Part3"><b>13.1</b></a>, <a href="#rfc.xref.Part3.8">A</a><ul> 3727 <li><em> Section 2.2</em> <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li>3728 <li><em> Section 5</em> <a href="#rfc.xref.Part3.5">6.4</a></li>3729 <li><em>Appendix A</em> <a href="#rfc.xref.Part3.1">1</a></li>3730 <li><em>Appendix A.1</em> <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li>3727 <li><em>Appendix </em> <a href="#rfc.xref.Part3.1">1</a></li> 3728 <li><em>Appendix </em> <a href="#rfc.xref.Part3.2">1.2.3</a>, <a href="#rfc.xref.Part3.3">3.4</a></li> 3729 <li><em>Appendix </em> <a href="#rfc.xref.Part3.4">6.2.3</a>, <a href="#rfc.xref.Part3.7">9.7</a></li> 3730 <li><em>Appendix </em> <a href="#rfc.xref.Part3.5">6.4</a></li> 3731 3731 </ul> 3732 3732 </li> -
draft-ietf-httpbis/latest/p1-messaging.xml
r1099 r1101 15 15 <!ENTITY ID-MONTH "January"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY mdash "—"> 17 18 <!ENTITY caching-overview "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY cache-incomplete "<xref target='Part6' x:rel='#errors.or.incomplete.response.cache.behavior' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 961 962 the "https" scheme (below) is used for servers that require an SSL/TLS 962 963 transport layer on a connection. Other protocols might also be used to 963 provide access to "http" identified resources ---it is only the964 provide access to "http" identified resources — it is only the 964 965 authoritative interface used for mapping the namespace that is 965 966 specific to TCP. … … 3569 3570 </t> 3570 3571 <t hangText="msgtype:"> 3571 The message type --"request" or "response". If not3572 The message type — "request" or "response". If not 3572 3573 present, the type can be determined from the first 3573 3574 line of the body. … … 3638 3639 </t> 3639 3640 <t hangText="msgtype:"> 3640 The message type --"request" or "response". If not3641 The message type — "request" or "response". If not 3641 3642 present, the type can be determined from the first 3642 3643 line of the body. … … 3725 3726 <section title="Upgrade Token Registration" anchor="upgrade.token.registration"> 3726 3727 <t> 3727 The registration procedure for HTTP Upgrade Tokens --previously defined3728 in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> --is now defined3728 The registration procedure for HTTP Upgrade Tokens — previously defined 3729 in <xref target="RFC2817" x:fmt="of" x:sec="7.2"/> — is now defined 3729 3730 by <xref target="upgrade.token.registry"/> of this document. 3730 3731 </t> … … 3895 3896 <t> 3896 3897 HTTP has evolved considerably over the years. It has 3897 benefited from a large and active developer community --the many3898 people who have participated on the www-talk mailing list --and it is3898 benefited from a large and active developer community — the many 3899 people who have participated on the www-talk mailing list — and it is 3899 3900 that community which has been most responsible for the success of 3900 3901 HTTP and of the World-Wide Web in general. Marc Andreessen, Robert … … 5267 5268 <t> 5268 5269 Add rules for terms imported from URI spec ("absoluteURI", "authority", 5269 "path-absolute", "port", "query", "relativeURI", "host) --these will5270 "path-absolute", "port", "query", "relativeURI", "host) — these will 5270 5271 have to be updated when switching over to RFC3986. 5271 5272 </t> -
draft-ietf-httpbis/latest/p2-semantics.html
r1099 r1101 403 403 <meta name="dct.creator" content="Reschke, J. F."> 404 404 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest"> 405 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">405 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 406 406 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 407 407 <meta name="dct.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."> … … 434 434 </tr> 435 435 <tr> 436 <td class="left">Expires: July 5, 2011</td>436 <td class="left">Expires: July 12, 2011</td> 437 437 <td class="right">HP</td> 438 438 </tr> … … 487 487 <tr> 488 488 <td class="left"></td> 489 <td class="right">January 1, 2011</td>489 <td class="right">January 8, 2011</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire on July 5, 2011.</p>516 <p>This Internet-Draft will expire on July 12, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 848 848 </p> 849 849 <p id="rfc.section.4.p.3">The individual values of the numeric status codes defined for HTTP/1.1, and an example set of corresponding Reason-Phrase 850 values, 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.850 values, 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. 851 851 </p> 852 852 <div id="rfc.figure.u.10"></div><pre class="inline"><span id="rfc.iref.g.4"></span><span id="rfc.iref.g.5"></span><span id="rfc.iref.g.6"></span> <a href="#status.code.and.reason.phrase" class="smpl">Status-Code</a> = … … 1152 1152 Host: server.example.com:80 1153 1153 1154 </pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method --except end-to-end protocol Upgrade requests, since the1154 </pre><p id="rfc.section.7.9.p.4">Other HTTP mechanisms can be used normally with the CONNECT method — except end-to-end protocol Upgrade requests, since the 1155 1155 tunnel must be established first. 1156 1156 </p> … … 1492 1492 is common for limited-time, promotional services and for resources belonging to individuals no longer working at the server's 1493 1493 site. It is not necessary to mark all permanently unavailable resources as "gone" or to keep the mark for any length of time 1494 --that is left to the discretion of the server owner.1494 — that is left to the discretion of the server owner. 1495 1495 </p> 1496 1496 <p id="rfc.section.8.4.11.p.3">Caches <em class="bcp14">MAY</em> use a heuristic (see <a href="p6-cache.html#heuristic.freshness" title="Calculating Heuristic Freshness">Section 2.3.1.1</a> of <a href="#Part6" id="rfc.xref.Part6.16"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>) to determine freshness for 410 responses. … … 1617 1617 <div id="rfc.figure.u.16"></div><pre class="text"> Allow: GET, HEAD, PUT 1618 1618 </pre><p id="rfc.section.9.1.p.5">The actual set of allowed methods is defined by the origin server at the time of each request.</p> 1619 <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field --it does not need to understand all the methods specified in order to handle them according1619 <p id="rfc.section.9.1.p.6">A proxy <em class="bcp14">MUST NOT</em> modify the Allow header field — it does not need to understand all the methods specified in order to handle them according 1620 1620 to the generic message handling rules. 1621 1621 </p> … … 1864 1864 </div> 1865 1865 <h2 id="rfc.section.10.2"><a href="#rfc.section.10.2">10.2</a> <a id="status.code.registration" href="#status.code.registration">Status Code Registry</a></h2> 1866 <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes -- previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> --is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.1</a> of this document.1866 <p id="rfc.section.10.2.p.1">The registration procedure for HTTP Status Codes — previously defined in <a href="http://tools.ietf.org/html/rfc2817#section-7.1">Section 7.1</a> of <a href="#RFC2817" id="rfc.xref.RFC2817.1"><cite title="Upgrading to TLS Within HTTP/1.1">[RFC2817]</cite></a> — is now defined by <a href="#status.code.registry" title="Status Code Registry">Section 4.1</a> of this document. 1867 1867 </p> 1868 1868 <p id="rfc.section.10.2.p.2">The HTTP Status Code Registry located at <<a href="http://www.iana.org/assignments/http-status-codes">http://www.iana.org/assignments/http-status-codes</a>> shall be updated with the registrations below: -
draft-ietf-httpbis/latest/p2-semantics.xml
r1099 r1101 15 15 <!ENTITY ID-MONTH "January"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY mdash "—"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY messaging "<xref target='Part1' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 573 574 HTTP/1.1, and an example set of corresponding Reason-Phrase values, are 574 575 presented below. The reason phrases listed here are only 575 recommendations --they &MAY; be replaced by local equivalents without576 recommendations — they &MAY; be replaced by local equivalents without 576 577 affecting the protocol. 577 578 </t> … … 1159 1160 </artwork></figure> 1160 1161 <t> 1161 Other HTTP mechanisms can be used normally with the CONNECT method --1162 Other HTTP mechanisms can be used normally with the CONNECT method — 1162 1163 except end-to-end protocol Upgrade requests, since the 1163 1164 tunnel must be established first. … … 1854 1855 individuals no longer working at the server's site. It is not 1855 1856 necessary to mark all permanently unavailable resources as "gone" or 1856 to keep the mark for any length of time --that is left to the1857 to keep the mark for any length of time — that is left to the 1857 1858 discretion of the server owner. 1858 1859 </t> … … 2105 2106 </t> 2106 2107 <t> 2107 A proxy &MUST-NOT; modify the Allow header field --it does not need to2108 A proxy &MUST-NOT; modify the Allow header field — it does not need to 2108 2109 understand all the methods specified in order to handle them according to 2109 2110 the generic message handling rules. … … 2550 2551 <section title="Status Code Registry" anchor="status.code.registration"> 2551 2552 <t> 2552 The registration procedure for HTTP Status Codes --previously defined2553 in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> --is now defined2553 The registration procedure for HTTP Status Codes — previously defined 2554 in <xref target="RFC2817" x:fmt="of" x:sec="7.1"/> — is now defined 2554 2555 by <xref target="status.code.registry"/> of this document. 2555 2556 </t> -
draft-ietf-httpbis/latest/p3-payload.html
r1099 r1101 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.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 3 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: July 5, 2011</td>430 <td class="left">Expires: July 12, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 485 485 <tr> 486 486 <td class="left"></td> 487 <td class="right">January 1, 2011</td>487 <td class="right">January 8, 2011</td> 488 488 </tr> 489 489 </tbody> … … 511 511 in progress”. 512 512 </p> 513 <p>This Internet-Draft will expire on July 5, 2011.</p>513 <p>This Internet-Draft will expire on July 12, 2011.</p> 514 514 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 515 515 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 813 813 </p> 814 814 <h3 id="rfc.section.2.3.2"><a href="#rfc.section.2.3.2">2.3.2</a> <a id="multipart.types" href="#multipart.types">Multipart Types</a></h3> 815 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types --encapsulations of one or more representations within a single message-body.815 <p id="rfc.section.2.3.2.p.1">MIME provides for a number of "multipart" types — encapsulations of one or more representations within a single message-body. 816 816 All multipart types share a common syntax, as defined in <a href="http://tools.ietf.org/html/rfc2046#section-5.1.1">Section 5.1.1</a> of <a href="#RFC2046" id="rfc.xref.RFC2046.2"><cite title="Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types">[RFC2046]</cite></a>, and <em class="bcp14">MUST</em> include a boundary parameter as part of the media type value. The message body is itself a protocol element and <em class="bcp14">MUST</em> therefore use only CRLF to represent line breaks between body-parts. 817 817 </p> … … 923 923 <p id="rfc.section.5.p.2">HTTP clients and their users might have different or variable capabilities, characteristics or preferences which would influence 924 924 which representation, among those available from the server, would be best for the server to deliver. For this reason, HTTP 925 provides mechanisms for "content negotiation" -- a process of allowing selection of a representation of a given resource,926 whenmore than one is available.925 provides mechanisms for "content negotiation" — a process of allowing selection of a representation of a given resource, when 926 more than one is available. 927 927 </p> 928 928 <p id="rfc.section.5.p.3">This specification defines two patterns of content negotiation; "server-driven", where the server selects the representation … … 1254 1254 intended to be used by an English-literate audience. In this case, the Content-Language would properly only include "en". 1255 1255 </p> 1256 <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type --it is not limited to textual documents.1256 <p id="rfc.section.6.6.p.9">Content-Language <em class="bcp14">MAY</em> be applied to any media type — it is not limited to textual documents. 1257 1257 </p> 1258 1258 <div id="rfc.iref.c.9"></div> … … 1323 1323 and Content-Encoding header fields). If a body-part has a Content-Transfer-Encoding or Content-Encoding header field, it is 1324 1324 assumed that the content of the body-part has had the encoding applied, and the body-part is included in the Content-MD5 digest 1325 as is --i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts.1325 as is — i.e., after the application. The Transfer-Encoding header field is not allowed within body-parts. 1326 1326 </p> 1327 1327 <p id="rfc.section.6.8.p.7">Conversion of all line breaks to CRLF <em class="bcp14">MUST NOT</em> be done before computing or checking the digest: the line break convention used in the text actually transmitted <em class="bcp14">MUST</em> be left unaltered when computing the digest. … … 1919 1919 <p id="rfc.section.E.5.p.2">Other changes: </p> 1920 1920 <ul> 1921 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>>: "Encoding References Normative" --rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>.1921 <li> <<a href="http://tools.ietf.org/wg/httpbis/trac/ticket/68">http://tools.ietf.org/wg/httpbis/trac/ticket/68</a>>: "Encoding References Normative" — rephrase the annotation and reference <a href="#BCP97" id="rfc.xref.BCP97.4"><cite title="Handling Normative References to Standards-Track Documents">[BCP97]</cite></a>. 1922 1922 </li> 1923 1923 </ul> -
draft-ietf-httpbis/latest/p3-payload.xml
r1099 r1101 15 15 <!ENTITY ID-MONTH "January"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY mdash "—"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 607 608 <section title="Multipart Types" anchor="multipart.types"> 608 609 <t> 609 MIME provides for a number of "multipart" types --encapsulations of610 MIME provides for a number of "multipart" types — encapsulations of 610 611 one or more representations within a single message-body. All multipart 611 612 types share a common syntax, as defined in <xref target="RFC2046" x:sec="5.1.1" x:fmt="of"/>, … … 824 825 which representation, among those available from the server, 825 826 would be best for the server to deliver. For this reason, HTTP 826 provides mechanisms for "content negotiation" --a process of827 provides mechanisms for "content negotiation" — a process of 827 828 allowing selection of a representation of a given resource, 828 829 when more than one is available. … … 1401 1402 </t> 1402 1403 <t> 1403 Content-Language &MAY; be applied to any media type --it is not1404 Content-Language &MAY; be applied to any media type — it is not 1404 1405 limited to textual documents. 1405 1406 </t> … … 1544 1545 or Content-Encoding header field, it is assumed that the content 1545 1546 of the body-part has had the encoding applied, and the body-part is 1546 included in the Content-MD5 digest as is --i.e., after the1547 included in the Content-MD5 digest as is — i.e., after the 1547 1548 application. The Transfer-Encoding header field is not allowed within 1548 1549 body-parts. … … 2887 2888 <t> 2888 2889 <eref target="http://tools.ietf.org/wg/httpbis/trac/ticket/68"/>: 2889 "Encoding References Normative" --rephrase the annotation and reference2890 "Encoding References Normative" — rephrase the annotation and reference 2890 2891 <xref target="BCP97"/>. 2891 2892 </t> -
draft-ietf-httpbis/latest/p4-conditional.html
r1099 r1101 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.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 4 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines request header fields for indicating conditional requests and the rules for constructing responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: July 5, 2011</td>428 <td class="left">Expires: July 12, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">January 1, 2011</td>485 <td class="right">January 8, 2011</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire on July 5, 2011.</p>511 <p>This Internet-Draft will expire on July 12, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p5-range.html
r1099 r1101 400 400 <meta name="dct.creator" content="Reschke, J. F."> 401 401 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest"> 402 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">402 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 403 403 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 404 404 <meta name="dct.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 5 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests."> … … 426 426 </tr> 427 427 <tr> 428 <td class="left">Expires: July 5, 2011</td>428 <td class="left">Expires: July 12, 2011</td> 429 429 <td class="right">J. Mogul</td> 430 430 </tr> … … 483 483 <tr> 484 484 <td class="left"></td> 485 <td class="right">January 1, 2011</td>485 <td class="right">January 8, 2011</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire on July 5, 2011.</p>511 <p>This Internet-Draft will expire on July 12, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r1099 r1101 402 402 <meta name="dct.creator" content="Reschke, J. F."> 403 403 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest"> 404 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">404 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 405 405 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 406 406 <meta name="dct.abstract" content="The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. This document is Part 6 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 6 defines requirements on HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: July 5, 2011</td>430 <td class="left">Expires: July 12, 2011</td> 431 431 <td class="right">J. Mogul</td> 432 432 </tr> … … 489 489 <tr> 490 490 <td class="left"></td> 491 <td class="right">January 1, 2011</td>491 <td class="right">January 8, 2011</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire on July 5, 2011.</p>517 <p>This Internet-Draft will expire on July 12, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r1099 r1101 397 397 <meta name="dct.creator" content="Reschke, J. F."> 398 398 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 399 <meta name="dct.issued" scheme="ISO8601" content="2011-01-0 1">399 <meta name="dct.issued" scheme="ISO8601" content="2011-01-08"> 400 400 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 401 401 <meta name="dct.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 7 of the seven-part specification that defines the protocol referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication."> … … 428 428 </tr> 429 429 <tr> 430 <td class="left">Expires: July 5, 2011</td>430 <td class="left">Expires: July 12, 2011</td> 431 431 <td class="right">HP</td> 432 432 </tr> … … 481 481 <tr> 482 482 <td class="left"></td> 483 <td class="right">January 1, 2011</td>483 <td class="right">January 8, 2011</td> 484 484 </tr> 485 485 </tbody> … … 507 507 in progress”. 508 508 </p> 509 <p>This Internet-Draft will expire on July 5, 2011.</p>509 <p>This Internet-Draft will expire on July 12, 2011.</p> 510 510 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 511 511 <p>Copyright © 2011 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 648 648 scheme. Note that there can be multiple challenges with the same auth-scheme but different realms. 649 649 </p> 650 <p id="rfc.section.2.p.10">A user agent that wishes to authenticate itself with an origin server --usually, but not necessarily, after receiving a 401651 (Unauthorized) --<em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy652 -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) --<em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization650 <p id="rfc.section.2.p.10">A user agent that wishes to authenticate itself with an origin server — usually, but not necessarily, after receiving a 401 651 (Unauthorized) — <em class="bcp14">MAY</em> do so by including an Authorization header field with the request. A client that wishes to authenticate itself with a proxy 652 — usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) — <em class="bcp14">MAY</em> do so by including a Proxy-Authorization header field with the request. Both the Authorization field value and the Proxy-Authorization 653 653 field value consist of credentials containing the authentication information of the client for the realm of the resource being 654 654 requested. The user agent <em class="bcp14">MUST</em> choose to use one of the challenges with the strongest auth-scheme it understands and request credentials from the user based … … 705 705 <div id="rfc.iref.h.1"></div> 706 706 <h2 id="rfc.section.4.1"><a href="#rfc.section.4.1">4.1</a> <a id="header.authorization" href="#header.authorization">Authorization</a></h2> 707 <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server --usually, but not necessarily,707 <p id="rfc.section.4.1.p.1">The "Authorization" request-header field allows a user agent to authenticate itself with a server — usually, but not necessarily, 708 708 after receiving a 401 (Unauthorized) response. Its value consists of credentials containing information of the user agent 709 709 for the realm of the resource being requested. -
draft-ietf-httpbis/latest/p7-auth.xml
r1099 r1101 15 15 <!ENTITY ID-MONTH "January"> 16 16 <!ENTITY ID-YEAR "2011"> 17 <!ENTITY mdash "—"> 17 18 <!ENTITY notation "<xref target='Part1' x:rel='#notation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 18 19 <!ENTITY notation-abnf "<xref target='Part1' x:rel='#notation.abnf' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 352 353 <t> 353 354 A user agent that wishes to authenticate itself with an origin 354 server --usually, but not necessarily, after receiving a 401355 (Unauthorized) --&MAY; do so by including an Authorization header field355 server — usually, but not necessarily, after receiving a 401 356 (Unauthorized) — &MAY; do so by including an Authorization header field 356 357 with the request. A client that wishes to authenticate itself with a 357 proxy --usually, but not necessarily, after receiving a 407 (Proxy358 Authentication Required) --&MAY; do so by including a Proxy-Authorization358 proxy — usually, but not necessarily, after receiving a 407 (Proxy 359 Authentication Required) — &MAY; do so by including a Proxy-Authorization 359 360 header field with the request. Both the Authorization 360 361 field value and the Proxy-Authorization field value consist of … … 475 476 <t> 476 477 The "Authorization" request-header field allows a user agent to authenticate 477 itself with a server --usually, but not necessarily, after receiving a 401478 itself with a server — usually, but not necessarily, after receiving a 401 478 479 (Unauthorized) response. Its value consists of credentials containing 479 480 information of the user agent for the realm of the resource being
Note: See TracChangeset
for help on using the changeset viewer.