Ignore:
Timestamp:
19/07/10 11:52:42 (12 years ago)
Author:
fielding@…
Message:

regenerate html

Location:
draft-ietf-httpbis/latest
Files:
7 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p1-messaging.html

    r854 r857  
    404404      <meta name="dct.creator" content="Reschke, J. F.">
    405405      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p1-messaging-latest">
    406       <meta name="dct.issued" scheme="ISO8601" content="2010-07-17">
     406      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    407407      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    408408      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 1 provides an overview of HTTP and its associated terminology, defines the &#34;http&#34; and &#34;https&#34; Uniform Resource Identifier (URI) schemes, defines the generic message syntax and parsing requirements for HTTP message frames, and describes general security concerns for implementations.">
    … …  
    435435            </tr>
    436436            <tr>
    437                <td class="left">Expires: January 18, 2011</td>
     437               <td class="left">Expires: January 20, 2011</td>
    438438               <td class="right">HP</td>
    439439            </tr>
    … …  
    488488            <tr>
    489489               <td class="left"></td>
    490                <td class="right">July 17, 2010</td>
     490               <td class="right">July 19, 2010</td>
    491491            </tr>
    492492         </tbody>
    … …  
    516516         in progress”.
    517517      </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>
    519519      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    520520      <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  
    403403      <meta name="dct.creator" content="Reschke, J. F.">
    404404      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p2-semantics-latest">
    405       <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
     405      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    406406      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    407407      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    434434            </tr>
    435435            <tr>
    436                <td class="left">Expires: January 17, 2011</td>
     436               <td class="left">Expires: January 20, 2011</td>
    437437               <td class="right">HP</td>
    438438            </tr>
    … …  
    487487            <tr>
    488488               <td class="left"></td>
    489                <td class="right">July 16, 2010</td>
     489               <td class="right">July 19, 2010</td>
    490490            </tr>
    491491         </tbody>
    … …  
    514514         in progress”.
    515515      </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>
    517517      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    518518      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    11641164      <h3 id="rfc.section.8.2.2"><a href="#rfc.section.8.2.2">8.2.2</a>&nbsp;<a id="status.201" href="#status.201">201 Created</a></h3>
    11651165      <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 entity 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 an entity containing a list of resource characteristics and location(s) from which the user or user agent can choose
    1168          the one most appropriate. The entity format is specified by the media type given in the Content-Type header field. The origin
     1166         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
    11691169         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.
    11701170      </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 requested 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>).
    11731173      </p>
    11741174      <div id="rfc.iref.29"></div>
    … …  
    11951195      <div id="rfc.iref.s.8"></div>
    11961196      <h3 id="rfc.section.8.2.5"><a href="#rfc.section.8.2.5">8.2.5</a>&nbsp;<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.
    11991202      </p>
    12001203      <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 metainformation <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.
    12021205      </p>
    12031206      <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  
    401401      <meta name="dct.creator" content="Reschke, J. F.">
    402402      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p3-payload-latest">
    403       <meta name="dct.issued" scheme="ISO8601" content="2010-07-17">
     403      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    404404      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    405405      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 3 defines HTTP message content, metadata, and content negotiation.">
    … …  
    427427            </tr>
    428428            <tr>
    429                <td class="left">Expires: January 18, 2011</td>
     429               <td class="left">Expires: January 20, 2011</td>
    430430               <td class="right">J. Mogul</td>
    431431            </tr>
    … …  
    484484            <tr>
    485485               <td class="left"></td>
    486                <td class="right">July 17, 2010</td>
     486               <td class="right">July 19, 2010</td>
    487487            </tr>
    488488         </tbody>
    … …  
    510510         in progress”.
    511511      </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>
    513513      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    514514      <p>Copyright © 2010 IETF Trust and the persons identified as the document authors. All rights reserved.</p>
    … …  
    650650      </p>
    651651      <ul class="empty">
    652          <li>The mechanism for selecting the appropriate representation when servicing a request. The representation of entities in any
    653             response can be 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> 
    657657      </p>
    658658      <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.
    661662         </li>
    662663      </ul>
    … …  
    664665      </p>
    665666      <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.
    675670         </li>
    676671      </ul>
    … …  
    12671262      <div id="rfc.iref.h.7"></div>
    12681263      <h2 id="rfc.section.5.7"><a href="#rfc.section.5.7">5.7</a>&nbsp;<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.
    12751267      </p>
    12761268      <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>
    … …  
    12781270  <a href="#header.content-location" class="smpl">Content-Location-v</a> =
    12791271                    <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>
    12911306      <div id="rfc.iref.c.10"></div>
    12921307      <div id="rfc.iref.h.8"></div>
    … …  
    17551770      </p>
    17561771      <h2 id="rfc.section.A.7"><a href="#rfc.section.A.7">A.7</a>&nbsp;<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 not
     1772      <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
    17581773         fold long lines. MHTML messages being transported by HTTP follow all conventions of MHTML, including line length limitations
    17591774         and folding, canonicalization, etc., since HTTP transports all message-bodies as payload (see <a href="#multipart.types" title="Multipart Types">Section&nbsp;2.3.2</a>) and does not interpret the content or any MIME header lines that might be contained therein.
    … …  
    18021817      </p>
    18031818      <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>.
    18051820      </p>
    18061821      <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&nbsp;2.2</a>)
    18071822      </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>.
    18091824      </p>
    18101825      <h2 id="rfc.section.C.2"><a href="#rfc.section.C.2">C.2</a>&nbsp;<a id="changes.from.rfc.2616" href="#changes.from.rfc.2616">Changes from RFC 2616</a></h2>
    … …  
    20732088      </ul>
    20742089      <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>
    20762091      </p>
    20772092      <div class="print2col">
    … …  
    21132128                  <li class="indline1">deflate (Coding Format)&nbsp;&nbsp;<a class="iref" href="#rfc.iref.d.1">2.2</a></li>
    21142129                  <li class="indline1">Derived-From header&nbsp;&nbsp;<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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.e.1">1.1</a></li>
    21192130               </ul>
    21202131            </li>
    … …  
    22282239                     </ul>
    22292240                  </li>
    2230                   <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.2">5.7</a></li>
     2241                  <li class="indline1"><em>Part2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a>, <a class="iref" href="#Part2"><b>9.1</b></a><ul class="ind">
    22322242                        <li class="indline1"><em>Section 9.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part2.1">4.1</a></li>
    22332243                     </ul>
    … …  
    22412251                     </ul>
    22422252                  </li>
    2243                   <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.4">5.7</a></li>
     2253                  <li class="indline1"><em>Part6</em>&nbsp;&nbsp;<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">
    22452254                        <li class="indline1"><em>Section 3.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.1">1.3.2</a>, <a class="iref" href="#rfc.xref.Part6.2">3.1</a></li>
    22462255                        <li class="indline1"><em>Section 3.5</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part6.3">4.1</a></li>
    22472256                     </ul>
    22482257                  </li>
    2249                   <li class="indline1">Public header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1"><b>C.1</b></a></li>
     2258                  <li class="indline1">payload&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.1">1.1</a></li>
     2259                  <li class="indline1">Public header&nbsp;&nbsp;<a class="iref" href="#rfc.iref.p.2"><b>C.1</b></a></li>
    22502260               </ul>
    22512261            </li>
    … …  
    22802290                  <li class="indline1"><em>RFC2295</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2295.1">4</a>, <a class="iref" href="#RFC2295"><b>9.2</b></a></li>
    22812291                  <li class="indline1"><em>RFC2388</em>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<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>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2557.1">5.7</a></li>
     2294                     </ul>
     2295                  </li>
    22832296                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<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">
    22842297                        <li class="indline1"><em>Section 14.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.2">5.4</a></li>
    … …  
    23142327               </ul>
    23152328            </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&nbsp;&nbsp;<a class="iref" href="#rfc.iref.v.1">1.1</a></li>
    2318                </ul>
    2319             </li>
    23202329         </ul>
    23212330      </div>

  • draft-ietf-httpbis/latest/p4-conditional.html

    r853 r857  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p4-conditional-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 17, 2011</td>
     428               <td class="left">Expires: January 20, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 16, 2010</td>
     485               <td class="right">July 19, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </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>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <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  
    400400      <meta name="dct.creator" content="Reschke, J. F.">
    401401      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p5-range-latest">
    402       <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
     402      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    403403      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    404404      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 5 defines range-specific requests and the rules for constructing and combining responses to those requests.">
    … …  
    426426            </tr>
    427427            <tr>
    428                <td class="left">Expires: January 17, 2011</td>
     428               <td class="left">Expires: January 20, 2011</td>
    429429               <td class="right">J. Mogul</td>
    430430            </tr>
    … …  
    483483            <tr>
    484484               <td class="left"></td>
    485                <td class="right">July 16, 2010</td>
     485               <td class="right">July 19, 2010</td>
    486486            </tr>
    487487         </tbody>
    … …  
    509509         in progress”.
    510510      </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>
    512512      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    513513      <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  
    402402      <meta name="dct.creator" content="Reschke, J. F.">
    403403      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p6-cache-latest">
    404       <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
     404      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    405405      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    406406      <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 &#34;HTTP/1.1&#34; 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.">
    … …  
    428428            </tr>
    429429            <tr>
    430                <td class="left">Expires: January 17, 2011</td>
     430               <td class="left">Expires: January 20, 2011</td>
    431431               <td class="right">J. Mogul</td>
    432432            </tr>
    … …  
    489489            <tr>
    490490               <td class="left"></td>
    491                <td class="right">July 16, 2010</td>
     491               <td class="right">July 19, 2010</td>
    492492            </tr>
    493493         </tbody>
    … …  
    515515         in progress”.
    516516      </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>
    518518      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    519519      <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  
    394394      <meta name="dct.creator" content="Reschke, J. F.">
    395395      <meta name="dct.identifier" content="urn:ietf:id:draft-ietf-httpbis-p7-auth-latest">
    396       <meta name="dct.issued" scheme="ISO8601" content="2010-07-16">
     396      <meta name="dct.issued" scheme="ISO8601" content="2010-07-19">
    397397      <meta name="dct.replaces" content="urn:ietf:rfc:2616">
    398398      <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 &#34;HTTP/1.1&#34; and, taken together, obsoletes RFC 2616. Part 7 defines HTTP Authentication.">
    … …  
    425425            </tr>
    426426            <tr>
    427                <td class="left">Expires: January 17, 2011</td>
     427               <td class="left">Expires: January 20, 2011</td>
    428428               <td class="right">HP</td>
    429429            </tr>
    … …  
    478478            <tr>
    479479               <td class="left"></td>
    480                <td class="right">July 16, 2010</td>
     480               <td class="right">July 19, 2010</td>
    481481            </tr>
    482482         </tbody>
    … …  
    504504         in progress”.
    505505      </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>
    507507      <h1><a id="rfc.copyrightnotice" href="#rfc.copyrightnotice">Copyright Notice</a></h1>
    508508      <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.