Ignore:
Timestamp:
15/07/12 02:55:39 (10 years ago)
Author:
fielding@…
Message:

Update p2 introduction and replace redundancies with reference to p1

File:
1 edited

Legend:

Unmodified
Added
Removed

  • draft-ietf-httpbis/latest/p2-semantics.xml

    r1778 r1781  
    188188   distributed, collaborative, hypertext information systems. HTTP has been in
    189189   use by the World Wide Web global information initiative since 1990. This
    190    document is Part 2 of the seven-part specification that defines the protocol
    191    referred to as "HTTP/1.1" and, taken together, obsoletes RFC 2616.
    192 </t>
    193 <t>
    194    Part 2 defines the semantics of HTTP messages as expressed by request
     190   document is Part 2 of the six-part specification that defines the protocol
     191   referred to as "HTTP/1.1".
     192</t>
     193<t>
     194   Part 2 defines the semantics of HTTP messages, as expressed by request
    195195   methods, request header fields, response status codes, and response header
    196    fields. Furthermore, it defines HTTP message content, metadata, and content
    197    negotiation.
     196   fields, the payload of messages as metadata and body content, and the
     197   mechanisms for content negotiation.
    198198</t>
    199199</abstract>
    … …  
    219219<section title="Introduction" anchor="introduction">
    220220<t>
    221    This document defines HTTP/1.1 request and response semantics.  Each HTTP
    222    message, as defined in &messaging;, is in the form of either a request or
    223    a response.  An HTTP server listens on a connection for HTTP requests and
    224    responds to each request, in the order received on that connection, with
    225    one or more HTTP response messages.  This document defines the commonly
    226    agreed upon semantics of the HTTP uniform interface, the intentions defined
    227    by each request method, and the various response messages that might be
    228    expected as a result of applying that method to the target resource.
    229 </t>
    230 <t>
    231    Furthermore, it defines HTTP/1.1 message payloads (a.k.a., content), the
    232    associated metadata header fields that define how the payload is intended
    233    to be interpreted by a recipient, the request header fields that
    234    might influence content selection, and the various selection algorithms
    235    that are collectively referred to as HTTP content negotiation.
    236 </t>
    237 <t>
     221   This document defines HTTP/1.1 request and response semantics in terms of
     222   the architecture, syntax notation, and conformance criteria defined in
     223   &architecture;. Each HTTP message is either a request or a response.
     224   A server listens on a connection for a request, parses each message
     225   received, interprets the message semantics in relation to the identified
     226   request target, and responds to that request with one or more response
     227   messages.
     228</t>
     229<t>
     230   HTTP provides a uniform interface for interacting with resources regardless
     231   of their type, nature, or implementation.  HTTP semantics includes the
     232   intentions defined by each request method, extensions to those semantics
     233   that might be described in request header fields, the meaning of status
     234   codes to indicate a machine-readable response, and additional control data
     235   and resource metadata that might be given in response header fields.
     236</t>
     237<t><iref item="content negotiation"/>
     238   In addition, this document defines the payload of messages (a.k.a.,
     239   content), the associated metadata header fields that define how the payload
     240   is intended to be interpreted by a recipient, the request header fields
     241   that might influence content selection, and the various selection
     242   algorithms that are collectively referred to as
     243   "<x:dfn>content negotiation</x:dfn>".
     244</t>
     245<x:note><t>
    238246   This document is currently disorganized in order to minimize the changes
    239247   between drafts and enable reviewers to see the smaller errata changes.
    … …  
    245253   reflects how widely dispersed these topics and associated requirements
    246254   had become in <xref target="RFC2616"/>.
    247 </t>
    248 
    249 <section title="Terminology" anchor="terminology">
    250 <t>
    251    This specification uses a number of terms to refer to the roles
    252    played by participants in, and objects of, the HTTP communication.
    253 </t>
    254 <t>
    255   <iref item="content negotiation"/>
    256   <x:dfn>content negotiation</x:dfn>
    257   <list>
    258     <t>
    259       The mechanism for selecting the appropriate representation when
    260       servicing a request. The representation in any response
    261       can be negotiated (including error responses).
    262     </t>
    263   </list>
    264 </t>
    265 <t>
    266   <iref primary="true" item="selected representation"/>
    267   <x:dfn>selected representation</x:dfn>
    268   <list>
    269     <t>
    270       The current representation of the target resource that would have been
    271       selected in a successful response if the same request had used the
    272       method GET and excluded any conditional request header fields.
    273     </t>
    274   </list>
    275 </t>
    276 </section>
    277 
    278 <section title="Conformance and Error Handling" anchor="intro.conformance.and.error.handling">
    279 <t>
    280    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
    281    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
    282    document are to be interpreted as described in <xref target="RFC2119"/>.
    283 </t>
    284 <t>
    285    This specification targets conformance criteria according to the role of
    286    a participant in HTTP communication.  Hence, HTTP requirements are placed
    287    on senders, recipients, clients, servers, user agents, intermediaries,
    288    origin servers, proxies, gateways, or caches, depending on what behavior
    289    is being constrained by the requirement. See &architecture; for definitions
    290    of these terms.
    291 </t>
    292 <t>
    293    The verb "generate" is used instead of "send" where a requirement
    294    differentiates between creating a protocol element and merely forwarding a
    295    received element downstream.
    296 </t>
    297 <t>
    298    An implementation is considered conformant if it complies with all of the
    299    requirements associated with the roles it partakes in HTTP. Note that
    300    SHOULD-level requirements are relevant here, unless one of the documented
    301    exceptions is applicable.
    302 </t>
    303 <t>
    304    This document also uses ABNF to define valid protocol elements
    305    (<xref target="notation"/>).
    306    In addition to the prose requirements placed upon them, senders &MUST-NOT;
    307    generate protocol elements that do not match the grammar defined by the
    308    ABNF rules for those protocol elements that are applicable to the sender's
    309    role. If a received protocol element is processed, the recipient &MUST; be
    310    able to parse any value that would match the ABNF rules for that protocol
    311    element, excluding only those rules not applicable to the recipient's role.
    312 </t>
    313 <t>
    314    Unless noted otherwise, a recipient &MAY; attempt to recover a usable
    315    protocol element from an invalid construct.  HTTP does not define
    316    specific error handling mechanisms except when they have a direct impact
    317    on security, since different applications of the protocol require
    318    different error handling strategies.  For example, a Web browser might
    319    wish to transparently recover from a response where the
    320    <x:ref>Location</x:ref> header field doesn't parse according to the ABNF,
    321    whereas a systems control client might consider any form of error recovery
    322    to be dangerous.
    323 </t>
    324 </section>
    325 
    326 <section title="Syntax Notation" anchor="notation">
    327   <x:anchor-alias value="ALPHA"/>
    328   <x:anchor-alias value="CR"/>
    329   <x:anchor-alias value="DIGIT"/>
    330   <x:anchor-alias value="LF"/>
    331   <x:anchor-alias value="OCTET"/>
    332   <x:anchor-alias value="SP"/>
    333   <x:anchor-alias value="VCHAR"/>
    334 <t>
    335    This specification uses the Augmented Backus-Naur Form (ABNF) notation
    336    of <xref target="RFC5234"/> with the list rule extension defined in
    337    &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
    338    with the list rule expanded.
    339 </t>
    340 <t>
    341   The following core rules are included by
    342   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
    343   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
    344   DIGIT (decimal 0-9), DQUOTE (double quote),
    345   HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
    346   OCTET (any 8-bit sequence of data), SP (space), and
    347   VCHAR (any visible US-ASCII character).
    348 </t>
    349 
    350 <section title="Core Rules" anchor="core.rules">
    351   <x:anchor-alias value="quoted-string"/>
    352   <x:anchor-alias value="token"/>
    353   <x:anchor-alias value="word"/>
    354   <x:anchor-alias value="BWS"/>
    355   <x:anchor-alias value="OWS"/>
    356   <x:anchor-alias value="RWS"/>
    357 <t>
    358   The core rules below are defined in <xref target="Part1"/>:
    359 </t>
    360 <figure><artwork type="abnf2616">
    361   <x:ref>BWS</x:ref>           = &lt;BWS, defined in &whitespace;&gt;
    362   <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
    363   <x:ref>RWS</x:ref>           = &lt;RWS, defined in &whitespace;&gt;
    364   <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
    365   <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
    366   <x:ref>word</x:ref>          = &lt;word, defined in &field-components;&gt;
    367 </artwork></figure>
    368 </section>
    369 
    370 <section title="ABNF Rules defined in other Parts of the Specification" anchor="abnf.dependencies">
    371   <x:anchor-alias value="absolute-URI"/>
    372   <x:anchor-alias value="comment"/>
    373   <x:anchor-alias value="partial-URI"/>
    374   <x:anchor-alias value="qvalue"/>
    375   <x:anchor-alias value="URI-reference"/>
    376 <t>
    377   The ABNF rules below are defined in other parts:
    378 </t>
    379 <figure><!--Part1--><artwork type="abnf2616">
    380   <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in &uri;&gt;
    381   <x:ref>comment</x:ref>       = &lt;comment, defined in &field-components;&gt;
    382   <x:ref>partial-URI</x:ref>   = &lt;partial-URI, defined in &uri;&gt;
    383   <x:ref>qvalue</x:ref>        = &lt;qvalue, defined in &qvalue;&gt;
    384   <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in &uri;&gt;
    385 </artwork></figure>
    386 </section>
    387 </section>
     255</t></x:note>
    388256</section>
    389257
    … …  
    27812649  <c>Expires</c> <c>&header-expires;</c>
    27822650</texttable>
     2651<t><iref primary="true" item="selected representation"/>
     2652   We use the term "<x:dfn>selected representation</x:dfn>" to refer to the
     2653   the current representation of a target resource that would have been
     2654   selected in a successful response if the same request had used the
     2655   method GET and excluded any conditional request header fields.
     2656</t>
    27832657<t>
    27842658   Additional header fields define metadata about the selected
    … …  
    37973671    &Note; Some recipients attempt to recover from Location fields
    37983672    that are not valid URI references. This specification does not mandate or
    3799     define such processing, but does allow it (see <xref target="intro.conformance.and.error.handling"/>).
     3673    define such processing, but does allow it.
    38003674  </t>
    38013675</x:note>
    … …  
    44624336</section>
    44634337
     4338<section title="ABNF Rules Defined Elsewhere" anchor="abnf.dependencies">
     4339  <x:anchor-alias value="ALPHA"/>
     4340  <x:anchor-alias value="CR"/>
     4341  <x:anchor-alias value="DIGIT"/>
     4342  <x:anchor-alias value="LF"/>
     4343  <x:anchor-alias value="OCTET"/>
     4344  <x:anchor-alias value="SP"/>
     4345  <x:anchor-alias value="VCHAR"/>
     4346  <x:anchor-alias value="BWS"/>
     4347  <x:anchor-alias value="OWS"/>
     4348  <x:anchor-alias value="RWS"/>
     4349  <x:anchor-alias value="absolute-URI"/>
     4350  <x:anchor-alias value="comment"/>
     4351  <x:anchor-alias value="partial-URI"/>
     4352  <x:anchor-alias value="qvalue"/>
     4353  <x:anchor-alias value="URI-reference"/>
     4354  <x:anchor-alias value="quoted-string"/>
     4355  <x:anchor-alias value="token"/>
     4356  <x:anchor-alias value="word"/>
     4357<t>
     4358   This specification uses the Augmented Backus-Naur Form (ABNF) notation
     4359   of <xref target="RFC5234"/> with the list rule extension defined in
     4360   &notation;.  <xref target="collected.abnf"/> shows the collected ABNF
     4361   with the list rule expanded.
     4362</t>
     4363<t>
     4364   The following core rules are included by
     4365   reference, as defined in <xref target="RFC5234" x:fmt="," x:sec="B.1"/>:
     4366   ALPHA (letters), CR (carriage return), CRLF (CR LF), CTL (controls),
     4367   DIGIT (decimal 0-9), DQUOTE (double quote),
     4368   HEXDIG (hexadecimal 0-9/A-F/a-f), HTAB (horizontal tab), LF (line feed),
     4369   OCTET (any 8-bit sequence of data), SP (space), and
     4370   VCHAR (any visible US-ASCII character).
     4371</t>
     4372<t>
     4373   The ABNF rules below are defined in other parts:
     4374</t>
     4375<figure><artwork type="abnf2616">
     4376  <x:ref>BWS</x:ref>           = &lt;BWS, defined in &whitespace;&gt;
     4377  <x:ref>OWS</x:ref>           = &lt;OWS, defined in &whitespace;&gt;
     4378  <x:ref>RWS</x:ref>           = &lt;RWS, defined in &whitespace;&gt;
     4379  <x:ref>URI-reference</x:ref> = &lt;URI-reference, defined in &uri;&gt;
     4380  <x:ref>absolute-URI</x:ref>  = &lt;absolute-URI, defined in &uri;&gt;
     4381  <x:ref>partial-URI</x:ref>   = &lt;partial-URI, defined in &uri;&gt;
     4382  <x:ref>quoted-string</x:ref> = &lt;quoted-string, defined in &field-components;&gt;
     4383  <x:ref>qvalue</x:ref>        = &lt;qvalue, defined in &qvalue;&gt;
     4384  <x:ref>token</x:ref>         = &lt;token, defined in &field-components;&gt;
     4385  <x:ref>word</x:ref>          = &lt;word, defined in &field-components;&gt;
     4386  <x:ref>comment</x:ref>       = &lt;comment, defined in &field-components;&gt;
     4387</artwork></figure>
     4388</section>
     4389
    44644390<section title="Security Considerations" anchor="security.considerations">
    44654391<t>
    … …  
    48714797  <seriesInfo name="RFC" value="2046"/>
    48724798</reference>
    4873 
     4799<!--
    48744800<reference anchor="RFC2119">
    48754801  <front>
    … …  
    48844810  <seriesInfo name="RFC" value="2119"/>
    48854811</reference>
    4886 
     4812-->
    48874813<reference anchor="RFC3986">
    48884814 <front>
Note: See TracChangeset for help on using the changeset viewer.