Changeset 162


Ignore:
Timestamp:
Jan 11, 2008, 7:39:06 PM (12 years ago)
Author:
fielding@…
Message:

editorial: write preliminary introduction to p2 noting future reorg

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

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/p2-semantics.html

    r157 r162  
    608608      </ul>
    609609      <h1 id="rfc.section.1" class="np"><a href="#rfc.section.1">1.</a>&nbsp;<a id="introduction" href="#introduction">Introduction</a></h1>
    610       <p id="rfc.section.1.p.1">This document will define aspects of HTTP related to request and response semantics. Right now it only includes the extracted
    611          relevant sections of RFC 2616 with only minor edits.
    612       </p>
    613       <p id="rfc.section.1.p.2">The HTTP protocol is a request/response protocol. A client sends a request to the server in the form of a request method,
    614          URI, and protocol version, followed by a MIME-like message containing request modifiers, client information, and possible
    615          body content over a connection with a server. The server responds with a status line, including the message's protocol version
    616          and a success or error code, followed by a MIME-like message containing server information, entity metainformation, and possible
    617          entity-body content. The relationship between HTTP and MIME is described in <a href="p3-payload.html#differences.between.http.entities.and.rfc.2045.entities" title="Differences Between HTTP Entities and RFC 2045 Entities">Appendix A</a> of <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     610      <p id="rfc.section.1.p.1">This document defines HTTP/1.1 request and response semantics. Each HTTP message, as defined in <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, is in the form of either a request or a response. An HTTP server listens on a connection for HTTP requests and responds
     611         to each request, in the order received on that connection, with one or more HTTP response messages. This document defines
     612         the commonly agreed upon semantics of the HTTP uniform interface, the intentions defined by each request method, and the various
     613         response messages that might be expected as a result of applying that method for the requested resource.
     614      </p>
     615      <p id="rfc.section.1.p.2">This document is currently disorganized in order to minimize the changes between drafts and enable reviewers to see the smaller
     616         errata changes. The next draft will reorganize the sections to better reflect the content. In particular, the sections will
     617         be ordered according to the typical processing of an HTTP request message (after message parsing): resource mapping, general
     618         header fields, methods, request modifiers, response status, and resource metadata. The current mess reflects how widely dispersed
     619         these topics and associated requirements had become in <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    618620      </p>
    619621      <h2 id="rfc.section.1.1"><a href="#rfc.section.1.1">1.1</a>&nbsp;<a id="intro.requirements" href="#intro.requirements">Requirements</a></h2>
     
    657659         method invocation.
    658660      </p>
    659       <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  request-header = Accept                   ; <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>
    660                  | Accept-Charset           ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>
    661                  | Accept-Encoding          ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>
    662                  | Accept-Language          ; <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
     661      <div id="rfc.figure.u.4"></div><pre class="inline"><span id="rfc.iref.g.5"></span>  request-header = Accept                   ; <a href="#Part3" id="rfc.xref.Part3.1"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept" title="Accept">Section 5.1</a>
     662                 | Accept-Charset           ; <a href="#Part3" id="rfc.xref.Part3.2"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-charset" title="Accept-Charset">Section 5.2</a>
     663                 | Accept-Encoding          ; <a href="#Part3" id="rfc.xref.Part3.3"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-encoding" title="Accept-Encoding">Section 5.3</a>
     664                 | Accept-Language          ; <a href="#Part3" id="rfc.xref.Part3.4"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>, <a href="p3-payload.html#header.accept-language" title="Accept-Language">Section 5.4</a>
    663665                 | Authorization            ; <a href="#Part7" id="rfc.xref.Part7.1"><cite title="HTTP/1.1, part 7: Authentication">[Part7]</cite></a>, <a href="p7-auth.html#header.authorization" title="Authorization">Section 3.1</a>
    664666                 | Expect                   ; <a href="#header.expect" id="rfc.xref.header.expect.1" title="Expect">Section&nbsp;10.2</a>
    665667                 | From                     ; <a href="#header.from" id="rfc.xref.header.from.1" title="From">Section&nbsp;10.3</a>
    666                  | Host                     ; <a href="#Part1" id="rfc.xref.Part1.1"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a>
     668                 | Host                     ; <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.host" title="Host">Section 8.4</a>
    667669                 | If-Match                 ; <a href="#Part4" id="rfc.xref.Part4.1"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-match" title="If-Match">Section 6.2</a>
    668670                 | If-Modified-Since        ; <a href="#Part4" id="rfc.xref.Part4.2"><cite title="HTTP/1.1, part 4: Conditional Requests">[Part4]</cite></a>, <a href="p4-conditional.html#header.if-modified-since" title="If-Modified-Since">Section 6.3</a>
     
    674676                 | Range                    ; <a href="#Part5" id="rfc.xref.Part5.2"><cite title="HTTP/1.1, part 5: Range Requests and Partial Responses">[Part5]</cite></a>, <a href="p5-range.html#header.range" title="Range">Section 5.4</a>
    675677                 | Referer                  ; <a href="#header.referer" id="rfc.xref.header.referer.1" title="Referer">Section&nbsp;10.6</a>
    676                  | TE                       ; <a href="#Part1" id="rfc.xref.Part1.2"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>
     678                 | TE                       ; <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, <a href="p1-messaging.html#header.upgrade" title="Upgrade">Section 8.8</a>
    677679                 | User-Agent               ; <a href="#header.user-agent" id="rfc.xref.header.user-agent.1" title="User-Agent">Section&nbsp;10.9</a>
    678680</pre><p id="rfc.section.4.p.3">Request-header field names can be extended reliably only in combination with a change in the protocol version. However, new
     
    760762      <p id="rfc.section.7.p.1">Request and Response messages <em class="bcp14">MAY</em> transfer an entity if not otherwise restricted by the request method or response status code. An entity consists of entity-header
    761763         fields and an entity-body, although some responses will only include the entity-headers. HTTP entity-body and entity-header
    762          fields are defined in <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
    763       </p>
    764       <p id="rfc.section.7.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.3"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
     764         fields are defined in <a href="#Part3" id="rfc.xref.Part3.5"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>.
     765      </p>
     766      <p id="rfc.section.7.p.2">An entity-body is only present in a message when a message-body is present, as described in <a href="p1-messaging.html#message.body" title="Message Body">Section 4.3</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. The entity-body is obtained from the message-body by decoding any Transfer-Encoding that might have been applied to ensure
    765767         safe and proper transfer of the message.
    766768      </p>
    767769      <h1 id="rfc.section.8"><a href="#rfc.section.8">8.</a>&nbsp;<a id="method.definitions" href="#method.definitions">Method Definitions</a></h1>
    768770      <p id="rfc.section.8.p.1">The set of common methods for HTTP/1.1 is defined below. Although this set can be expanded, additional methods cannot be assumed
    769          to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.4"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
     771         to share the same semantics for separately extended clients and servers. The Host request-header field (<a href="p1-messaging.html#header.host" title="Host">Section 8.4</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) <em class="bcp14">MUST</em> accompany all HTTP/1.1 requests.
    770772      </p>
    771773      <h2 id="rfc.section.8.1"><a href="#rfc.section.8.1">8.1</a>&nbsp;<a id="safe.and.idempotent" href="#safe.and.idempotent">Safe and Idempotent Methods</a></h2>
     
    926928      </p>
    927929      <p id="rfc.section.8.8.p.2">TRACE allows the client to see what is being received at the other end of the request chain and use that data for testing
    928          or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.5"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
     930         or diagnostic information. The value of the Via header field (<a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>) is of particular interest, since it acts as a trace of the request chain. Use of the Max-Forwards header field allows the
    929931         client to limit the length of the request chain, which is useful for testing a chain of proxies forwarding messages in an
    930932         infinite loop.
     
    959961      <p id="rfc.section.9.1.1.p.1">The client <em class="bcp14">SHOULD</em> continue with its request. This interim response is used to inform the client that the initial part of the request has been
    960962         received and has not yet been rejected by the server. The client <em class="bcp14">SHOULD</em> continue by sending the remainder of the request or, if the request has already been completed, ignore this response. The
    961          server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.6"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
     963         server <em class="bcp14">MUST</em> send a final response after the request has been completed. See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for detailed discussion of the use and handling of this status code.
    962964      </p>
    963965      <div id="rfc.iref.26"></div>
     
    10591061      <h3 id="rfc.section.9.3.1"><a href="#rfc.section.9.3.1">9.3.1</a>&nbsp;<a id="status.300" href="#status.300">300 Multiple Choices</a></h3>
    10601062      <p id="rfc.section.9.3.1.p.1">The requested resource corresponds to any one of a set of representations, each with its own specific location, and agent-driven
    1061          negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
     1063         negotiation information (<a href="p3-payload.html#content.negotiation" title="Content Negotiation">Section 4</a> of <a href="#Part3" id="rfc.xref.Part3.6"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) is being provided so that the user (or user agent) can select a preferred representation and redirect its request to that
    10621064         location.
    10631065      </p>
     
    13411343      <p id="rfc.section.9.5.6.p.1">The server does not support, or refuses to support, the HTTP protocol version that was used in the request message. The server
    13421344         is indicating that it is unable or unwilling to complete the request using the same major version as the client, as described
    1343          in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.7"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
     1345         in <a href="p1-messaging.html#http.version" title="HTTP Version">Section 3.1</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>, other than with this error message. The response <em class="bcp14">SHOULD</em> contain an entity describing why that version is not supported and what other protocols are supported by that server.
    13441346      </p>
    13451347      <h1 id="rfc.section.10"><a href="#rfc.section.10">10.</a>&nbsp;<a id="header.fields" href="#header.fields">Header Field Definitions</a></h1>
     
    13881390      </p>
    13891391      <p id="rfc.section.10.2.p.7">Many older HTTP/1.0 and HTTP/1.1 applications do not understand the Expect header.</p>
    1390       <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.8"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
     1392      <p id="rfc.section.10.2.p.8">See <a href="p1-messaging.html#use.of.the.100.status" title="Use of the 100 (Continue) Status">Section 7.2.3</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a> for the use of the 100 (Continue) status.
    13911393      </p>
    13921394      <div id="rfc.iref.f.1"></div>
     
    14221424</pre><p id="rfc.section.10.4.p.5"> </p>
    14231425      <dl class="empty">
    1424          <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.8"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
     1426         <dd> <b>Note:</b> The Content-Location header field (<a href="p3-payload.html#header.content-location" title="Content-Location">Section 5.7</a> of <a href="#Part3" id="rfc.xref.Part3.7"><cite title="HTTP/1.1, part 3: Message Payload and Content Negotiation">[Part3]</cite></a>) differs from Location in that the Content-Location identifies the original location of the entity enclosed in the request.
    14251427            It is therefore possible for a response to contain header fields for both Location and Content-Location.
    14261428         </dd>
     
    14831485</pre><p id="rfc.section.10.8.p.3">Example:</p>
    14841486      <div id="rfc.figure.u.20"></div><pre class="text">    Server: CERN/3.0 libwww/2.17
    1485 </pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.9"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
     1487</pre><p id="rfc.section.10.8.p.5">If the response is being forwarded through a proxy, the proxy application <em class="bcp14">MUST NOT</em> modify the Server response-header. Instead, it <em class="bcp14">MUST</em> include a Via field (as described in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>).
    14861488      </p>
    14871489      <dl class="empty">
     
    16761678      </p>
    16771679      <p id="rfc.section.A.2.p.4">In the description of the Server header, the Via field was described as a SHOULD. The requirement was and is stated correctly
    1678          in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.10"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;10.8</a>)
     1680         in the description of the Via header in <a href="p1-messaging.html#header.via" title="Via">Section 8.9</a> of <a href="#Part1" id="rfc.xref.Part1.11"><cite title="HTTP/1.1, part 1: URIs, Connections, and Message Parsing">[Part1]</cite></a>. (<a href="#header.server" id="rfc.xref.header.server.3" title="Server">Section&nbsp;10.8</a>)
    16791681      </p>
    16801682      <h1 id="rfc.section.B"><a href="#rfc.section.B">B.</a>&nbsp;Change Log (to be removed by RFC Editor before publication)
     
    16821684      <h2 id="rfc.section.B.1"><a href="#rfc.section.B.1">B.1</a>&nbsp;Since RFC2616
    16831685      </h2>
    1684       <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.1"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
     1686      <p id="rfc.section.B.1.p.1">Extracted relevant partitions from <a href="#RFC2616" id="rfc.xref.RFC2616.2"><cite title="Hypertext Transfer Protocol -- HTTP/1.1">[RFC2616]</cite></a>.
    16851687      </p>
    16861688      <h2 id="rfc.section.B.2"><a href="#rfc.section.B.2">B.2</a>&nbsp;Since draft-ietf-httpbis-p2-semantics-00
     
    18941896            </li>
    18951897            <li class="indline0"><a id="rfc.index.P" href="#rfc.index.P"><b>P</b></a><ul class="ind">
    1896                   <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">7</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a>, <a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.7">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.10">A.2</a><ul class="ind">
    1897                         <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">9.5.6</a></li>
    1898                         <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">7</a></li>
    1899                         <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">10.2</a></li>
    1900                         <li class="indline1"><em>Section 8.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">4</a>, <a class="iref" href="#rfc.xref.Part1.4">8</a></li>
    1901                         <li class="indline1"><em>Section 8.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">4</a></li>
    1902                         <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.5">8.8</a>, <a class="iref" href="#rfc.xref.Part1.9">10.8</a>, <a class="iref" href="#rfc.xref.Part1.10">A.2</a></li>
     1898                  <li class="indline1"><em>Part1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.1">1</a>, <a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.3">4</a>, <a class="iref" href="#rfc.xref.Part1.4">7</a>, <a class="iref" href="#rfc.xref.Part1.5">8</a>, <a class="iref" href="#rfc.xref.Part1.6">8.8</a>, <a class="iref" href="#rfc.xref.Part1.7">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.8">9.5.6</a>, <a class="iref" href="#rfc.xref.Part1.9">10.2</a>, <a class="iref" href="#rfc.xref.Part1.10">10.8</a>, <a class="iref" href="#Part1"><b>14.1</b></a>, <a class="iref" href="#rfc.xref.Part1.11">A.2</a><ul class="ind">
     1899                        <li class="indline1"><em>Section 3.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.8">9.5.6</a></li>
     1900                        <li class="indline1"><em>Section 4.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.4">7</a></li>
     1901                        <li class="indline1"><em>Section 7.2.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.7">9.1.1</a>, <a class="iref" href="#rfc.xref.Part1.9">10.2</a></li>
     1902                        <li class="indline1"><em>Section 8.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.2">4</a>, <a class="iref" href="#rfc.xref.Part1.5">8</a></li>
     1903                        <li class="indline1"><em>Section 8.8</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.3">4</a></li>
     1904                        <li class="indline1"><em>Section 8.9</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part1.6">8.8</a>, <a class="iref" href="#rfc.xref.Part1.10">10.8</a>, <a class="iref" href="#rfc.xref.Part1.11">A.2</a></li>
    19031905                     </ul>
    19041906                  </li>
    1905                   <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a>, <a class="iref" href="#rfc.xref.Part3.2">4</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">4</a>, <a class="iref" href="#rfc.xref.Part3.5">4</a>, <a class="iref" href="#rfc.xref.Part3.6">7</a>, <a class="iref" href="#rfc.xref.Part3.7">9.3.1</a>, <a class="iref" href="#rfc.xref.Part3.8">10.4</a>, <a class="iref" href="#Part3"><b>14.1</b></a><ul class="ind">
    1906                         <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">9.3.1</a></li>
    1907                         <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">4</a></li>
    1908                         <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">4</a></li>
    1909                         <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">4</a></li>
    1910                         <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.5">4</a></li>
    1911                         <li class="indline1"><em>Section 5.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.8">10.4</a></li>
    1912                         <li class="indline1"><em>Section A</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">1</a></li>
     1907                  <li class="indline1"><em>Part3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">4</a>, <a class="iref" href="#rfc.xref.Part3.2">4</a>, <a class="iref" href="#rfc.xref.Part3.3">4</a>, <a class="iref" href="#rfc.xref.Part3.4">4</a>, <a class="iref" href="#rfc.xref.Part3.5">7</a>, <a class="iref" href="#rfc.xref.Part3.6">9.3.1</a>, <a class="iref" href="#rfc.xref.Part3.7">10.4</a>, <a class="iref" href="#Part3"><b>14.1</b></a><ul class="ind">
     1908                        <li class="indline1"><em>Section 4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.6">9.3.1</a></li>
     1909                        <li class="indline1"><em>Section 5.1</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.1">4</a></li>
     1910                        <li class="indline1"><em>Section 5.2</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.2">4</a></li>
     1911                        <li class="indline1"><em>Section 5.3</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.3">4</a></li>
     1912                        <li class="indline1"><em>Section 5.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.4">4</a></li>
     1913                        <li class="indline1"><em>Section 5.7</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.Part3.7">10.4</a></li>
    19131914                     </ul>
    19141915                  </li>
     
    19501951                  <li class="indline1"><em>RFC2068</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2068.1">9.3.3</a>, <a class="iref" href="#rfc.xref.RFC2068.2">9.3.6</a>, <a class="iref" href="#RFC2068"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2068.3">A.1</a></li>
    19511952                  <li class="indline1"><em>RFC2119</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2119.1">1.1</a>, <a class="iref" href="#RFC2119"><b>14.1</b></a></li>
    1952                   <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#RFC2616"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.1">B.1</a></li>
     1953                  <li class="indline1"><em>RFC2616</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2616.1">1</a>, <a class="iref" href="#RFC2616"><b>14.2</b></a>, <a class="iref" href="#rfc.xref.RFC2616.2">B.1</a></li>
    19531954                  <li class="indline1"><em>RFC2822</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2822.1">10.3</a>, <a class="iref" href="#RFC2822"><b>14.2</b></a><ul class="ind">
    19541955                        <li class="indline1"><em>Section 3.4</em>&nbsp;&nbsp;<a class="iref" href="#rfc.xref.RFC2822.1">10.3</a></li>
  • draft-ietf-httpbis/latest/p2-semantics.xml

    r153 r162  
    2222  <!ENTITY auth                       "<xref target='Part7' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2323  <!ENTITY content-negotiation        "<xref target='Part3' x:rel='#content.negotiation' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    24   <!ENTITY diff2045entity             "<xref target='Part3' x:rel='#differences.between.http.entities.and.rfc.2045.entities' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2524  <!ENTITY uri                        "<xref target='Part1' x:rel='#uri' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
    2625  <!ENTITY http-url                   "<xref target='Part1' x:rel='#http-url' xmlns:x='http://purl.org/net/xml2rfc/ext'/>">
     
    245244<section title="Introduction" anchor="introduction">
    246245<t>
    247    This document will define aspects of HTTP related to request and response
    248    semantics. Right now it only includes the extracted relevant sections of
    249    RFC 2616 with only minor edits.
    250 </t>
    251 <t>
    252    The HTTP protocol is a request/response protocol. A client sends a
    253    request to the server in the form of a request method, URI, and
    254    protocol version, followed by a MIME-like message containing request
    255    modifiers, client information, and possible body content over a
    256    connection with a server. The server responds with a status line,
    257    including the message's protocol version and a success or error code,
    258    followed by a MIME-like message containing server information, entity
    259    metainformation, and possible entity-body content. The relationship
    260    between HTTP and MIME is described in &diff2045entity;.
     246   This document defines HTTP/1.1 request and response semantics.  Each HTTP
     247   message, as defined in &messaging;, is in the form of either a request or
     248   a response.  An HTTP server listens on a connection for HTTP requests and
     249   responds to each request, in the order received on that connection, with
     250   one or more HTTP response messages.  This document defines the commonly
     251   agreed upon semantics of the HTTP uniform interface, the intentions defined
     252   by each request method, and the various response messages that might be
     253   expected as a result of applying that method for the requested resource.
     254</t>
     255<t>
     256   This document is currently disorganized in order to minimize the changes
     257   between drafts and enable reviewers to see the smaller errata changes.
     258   The next draft will reorganize the sections to better reflect the content.
     259   In particular, the sections will be ordered according to the typical
     260   processing of an HTTP request message (after message parsing): resource
     261   mapping, general header fields, methods, request modifiers, response
     262   status, and resource metadata.  The current mess reflects how widely
     263   dispersed these topics and associated requirements had become in
     264   <xref target="RFC2616"/>.
    261265</t>
    262266
Note: See TracChangeset for help on using the changeset viewer.