Changeset 857 for draft-ietf-httpbis/latest
- Timestamp:
- 19/07/10 11:52:42 (12 years ago)
- Location:
- draft-ietf-httpbis/latest
- Files:
-
- 7 edited
Legend:
- Unmodified
- Added
- Removed
-
draft-ietf-httpbis/latest/p1-messaging.html
r854 r857 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="2010-07-1 7">406 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 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: January 18, 2011</td>437 <td class="left">Expires: January 20, 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">July 1 7, 2010</td>490 <td class="right">July 19, 2010</td> 491 491 </tr> 492 492 </tbody> … … 516 516 in progress”. 517 517 </p> 518 <p>This Internet-Draft will expire in January 18, 2011.</p>518 <p>This Internet-Draft will expire in January 20, 2011.</p> 519 519 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 520 520 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p2-semantics.html
r853 r857 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="2010-07-1 6">405 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 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: January 17, 2011</td>436 <td class="left">Expires: January 20, 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">July 1 6, 2010</td>489 <td class="right">July 19, 2010</td> 490 490 </tr> 491 491 </tbody> … … 514 514 in progress”. 515 515 </p> 516 <p>This Internet-Draft will expire in January 17, 2011.</p>516 <p>This Internet-Draft will expire in January 20, 2011.</p> 517 517 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 518 518 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 1164 1164 <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a> <a id="status.201" href="#status.201">201 Created</a></h3> 1165 1165 <p id="rfc.section.8.2.2.p.1">The request has been fulfilled and has resulted in a new resource being created. The newly created resource can be referenced 1166 by the URI(s) returned in the entityof the response, with the most specific URI for the resource given by a Location header1167 field. The response <em class="bcp14">SHOULD</em> include a n entitycontaining a list of resource characteristics and location(s) from which the user or user agent can choose1168 the one most appropriate. The entityformat is specified by the media type given in the Content-Type header field. The origin1166 by the URI(s) returned in the payload of the response, with the most specific URI for the resource given by a Location header 1167 field. The response <em class="bcp14">SHOULD</em> include a payload containing a list of resource characteristics and location(s) from which the user or user agent can choose 1168 the one most appropriate. The payload format is specified by the media type given in the Content-Type header field. The origin 1169 1169 server <em class="bcp14">MUST</em> create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server <em class="bcp14">SHOULD</em> respond with 202 (Accepted) response instead. 1170 1170 </p> 1171 <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the re quested variant just created,1172 see <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> of <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>.1171 <p id="rfc.section.8.2.2.p.2">A 201 response <em class="bcp14">MAY</em> contain an ETag response header field indicating the current value of the entity tag for the representation of the resource 1172 just created (see <a href="p4-conditional.html#header.etag" title="ETag">Section 6.1</a> of <a href="#Part4" id="rfc.xref.Part4.14"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>). 1173 1173 </p> 1174 1174 <div id="rfc.iref.29"></div> … … 1195 1195 <div id="rfc.iref.s.8"></div> 1196 1196 <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a> <a id="status.204" href="#status.204">204 No Content</a></h3> 1197 <p id="rfc.section.8.2.5.p.1">The server has fulfilled the request but does not need to return an entity-body, and might want to return updated metainformation. 1198 The response <em class="bcp14">MAY</em> include new or updated metainformation in the form of entity-headers, which if present <em class="bcp14">SHOULD</em> be associated with the requested variant. 1197 <p id="rfc.section.8.2.5.p.1">The server has successfully fulfilled the request, but there is no additional content to return in the response payload body. 1198 The resource metadata and representation metadata in the response message's header fields refer to the requested resource 1199 and its current representation, respectively, after the requested action. For example, if a 204 status is received in response 1200 to a PUT and the response contains an Etag header field, then the value of that field is the current entity-tag for the representation 1201 that was successfully PUT to the requested resource. 1199 1202 </p> 1200 1203 <p id="rfc.section.8.2.5.p.2">If the client is a user agent, it <em class="bcp14">SHOULD NOT</em> change its document view from that which caused the request to be sent. This response is primarily intended to allow input 1201 for actions to take place without causing a change to the user agent's active document view, although any new or updated meta information<em class="bcp14">SHOULD</em> be applied to the document currently in the user agent's active view.1204 for actions to take place without causing a change to the user agent's active document view, although any new or updated metadata <em class="bcp14">SHOULD</em> be applied to the document currently in the user agent's active view. 1202 1205 </p> 1203 1206 <p id="rfc.section.8.2.5.p.3">The 204 response <em class="bcp14">MUST NOT</em> include a message-body, and thus is always terminated by the first empty line after the header fields. -
draft-ietf-httpbis/latest/p3-payload.html
r854 r857 401 401 <meta name="dct.creator" content="Reschke, J. F."> 402 402 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest"> 403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 7">403 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 404 404 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 405 405 <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."> … … 427 427 </tr> 428 428 <tr> 429 <td class="left">Expires: January 18, 2011</td>429 <td class="left">Expires: January 20, 2011</td> 430 430 <td class="right">J. Mogul</td> 431 431 </tr> … … 484 484 <tr> 485 485 <td class="left"></td> 486 <td class="right">July 1 7, 2010</td>486 <td class="right">July 19, 2010</td> 487 487 </tr> 488 488 </tbody> … … 510 510 in progress”. 511 511 </p> 512 <p>This Internet-Draft will expire in January 18, 2011.</p>512 <p>This Internet-Draft will expire in January 20, 2011.</p> 513 513 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 514 514 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> … … 650 650 </p> 651 651 <ul class="empty"> 652 <li>The mechanism for selecting the appropriate representation when servicing a request. The representation of entities in any653 response canbe negotiated (including error responses).654 </li> 655 </ul> 656 <p id="rfc.section.1.1.p.3"> <span id="rfc.iref. e.1"></span> <dfn>entity</dfn>652 <li>The mechanism for selecting the appropriate representation when servicing a request. The representation in any response can 653 be negotiated (including error responses). 654 </li> 655 </ul> 656 <p id="rfc.section.1.1.p.3"> <span id="rfc.iref.p.1"></span> <dfn>payload</dfn> 657 657 </p> 658 658 <ul class="empty"> 659 <li>The information transferred as the payload of a request or response. An entity consists of metadata in the form of entity-header 660 fields and content in the form of an entity-body. 659 <li>The information transferred within a given message is called the payload, consisting of optional payload metadata and an optional 660 payload body. The payload in HTTP is always a partial or complete representation of some resource, though which resource is 661 represented is dependent on the type of message (request or response), the request method, and the response status code. 661 662 </li> 662 663 </ul> … … 664 665 </p> 665 666 <ul class="empty"> 666 <li>An entity included with a response that is subject to content negotiation. There may exist multiple representations associated 667 with a particular response status. 668 </li> 669 </ul> 670 <p id="rfc.section.1.1.p.5"> <span id="rfc.iref.v.1"></span> <dfn>variant</dfn> 671 </p> 672 <ul class="empty"> 673 <li>A resource may have one, or more than one, representation(s) associated with it at any given instant. Each of these representations 674 is termed a "variant". Use of the term "variant" does not necessarily imply that the resource is subject to content negotiation. 667 <li>A representation is information in a format that can be readily communicated from one party to another. For our purposes, 668 a representation is binary data and its associated metadata. A representation of a resource is information that reflects the 669 state of that resource, as observed at some point in the past or to be desired at some point in the future. 675 670 </li> 676 671 </ul> … … 1267 1262 <div id="rfc.iref.h.7"></div> 1268 1263 <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a> <a id="header.content-location" href="#header.content-location">Content-Location</a></h2> 1269 <p id="rfc.section.5.7.p.1">The "Content-Location" entity-header field is used to supply a URI for the entity in the message when it is accessible from 1270 a location separate from the requested resource's URI. 1271 </p> 1272 <p id="rfc.section.5.7.p.2">A server <em class="bcp14">SHOULD</em> provide a Content-Location for the variant corresponding to the response entity, especially in the case where a resource has 1273 multiple entities associated with it, and those entities actually have separate locations by which they might be individually 1274 accessed, the server <em class="bcp14">SHOULD</em> provide a Content-Location for the particular variant which is returned. 1264 <p id="rfc.section.5.7.p.1">The "Content-Location" header field supplies a URI that can be used as a specific identifier for the representation in this 1265 message. In other words, if one were to perform a GET on this URI at the time of this message's generation, then a 200 response 1266 would contain the same representation that is enclosed as payload in this message. 1275 1267 </p> 1276 1268 <div id="rfc.figure.u.31"></div><pre class="inline"><span id="rfc.iref.g.31"></span><span id="rfc.iref.g.32"></span> <a href="#header.content-location" class="smpl">Content-Location</a> = "Content-Location" ":" <a href="#core.rules" class="smpl">OWS</a> … … 1278 1270 <a href="#header.content-location" class="smpl">Content-Location-v</a> = 1279 1271 <a href="#abnf.dependencies" class="smpl">absolute-URI</a> / <a href="#abnf.dependencies" class="smpl">partial-URI</a> 1280 </pre><p id="rfc.section.5.7.p.4">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>); it is only a statement of the location of the resource corresponding to this particular entity at the time of the request. 1281 Future requests <em class="bcp14">MAY</em> may be addressed to the Content-Location URI if the desire is to identify the source of that particular entity. 1282 </p> 1283 <p id="rfc.section.5.7.p.5"> <a href="p2-semantics.html#identifying.response.associated.with.representation" title="Identifying the Resource Associated with a Representation">Section 6.1</a> of <a href="#Part2" id="rfc.xref.Part2.2"><cite title="HTTP/1.1, part 2: Message Semantics">[Part2]</cite></a> describes how clients may process the Content-Location header field. 1284 </p> 1285 <p id="rfc.section.5.7.p.6">A cache cannot assume that an entity with a Content-Location different from the URI used to retrieve it can be used to respond 1286 to later requests on that Content-Location URI. However, the Content-Location can be used to differentiate between multiple 1287 entities retrieved from a single requested resource, as described in <a href="p6-cache.html#caching.negotiated.responses" title="Caching Negotiated Responses">Section 2.7</a> of <a href="#Part6" id="rfc.xref.Part6.4"><cite title="HTTP/1.1, part 6: Caching">[Part6]</cite></a>. 1288 </p> 1289 <p id="rfc.section.5.7.p.7">If the Content-Location is a relative URI, the relative URI is interpreted relative to the Effective Request URI.</p> 1290 <p id="rfc.section.5.7.p.8">The meaning of the Content-Location header in requests is undefined; servers are free to ignore it in those cases.</p> 1272 </pre><p id="rfc.section.5.7.p.3">The Content-Location value is not a replacement for the Effective Request URI (<a href="p1-messaging.html#effective.request.uri" title="Effective Request URI">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.22"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>). It is representation metadata. It has the same syntax and semantics as the header field of the same name defined for MIME 1273 body parts in <a href="http://tools.ietf.org/html/rfc2557#section-4">Section 4</a> of <a href="#RFC2557" id="rfc.xref.RFC2557.1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. However, its appearance in an HTTP message has some special implications for HTTP recipients. 1274 </p> 1275 <p id="rfc.section.5.7.p.4">If Content-Location is included in a response message and its value is the same as the Effective Request URI, then the response 1276 payload <em class="bcp14">SHOULD</em> be considered the current representation of that resource. For a GET or HEAD request, this is the same as the default semantics 1277 when no Content-Location is provided by the server. For a state-changing method like PUT or POST, it implies that the server's 1278 response contains the new representation of that resource, thereby distinguishing it from representations that might only 1279 report about the action (e.g., "It worked!"). This allows authoring applications to update their local copies without the 1280 need for a subsequent GET request. 1281 </p> 1282 <p id="rfc.section.5.7.p.5">If Content-Location is included in a response message and its value differs from the Effective Request URI, then the origin 1283 server is informing recipients that this representation has its own, presumably more specific, identifier. For a GET or HEAD 1284 request, this is an indication that the Effective Request URI identifies a resource that is subject to content negotiation 1285 and the representation selected for this response can also be found at the identified URI. For other methods, such a Content-Location 1286 indicates that this representation contains a report on the action's status and the same report is available (for future access 1287 with GET) at the given URI. For example, a purchase transaction made via the POST method may include a receipt document as 1288 the payload of the 200 response; the Content-Location value provides an identifier for retrieving a copy of that same receipt 1289 in the future. 1290 </p> 1291 <p id="rfc.section.5.7.p.6">If Content-Location is included in a request message, then it <em class="bcp14">MAY</em> be interpreted by the origin server as an indication of where the user agent originally obtained the content of the enclosed 1292 representation (prior to any subsequent modification of the content by that user agent). In other words, the user agent is 1293 providing the same representation metadata that it received with the original representation. However, such interpretation <em class="bcp14">MUST NOT</em> be used to alter the semantics of the method requested by the client. For example, if a client makes a PUT request on a negotiated 1294 resource and the origin server accepts that PUT (without redirection), then the new set of values for that resource is expected 1295 to be consistent with the one representation supplied in that PUT; the Content-Location cannot be used as a form of reverse 1296 content selection that identifies only one of the negotiated representations to be updated. If the user agent had wanted the 1297 latter semantics, it would have applied the PUT directly to the Content-Location URI. 1298 </p> 1299 <p id="rfc.section.5.7.p.7">A Content-Location field received in a request message is transitory information that <em class="bcp14">SHOULD NOT</em> be saved with other representation metadata for use in later responses. The Content-Location's value might be saved for use 1300 in other contexts, such as within source links or other metadata. 1301 </p> 1302 <p id="rfc.section.5.7.p.8">A cache cannot assume that a representation with a Content-Location different from the URI used to retrieve it can be used 1303 to respond to later requests on that Content-Location URI. 1304 </p> 1305 <p id="rfc.section.5.7.p.9">If the Content-Location value is a partial URI, it is interpreted relative to the Effective Request URI.</p> 1291 1306 <div id="rfc.iref.c.10"></div> 1292 1307 <div id="rfc.iref.h.8"></div> … … 1755 1770 </p> 1756 1771 <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a> <a id="mhtml.line.length" href="#mhtml.line.length">MHTML and Line Length Limitations</a></h2> 1757 <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557. 1"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not1772 <p id="rfc.section.A.7.p.1">HTTP implementations which share code with MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a> implementations need to be aware of MIME line length limitations. Since HTTP does not have this limitation, HTTP does not 1758 1773 fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations 1759 1774 and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section 2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein. … … 1802 1817 </p> 1803 1818 <p id="rfc.section.C.1.p.3">Content-Base was deleted from the specification: it was not implemented widely, and there is no simple, safe way to introduce 1804 it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557. 2"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>.1819 it without a robust extension mechanism. In addition, it is used in a similar, but not identical fashion in MHTML <a href="#RFC2557" id="rfc.xref.RFC2557.3"><cite title="MIME Encapsulation of Aggregate Documents, such as HTML (MHTML)">[RFC2557]</cite></a>. 1805 1820 </p> 1806 1821 <p id="rfc.section.C.1.p.4">A content-coding of "identity" was introduced, to solve problems discovered in caching. (<a href="#content.codings" title="Content Codings">Section 2.2</a>) 1807 1822 </p> 1808 <p id="rfc.section.C.1.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p. 1"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>.1823 <p id="rfc.section.C.1.p.5">The Alternates<span id="rfc.iref.a.5"></span><span id="rfc.iref.h.12"></span>, Content-Version<span id="rfc.iref.c.13"></span><span id="rfc.iref.h.13"></span>, Derived-From<span id="rfc.iref.d.2"></span><span id="rfc.iref.h.14"></span>, Link<span id="rfc.iref.l.1"></span><span id="rfc.iref.h.15"></span>, URI<span id="rfc.iref.u.1"></span><span id="rfc.iref.h.16"></span>, Public<span id="rfc.iref.p.2"></span><span id="rfc.iref.h.17"></span> and Content-Base<span id="rfc.iref.c.14"></span><span id="rfc.iref.h.18"></span> header fields were defined in previous versions of this specification, but not commonly implemented. See <a href="http://tools.ietf.org/html/rfc2068#section-19.6.2">Section 19.6.2</a> of <a href="#RFC2068" id="rfc.xref.RFC2068.5"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2068]</cite></a>. 1809 1824 </p> 1810 1825 <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a> <a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2> … … 2073 2088 </ul> 2074 2089 <h1 id="rfc.index"><a href="#rfc.index">Index</a></h1> 2075 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index. E">E</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a> <a href="#rfc.index.V">V</a>2090 <p class="noprint"><a href="#rfc.index.A">A</a> <a href="#rfc.index.B">B</a> <a href="#rfc.index.C">C</a> <a href="#rfc.index.D">D</a> <a href="#rfc.index.G">G</a> <a href="#rfc.index.H">H</a> <a href="#rfc.index.I">I</a> <a href="#rfc.index.L">L</a> <a href="#rfc.index.M">M</a> <a href="#rfc.index.P">P</a> <a href="#rfc.index.R">R</a> <a href="#rfc.index.U">U</a> 2076 2091 </p> 2077 2092 <div class="print2col"> … … 2113 2128 <li class="indline1">deflate (Coding Format) <a class="iref" href="#rfc.iref.d.1">2.2</a></li> 2114 2129 <li class="indline1">Derived-From header <a class="iref" href="#rfc.iref.d.2"><b>C.1</b></a></li> 2115 </ul>2116 </li>2117 <li class="indline0"><a id="rfc.index.E" href="#rfc.index.E"><b>E</b></a><ul class="ind">2118 <li class="indline1">entity <a class="iref" href="#rfc.iref.e.1">1.1</a></li>2119 2130 </ul> 2120 2131 </li> … … 2228 2239 </ul> 2229 2240 </li> 2230 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#rfc.xref.Part2.2">5.7</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind"> 2231 <li class="indline1"><em>Section 6.1</em> <a class="iref" href="#rfc.xref.Part2.2">5.7</a></li> 2241 <li class="indline1"><em>Part2</em> <a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind"> 2232 2242 <li class="indline1"><em>Section 9.9</em> <a class="iref" href="#rfc.xref.Part2.1">4.1</a></li> 2233 2243 </ul> … … 2241 2251 </ul> 2242 2252 </li> 2243 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#rfc.xref.Part6.4">5.7</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind"> 2244 <li class="indline1"><em>Section 2.7</em> <a class="iref" href="#rfc.xref.Part6.4">5.7</a></li> 2253 <li class="indline1"><em>Part6</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a>, <a class="iref" href="#rfc.xref.Part6.3">4.1</a>, <a class="iref" href="#Part6"><b>9.1</b></a><ul class="ind"> 2245 2254 <li class="indline1"><em>Section 3.3</em> <a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li> 2246 2255 <li class="indline1"><em>Section 3.5</em> <a class="iref" href="#rfc.xref.Part6.3">4.1</a></li> 2247 2256 </ul> 2248 2257 </li> 2249 <li class="indline1">Public header <a class="iref" href="#rfc.iref.p.1"><b>C.1</b></a></li> 2258 <li class="indline1">payload <a class="iref" href="#rfc.iref.p.1">1.1</a></li> 2259 <li class="indline1">Public header <a class="iref" href="#rfc.iref.p.2"><b>C.1</b></a></li> 2250 2260 </ul> 2251 2261 </li> … … 2280 2290 <li class="indline1"><em>RFC2295</em> <a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li> 2281 2291 <li class="indline1"><em>RFC2388</em> <a class="iref" href="#rfc.xref.RFC2388.1">2.3.2</a>, <a class="iref" href="#RFC2388"><b>9.2</b></a></li> 2282 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.1">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.2">C.1</a></li> 2292 <li class="indline1"><em>RFC2557</em> <a class="iref" href="#rfc.xref.RFC2557.1">5.7</a>, <a class="iref" href="#RFC2557"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2557.2">A.7</a>, <a class="iref" href="#rfc.xref.RFC2557.3">C.1</a><ul class="ind"> 2293 <li class="indline1"><em>Section 4</em> <a class="iref" href="#rfc.xref.RFC2557.1">5.7</a></li> 2294 </ul> 2295 </li> 2283 2296 <li class="indline1"><em>RFC2616</em> <a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#rfc.xref.RFC2616.2">5.4</a>, <a class="iref" href="#RFC2616"><b>9.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.3">E.1</a><ul class="ind"> 2284 2297 <li class="indline1"><em>Section 14.4</em> <a class="iref" href="#rfc.xref.RFC2616.2">5.4</a></li> … … 2314 2327 </ul> 2315 2328 </li> 2316 <li class="indline0"><a id="rfc.index.V" href="#rfc.index.V"><b>V</b></a><ul class="ind">2317 <li class="indline1">variant <a class="iref" href="#rfc.iref.v.1">1.1</a></li>2318 </ul>2319 </li>2320 2329 </ul> 2321 2330 </div> -
draft-ietf-httpbis/latest/p4-conditional.html
r853 r857 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="2010-07-1 6">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 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: January 17, 2011</td>428 <td class="left">Expires: January 20, 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">July 1 6, 2010</td>485 <td class="right">July 19, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 17, 2011.</p>511 <p>This Internet-Draft will expire in January 20, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p5-range.html
r853 r857 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="2010-07-1 6">402 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 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: January 17, 2011</td>428 <td class="left">Expires: January 20, 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">July 1 6, 2010</td>485 <td class="right">July 19, 2010</td> 486 486 </tr> 487 487 </tbody> … … 509 509 in progress”. 510 510 </p> 511 <p>This Internet-Draft will expire in January 17, 2011.</p>511 <p>This Internet-Draft will expire in January 20, 2011.</p> 512 512 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 513 513 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p6-cache.html
r853 r857 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="2010-07-1 6">404 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 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: January 17, 2011</td>430 <td class="left">Expires: January 20, 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">July 1 6, 2010</td>491 <td class="right">July 19, 2010</td> 492 492 </tr> 493 493 </tbody> … … 515 515 in progress”. 516 516 </p> 517 <p>This Internet-Draft will expire in January 17, 2011.</p>517 <p>This Internet-Draft will expire in January 20, 2011.</p> 518 518 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 519 519 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p> -
draft-ietf-httpbis/latest/p7-auth.html
r853 r857 394 394 <meta name="dct.creator" content="Reschke, J. F."> 395 395 <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest"> 396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-1 6">396 <meta name="dct.issued" scheme="ISO8601" content="2010-07-19"> 397 397 <meta name="dct.replaces" content="urn:ietf:rfc:2616"> 398 398 <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."> … … 425 425 </tr> 426 426 <tr> 427 <td class="left">Expires: January 17, 2011</td>427 <td class="left">Expires: January 20, 2011</td> 428 428 <td class="right">HP</td> 429 429 </tr> … … 478 478 <tr> 479 479 <td class="left"></td> 480 <td class="right">July 1 6, 2010</td>480 <td class="right">July 19, 2010</td> 481 481 </tr> 482 482 </tbody> … … 504 504 in progress”. 505 505 </p> 506 <p>This Internet-Draft will expire in January 17, 2011.</p>506 <p>This Internet-Draft will expire in January 20, 2011.</p> 507 507 <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1> 508 508 <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
Note: See TracChangeset
for help on using the changeset viewer.