Changeset 1628
- Timestamp:
- 28/03/12 15:57:43 (11 years ago)
- Location:
- draft-ietf-httpbis/experiment
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/experiment/p1-messaging.html
r1627 r1628 757 757 <p id="rfc.section.1.p.1">The Hypertext Transfer Protocol (HTTP) is an application-level request/response protocol that uses extensible semantics and 758 758 MIME-like message payloads for flexible interaction with network-based hypertext information systems. HTTP relies upon the 759 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 the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet 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="p 3-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).759 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 the target resource (<a href="#target-resource" title="Identifying a Target Resource">Section 5.1</a>) and relationships between resources. Messages are passed in a format similar to that used by Internet 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="p2-semantics.html#differences.between.http.and.mime" title="Differences between HTTP and MIME">Appendix A</a> of <a href="#Part2" id="rfc.xref.Part2.1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for the differences between HTTP and MIME messages). 760 760 </p> 761 761 <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 … … 910 910 or an intranet-to-Internet privacy filter. Such transformations are presumed to be desired by the client (or client organization) 911 911 that selected the proxy and are beyond the scope of this specification. However, when a proxy is not intended to transform 912 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2. 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations.912 a given message, we use the term "<dfn>non-transforming proxy</dfn>" to target requirements that preserve HTTP message semantics. See <a href="p2-semantics.html#status.203" title="203 Non-Authoritative Information">Section 4.4.4</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> and <a href="p6-cache.html#header.warning" title="Warning">Section 3.6</a> of <a href="#Part6" id="rfc.xref.Part6.1"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a> for status and warning codes related to transformations. 913 913 </p> 914 914 <p id="rfc.section.2.3.p.7"><span id="rfc.iref.g.13"></span><span id="rfc.iref.r.4"></span> <span id="rfc.iref.a.1"></span> A "<dfn>gateway</dfn>" (a.k.a., "<dfn>reverse proxy</dfn>") is a receiving agent that acts as a layer above some other server(s) and translates the received requests to the underlying … … 1078 1078 </p> 1079 1079 <p id="rfc.section.2.7.1.p.6">When an "http" URI is used within a context that calls for access to the indicated resource, a client <em class="bcp14">MAY</em> attempt access by resolving the host to an IP address, establishing a TCP connection to that address on the indicated port, 1080 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request.1080 and sending an HTTP request message (<a href="#http.message" title="Message Format">Section 3</a>) containing the URI's identifying data (<a href="#message.routing" title="Message Routing">Section 5</a>) to the server. If the server responds to that request with a non-interim HTTP response message, as described in <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, then that response is considered an authoritative answer to the client's request. 1081 1081 </p> 1082 1082 <p id="rfc.section.2.7.1.p.7">Although HTTP is independent of the transport protocol, the "http" scheme is specific to TCP-based services because the name … … 1174 1174 </div> 1175 1175 <div id="rfc.figure.u.14"></div><pre class="inline"><span id="rfc.iref.g.28"></span> <a href="#method" class="smpl">method</a> = <a href="#rule.token.separators" class="smpl">token</a> 1176 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2. 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods.1176 </pre><p id="rfc.section.3.1.1.p.5">The methods defined by this specification can be found in <a href="p2-semantics.html#methods" title="Methods">Section 2</a> of <a href="#Part2" id="rfc.xref.Part2.4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, along with information regarding the HTTP method registry and considerations for defining new methods. 1177 1177 </p> 1178 1178 <div id="rfc.iref.r.6"></div> … … 1189 1189 <p id="rfc.section.3.1.1.p.9">HTTP does not place a pre-defined limit on the length of a request-line. A server that receives a method longer than any that 1190 1190 it implements <em class="bcp14">SHOULD</em> respond with either a 405 (Not Allowed), if it is an origin server, or a 501 (Not Implemented) status code. A server <em class="bcp14">MUST</em> be prepared to receive URIs of unbounded length and respond with the 414 (URI Too Long) status code if the received request-target 1191 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2. 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).1191 would be longer than the server wishes to handle (see <a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 1192 1192 </p> 1193 1193 <p id="rfc.section.3.1.1.p.10">Various ad-hoc limitations on request-line length are found in practice. It is <em class="bcp14">RECOMMENDED</em> that all HTTP senders and recipients support, at a minimum, request-line lengths of up to 8000 octets. … … 1199 1199 <div id="rfc.figure.u.15"></div><pre class="inline"><span id="rfc.iref.g.29"></span> <a href="#status.line" class="smpl">status-line</a> = <a href="#http.version" class="smpl">HTTP-version</a> <a href="#core.rules" class="smpl">SP</a> <a href="#status-code" class="smpl">status-code</a> <a href="#core.rules" class="smpl">SP</a> <a href="#reason-phrase" class="smpl">reason-phrase</a> <a href="#core.rules" class="smpl">CRLF</a> 1200 1200 </pre><div id="status-code"> 1201 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2. 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations1201 <p id="rfc.section.3.1.2.p.3">The status-code element is a 3-digit integer result code of the attempt to understand and satisfy the request. See <a href="p2-semantics.html#status.code.and.reason.phrase" title="Status Code and Reason Phrase">Section 4</a> of <a href="#Part2" id="rfc.xref.Part2.6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> for further information, such as the list of status codes defined by this specification, the IANA registry, and considerations 1202 1202 for new status codes. 1203 1203 </p> … … 1223 1223 ; see <a href="#field.parsing" title="Field Parsing">Section 3.2.2</a> 1224 1224 </pre><p id="rfc.section.3.2.p.3">The field-name token labels the corresponding field-value as having the semantics defined by that header field. For example, 1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 11.2</a> of <a href="#Part2" id="rfc.xref.Part2. 6"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears.1225 the Date header field is defined in <a href="p2-semantics.html#header.date" title="Date">Section 11.2</a> of <a href="#Part2" id="rfc.xref.Part2.7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> as containing the origination timestamp for the message in which it appears. 1226 1226 </p> 1227 1227 <p id="rfc.section.3.2.p.4">HTTP header fields are fully extensible: there is no limit on the introduction of new field names, each presumably defining … … 1231 1231 them. 1232 1232 </p> 1233 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2. 7"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients.1233 <p id="rfc.section.3.2.p.5">New HTTP header fields <em class="bcp14">SHOULD</em> be registered with IANA according to the procedures in <a href="p2-semantics.html#considerations.for.creating.header.fields" title="Considerations for Creating Header Fields">Section 3.1</a> of <a href="#Part2" id="rfc.xref.Part2.8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>. Unrecognized header fields <em class="bcp14">MUST</em> be forwarded by a proxy unless the field-name is listed in the Connection header field (<a href="#header.connection" id="rfc.xref.header.connection.3" title="Connection">Section 6.1</a>) or the proxy is specifically configured to block or otherwise transform such fields. Unrecognized header fields <em class="bcp14">SHOULD</em> be ignored by other recipients. 1234 1234 </p> 1235 1235 <p id="rfc.section.3.2.p.6">The order in which header fields with differing field names are received is not significant. However, it is "good practice" … … 1418 1418 <p id="rfc.section.3.3.1.p.6">If more than one Transfer-Encoding header field is present in a message, the multiple field-values <em class="bcp14">MUST</em> be combined into one field-value, according to the algorithm defined in <a href="#header.fields" title="Header Fields">Section 3.2</a>, before determining the message body length. 1419 1419 </p> 1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p 3-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.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification.1420 <p id="rfc.section.3.3.1.p.7">Unlike Content-Encoding (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), Transfer-Encoding is a property of the message, not of the payload, and thus <em class="bcp14">MAY</em> be added or removed by any implementation along the request/response chain. Additional information about the encoding parameters <em class="bcp14">MAY</em> be provided by other header fields not defined by this specification. 1421 1421 </p> 1422 1422 <p id="rfc.section.3.3.1.p.8">Transfer-Encoding <em class="bcp14">MAY</em> be sent in a response to a HEAD request or in a 304 response to a GET request, neither of which includes a message body, to … … 1725 1725 </p> 1726 1726 <h3 id="rfc.section.4.3.1"><a href="#rfc.section.4.3.1">4.3.1</a> <a id="quality.values" href="#quality.values">Quality Values</a></h3> 1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p 3-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.3"><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 weight1727 <p id="rfc.section.4.3.1.p.1">Both transfer codings (TE request header field, <a href="#header.te" id="rfc.xref.header.te.3" title="TE">Section 4.3</a>) and content negotiation (<a href="p2-semantics.html#content.negotiation" title="Content Negotiation">Section 10</a> of <a href="#Part2" id="rfc.xref.Part2.10"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) use short "floating point" numbers to indicate the relative importance ("weight") of various negotiable parameters. A weight 1728 1728 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 1729 1729 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. … … 1767 1767 </p> 1768 1768 <p id="rfc.section.5.1.p.2">HTTP communication is initiated by a user agent for some purpose. The purpose is a combination of request semantics, which 1769 are defined in <a href="#Part2" id="rfc.xref.Part2. 8"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order1769 are defined in <a href="#Part2" id="rfc.xref.Part2.11"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>, and a target resource upon which to apply those semantics. A URI reference (<a href="#uri" title="Uniform Resource Identifiers">Section 2.7</a>) is typically used as an identifier for the "target resource", which a user agent would resolve to its absolute form in order 1770 1770 to obtain the "target URI". The target URI excludes the reference's fragment identifier component, if any, since fragment 1771 1771 identifiers are reserved for client-side processing (<a href="#RFC3986" id="rfc.xref.RFC3986.18"><cite title="Uniform Resource Identifier (URI): Generic Syntax">[RFC3986]</cite></a>, <a href="http://tools.ietf.org/html/rfc3986#section-3.5">Section 3.5</a>). … … 1826 1826 </p> 1827 1827 <div id="authority-form"> 1828 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2. 9"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example,1828 <p id="rfc.section.5.3.p.13"><span id="rfc.iref.a.3"></span> The authority-form of request-target is only used for CONNECT requests (<a href="p2-semantics.html#CONNECT" title="CONNECT">Section 2.3.8</a> of <a href="#Part2" id="rfc.xref.Part2.12"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When making a CONNECT request to establish a tunnel through one or more proxies, a client <em class="bcp14">MUST</em> send only the target URI's authority component (excluding any userinfo) as the request-target. For example, 1829 1829 </p> 1830 1830 </div> 1831 1831 <div id="rfc.figure.u.49"></div><pre class="text2">CONNECT www.example.com:80 HTTP/1.1 1832 1832 </pre><div id="asterisk-form"> 1833 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 0"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server,1833 <p id="rfc.section.5.3.p.15"><span id="rfc.iref.a.4"></span> The asterisk-form of request-target is only used for a server-wide OPTIONS request (<a href="p2-semantics.html#OPTIONS" title="OPTIONS">Section 2.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.13"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). When a client wishes to request OPTIONS for the server as a whole, as opposed to a specific named resource of that server, 1834 1834 the client <em class="bcp14">MUST</em> send only "*" (%x2A) as the request-target. For example, 1835 1835 </p> … … 1986 1986 </p> 1987 1987 </div> 1988 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part 3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>).1988 <p id="rfc.section.5.6.2.p.8">A non-transforming proxy <em class="bcp14">MUST</em> preserve the message payload (<a href="#Part2" id="rfc.xref.Part2.14"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>), though it <em class="bcp14">MAY</em> change the message body through application or removal of a transfer-coding (<a href="#transfer.codings" title="Transfer Codings">Section 4</a>). 1989 1989 </p> 1990 1990 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="associating.response.to.request" href="#associating.response.to.request">Associating a Response to a Request</a></h2> … … 1992 1992 messages. Hence, it relies on the order of response arrival to correspond exactly to the order in which requests are made 1993 1993 on the same connection. More than one response message per request only occurs when one or more informational responses (1xx, 1994 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 1"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request.1994 see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.15"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) precede a final response to the same request. 1995 1995 </p> 1996 1996 <p id="rfc.section.5.7.p.2">A client that uses persistent connections and sends more than one request per connection <em class="bcp14">MUST</em> maintain a list of outstanding requests in the order sent on that connection and <em class="bcp14">MUST</em> associate each received response message to the highest ordered request that has not yet received a final (non-1xx) response. … … 2137 2137 <p id="rfc.section.6.3.2.2.p.2">Clients which assume persistent connections and pipeline immediately after connection establishment <em class="bcp14">SHOULD</em> be prepared to retry their connection if the first pipelined attempt fails. If a client does such a retry, it <em class="bcp14">MUST NOT</em> pipeline before it knows the connection is persistent. Clients <em class="bcp14">MUST</em> also be prepared to resend their requests if the server closes the connection before sending all of the corresponding responses. 2138 2138 </p> 2139 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to2139 <p id="rfc.section.6.3.2.2.p.3">Clients <em class="bcp14">SHOULD NOT</em> pipeline requests using non-idempotent request methods or non-idempotent sequences of request methods (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Otherwise, a premature termination of the transport connection could lead to indeterminate results. A client wishing to 2140 2140 send a non-idempotent request <em class="bcp14">SHOULD</em> wait to send that request until it has received the response status line for the previous request. 2141 2141 </p> … … 2167 2167 <h3 id="rfc.section.6.3.4"><a href="#rfc.section.6.3.4">6.3.4</a> <a id="persistent.retrying.requests" href="#persistent.retrying.requests">Retrying Requests</a></h3> 2168 2168 <p id="rfc.section.6.3.4.p.1">Senders can close the transport connection at any time. Therefore, clients, servers, and proxies <em class="bcp14">MUST</em> be able to recover from asynchronous close events. Client software <em class="bcp14">MAY</em> reopen the transport connection and retransmit the aborted sequence of requests without user interaction so long as the request 2169 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.1 3"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding2169 sequence is idempotent (see <a href="p2-semantics.html#idempotent.methods" title="Idempotent Methods">Section 2.1.2</a> of <a href="#Part2" id="rfc.xref.Part2.17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). Non-idempotent request methods or sequences <em class="bcp14">MUST NOT</em> be automatically retried, although user agents <em class="bcp14">MAY</em> offer a human operator the choice of retrying the request(s). Confirmation by user-agent software with semantic understanding 2170 2170 of the application <em class="bcp14">MAY</em> substitute for user confirmation. The automatic retry <em class="bcp14">SHOULD NOT</em> be repeated if the second sequence of requests fails. 2171 2171 </p> … … 2180 2180 </p> 2181 2181 <h3 id="rfc.section.6.4.3"><a href="#rfc.section.6.4.3">6.4.3</a> <a id="use.of.the.100.status" href="#use.of.the.100.status">Use of the 100 (Continue) Status</a></h3> 2182 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.1 4"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing2182 <p id="rfc.section.6.4.3.p.1">The purpose of the 100 (Continue) status code (see <a href="p2-semantics.html#status.100" title="100 Continue">Section 4.3.1</a> of <a href="#Part2" id="rfc.xref.Part2.18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) is to allow a client that is sending a request message with a request body to determine if the origin server is willing 2183 2183 to accept the request (based on the request header fields) before the client sends the request body. In some cases, it might 2184 2184 either be inappropriate or highly inefficient for the client to send the body if the server will reject the message without … … 2187 2187 <p id="rfc.section.6.4.3.p.2">Requirements for HTTP/1.1 clients: </p> 2188 2188 <ul> 2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 11.3</a> of <a href="#Part2" id="rfc.xref.Part2.1 5"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation.2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 11.3</a> of <a href="#Part2" id="rfc.xref.Part2. 16"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body.2189 <li>If a client will wait for a 100 (Continue) response before sending the request body, it <em class="bcp14">MUST</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 11.3</a> of <a href="#Part2" id="rfc.xref.Part2.19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation. 2190 </li> 2191 <li>A client <em class="bcp14">MUST NOT</em> send an Expect header field (<a href="p2-semantics.html#header.expect" title="Expect">Section 11.3</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) with the "100-continue" expectation if it does not intend to send a request body. 2192 2192 </li> 2193 2193 </ul> … … 2233 2233 <li>A proxy <em class="bcp14">MUST NOT</em> forward a 100 (Continue) response if the request message was received from an HTTP/1.0 (or earlier) client and did not include 2234 2234 an Expect header field with the "100-continue" expectation. This requirement overrides the general rule for forwarding of 2235 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2. 17"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2235 1xx responses (see <a href="p2-semantics.html#status.1xx" title="Informational 1xx">Section 4.3</a> of <a href="#Part2" id="rfc.xref.Part2.21"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2236 2236 </li> 2237 2237 </ul> … … 2270 2270 </p> 2271 2271 <p id="rfc.section.6.5.p.8">The Upgrade header field cannot be used to indicate a switch to a protocol on a different connection. For that purpose, it 2272 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2. 18"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2272 is more appropriate to use a 3xx redirection response (<a href="p2-semantics.html#status.3xx" title="Redirection 3xx">Section 4.5</a> of <a href="#Part2" id="rfc.xref.Part2.22"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2273 2273 </p> 2274 2274 <p id="rfc.section.6.5.p.9">Servers <em class="bcp14">MUST</em> include the "Upgrade" header field in 101 (Switching Protocols) responses to indicate which protocol(s) are being switched … … 2534 2534 <li>Pointer to specification text</li> 2535 2535 </ul> 2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p 3-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.5"><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 4.2</a>.2536 <p id="rfc.section.7.4.p.3">Names of transfer codings <em class="bcp14">MUST NOT</em> overlap with names of content codings (<a href="p2-semantics.html#content.codings" title="Content Codings">Section 7.2</a> of <a href="#Part2" id="rfc.xref.Part2.23"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</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 4.2</a>. 2537 2537 </p> 2538 2538 <p id="rfc.section.7.4.p.4">Values to be added to this name space require IETF Review (see <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. … … 2694 2694 that most implementations will choose substantially higher limits. 2695 2695 </p> 2696 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2. 19"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.20"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>).2696 <p id="rfc.section.8.6.p.3">This specification also provides a way for servers to reject messages that have request-targets that are too long (<a href="p2-semantics.html#status.414" title="414 URI Too Long">Section 4.6.12</a> of <a href="#Part2" id="rfc.xref.Part2.24"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>) or request entities that are too large (<a href="p2-semantics.html#status.4xx" title="Client Error 4xx">Section 4.6</a> of <a href="#Part2" id="rfc.xref.Part2.25"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a>). 2697 2697 </p> 2698 2698 <p id="rfc.section.8.6.p.4">Other fields (including but not limited to request methods, response status phrases, header field-names, and body chunks) <em class="bcp14">SHOULD</em> be limited by implementations carefully, so as to not impede interoperability. … … 2738 2738 <h2 id="rfc.references.1"><a href="#rfc.section.10.1" id="rfc.section.10.1">10.1</a> Normative References 2739 2739 </h2> 2740 <table> 2740 <table> 2741 2741 <tr> 2742 2742 <td class="reference"><b id="ISO-8859-1">[ISO-8859-1]</b></td> … … 2746 2746 <td class="reference"><b id="Part2">[Part2]</b></td> 2747 2747 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p2-semantics-latest">HTTP/1.1, part 2: Message Semantics</a>”, Internet-Draft draft-ietf-httpbis-p2-semantics-latest (work in progress), March 2012. 2748 </td>2749 </tr>2750 <tr>2751 <td class="reference"><b id="Part3">[Part3]</b></td>2752 <td class="top"><a href="mailto:fielding@gbiv.com" title="Adobe Systems Incorporated">Fielding, R., Ed.</a>, <a href="mailto:ylafon@w3.org" title="World Wide Web Consortium">Lafon, Y., Ed.</a>, and <a href="mailto:julian.reschke@greenbytes.de" title="greenbytes GmbH">J. Reschke, Ed.</a>, “<a href="http://tools.ietf.org/html/draft-ietf-httpbis-p3-payload-latest">HTTP/1.1, part 3: Message Payload and Content Negotiation</a>”, Internet-Draft draft-ietf-httpbis-p3-payload-latest (work in progress), March 2012.2753 2748 </td> 2754 2749 </tr> … … 3750 3745 <li><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul> 3751 3746 <li><em>Pad1995</em> <a href="#rfc.xref.Pad1995.1">6.3.1</a>, <a href="#Pad1995"><b>10.2</b></a></li> 3752 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">2.3</a>, <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.3">3.1.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a>, <a href="#rfc.xref.Part2.6">3.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">5.1</a>, <a href="#rfc.xref.Part2.9">5.3</a>, <a href="#rfc.xref.Part2.10">5.3</a>, <a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a>, <a href="#rfc.xref.Part2.14">6.4.3</a>, <a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a>, <a href="#rfc.xref.Part2.17">6.4.3</a>, <a href="#rfc.xref.Part2.18">6.5</a>, <a href="#rfc.xref.Part2.19">8.6</a>, <a href="#rfc.xref.Part2.20">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3753 <li><em>Section 2</em> <a href="#rfc.xref.Part2.3">3.1.1</a></li> 3754 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.12">6.3.2.2</a>, <a href="#rfc.xref.Part2.13">6.3.4</a></li> 3755 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.10">5.3</a></li> 3756 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.9">5.3</a></li> 3757 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3758 <li><em>Section 4</em> <a href="#rfc.xref.Part2.2">2.7.1</a>, <a href="#rfc.xref.Part2.5">3.1.2</a></li> 3759 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.11">5.7</a>, <a href="#rfc.xref.Part2.17">6.4.3</a></li> 3760 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.14">6.4.3</a></li> 3761 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.1">2.3</a></li> 3762 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.18">6.5</a></li> 3763 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.20">8.6</a></li> 3764 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.19">8.6</a></li> 3765 <li><em>Section 11.2</em> <a href="#rfc.xref.Part2.6">3.2</a></li> 3766 <li><em>Section 11.3</em> <a href="#rfc.xref.Part2.15">6.4.3</a>, <a href="#rfc.xref.Part2.16">6.4.3</a></li> 3767 </ul> 3768 </li> 3769 <li><em>Part3</em> <a href="#rfc.xref.Part3.1">1</a>, <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.3">4.3.1</a>, <a href="#rfc.xref.Part3.4">5.6.2</a>, <a href="#rfc.xref.Part3.5">7.4</a>, <a href="#Part3"><b>10.1</b></a><ul> 3770 <li><em>Appendix </em> <a href="#rfc.xref.Part3.1">1</a></li> 3771 <li><em>Appendix </em> <a href="#rfc.xref.Part3.2">3.3.1</a>, <a href="#rfc.xref.Part3.5">7.4</a></li> 3772 <li><em>Appendix </em> <a href="#rfc.xref.Part3.3">4.3.1</a></li> 3747 <li><em>Part2</em> <a href="#rfc.xref.Part2.1">1</a>, <a href="#rfc.xref.Part2.2">2.3</a>, <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.4">3.1.1</a>, <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a>, <a href="#rfc.xref.Part2.7">3.2</a>, <a href="#rfc.xref.Part2.8">3.2</a>, <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.10">4.3.1</a>, <a href="#rfc.xref.Part2.11">5.1</a>, <a href="#rfc.xref.Part2.12">5.3</a>, <a href="#rfc.xref.Part2.13">5.3</a>, <a href="#rfc.xref.Part2.14">5.6.2</a>, <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a>, <a href="#rfc.xref.Part2.18">6.4.3</a>, <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a>, <a href="#rfc.xref.Part2.21">6.4.3</a>, <a href="#rfc.xref.Part2.22">6.5</a>, <a href="#rfc.xref.Part2.23">7.4</a>, <a href="#rfc.xref.Part2.24">8.6</a>, <a href="#rfc.xref.Part2.25">8.6</a>, <a href="#Part2"><b>10.1</b></a><ul> 3748 <li><em>Section 2</em> <a href="#rfc.xref.Part2.4">3.1.1</a></li> 3749 <li><em>Section 2.1.2</em> <a href="#rfc.xref.Part2.16">6.3.2.2</a>, <a href="#rfc.xref.Part2.17">6.3.4</a></li> 3750 <li><em>Section 2.3.1</em> <a href="#rfc.xref.Part2.13">5.3</a></li> 3751 <li><em>Section 2.3.8</em> <a href="#rfc.xref.Part2.12">5.3</a></li> 3752 <li><em>Section 3.1</em> <a href="#rfc.xref.Part2.8">3.2</a></li> 3753 <li><em>Section 4</em> <a href="#rfc.xref.Part2.3">2.7.1</a>, <a href="#rfc.xref.Part2.6">3.1.2</a></li> 3754 <li><em>Section 4.3</em> <a href="#rfc.xref.Part2.15">5.7</a>, <a href="#rfc.xref.Part2.21">6.4.3</a></li> 3755 <li><em>Section 4.3.1</em> <a href="#rfc.xref.Part2.18">6.4.3</a></li> 3756 <li><em>Section 4.4.4</em> <a href="#rfc.xref.Part2.2">2.3</a></li> 3757 <li><em>Section 4.5</em> <a href="#rfc.xref.Part2.22">6.5</a></li> 3758 <li><em>Section 4.6</em> <a href="#rfc.xref.Part2.25">8.6</a></li> 3759 <li><em>Section 4.6.12</em> <a href="#rfc.xref.Part2.5">3.1.1</a>, <a href="#rfc.xref.Part2.24">8.6</a></li> 3760 <li><em>Section 7.2</em> <a href="#rfc.xref.Part2.9">3.3.1</a>, <a href="#rfc.xref.Part2.23">7.4</a></li> 3761 <li><em>Section 10</em> <a href="#rfc.xref.Part2.10">4.3.1</a></li> 3762 <li><em>Section 11.2</em> <a href="#rfc.xref.Part2.7">3.2</a></li> 3763 <li><em>Section 11.3</em> <a href="#rfc.xref.Part2.19">6.4.3</a>, <a href="#rfc.xref.Part2.20">6.4.3</a></li> 3764 <li><em>Appendix A</em> <a href="#rfc.xref.Part2.1">1</a></li> 3773 3765 </ul> 3774 3766 </li> -
draft-ietf-httpbis/experiment/p1-messaging.xml
r1625 r1628 18 18 <!ENTITY caching-overview "<xref target='Part6' x:rel='#caching.overview' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 19 19 <!ENTITY cache-incomplete "<xref target='Part6' x:rel='#response.cacheability' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 20 <!ENTITY payload "<xref target='Part 3' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">21 <!ENTITY media-types "<xref target='Part 3' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">22 <!ENTITY content-codings "<xref target='Part 3' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">20 <!ENTITY payload "<xref target='Part2' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 21 <!ENTITY media-types "<xref target='Part2' x:rel='#media.types' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 22 <!ENTITY content-codings "<xref target='Part2' x:rel='#content.codings' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 23 23 <!ENTITY CONNECT "<xref target='Part2' x:rel='#CONNECT' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 24 <!ENTITY content.negotiation "<xref target='Part 3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">25 <!ENTITY diff-mime "<xref target='Part 3' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">26 <!ENTITY representation "<xref target='Part 3' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">24 <!ENTITY content.negotiation "<xref target='Part2' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 25 <!ENTITY diff-mime "<xref target='Part2' x:rel='#differences.between.http.and.mime' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 26 <!ENTITY representation "<xref target='Part2' x:rel='#representation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 27 27 <!ENTITY header-cache-control "<xref target='Part6' x:rel='#header.cache-control' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 28 28 <!ENTITY header-date "<xref target='Part2' x:rel='#header.date' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 29 29 <!ENTITY header-expect "<xref target='Part2' x:rel='#header.expect' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 30 <!ENTITY header-mime-version "<xref target='Part 3' x:rel='#mime-version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">30 <!ENTITY header-mime-version "<xref target='Part2' x:rel='#mime-version' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 31 31 <!ENTITY header-pragma "<xref target='Part6' x:rel='#header.pragma' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> 32 32 <!ENTITY header-warning "<xref target='Part6' x:rel='#header.warning' xmlns:x='http://purl.org/net/xml2rfc/ext'/>"> … … 4094 4094 </reference> 4095 4095 4096 <reference anchor="Part3">4097 <front>4098 <title abbrev="HTTP/1.1">HTTP/1.1, part 3: Message Payload and Content Negotiation</title>4099 <author initials="R." surname="Fielding" fullname="Roy T. Fielding" role="editor">4100 <organization abbrev="Adobe">Adobe Systems Incorporated</organization>4101 <address><email>fielding@gbiv.com</email></address>4102 </author>4103 <author initials="Y." surname="Lafon" fullname="Yves Lafon" role="editor">4104 <organization abbrev="W3C">World Wide Web Consortium</organization>4105 <address><email>ylafon@w3.org</email></address>4106 </author>4107 <author initials="J. F." surname="Reschke" fullname="Julian F. Reschke" role="editor">4108 <organization abbrev="greenbytes">greenbytes GmbH</organization>4109 <address><email>julian.reschke@greenbytes.de</email></address>4110 </author>4111 <date month="&ID-MONTH;" year="&ID-YEAR;"/>4112 </front>4113 <seriesInfo name="Internet-Draft" value="draft-ietf-httpbis-p3-payload-&ID-VERSION;"/>4114 <x:source href="p3-payload.xml" basename="p3-payload"/>4115 </reference>4116 4117 4096 <reference anchor="Part6"> 4118 4097 <front>
Note: See TracChangeset
for help on using the changeset viewer.