Ignore:
Timestamp:
06/05/14 12:37:38 (6 years ago)
Author:
julian.reschke@…
Message:

punctuation (#553)

File:
1 edited

Legend:

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

    r2635 r2636  
    789789            request, parses each message received, interprets the message semantics in relation to the identified request target, and
    790790            responds to that request with one or more response messages. A client constructs request messages to communicate specific
    791             intentions, and examines received responses to see if the intentions were carried out and determine how to interpret the results.
    792             This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.
     791            intentions, and examines received responses to see if the intentions were carried out, and determine how to interpret the
     792            results. This document defines HTTP/1.1 request and response semantics in terms of the architecture defined in <a href="#RFC7230" id="rfc.xref.RFC7230.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>.
    793793         </p>
    794794         <p id="rfc.section.1.p.2">HTTP provides a uniform interface for interacting with a resource (<a href="#resources" title="Resources">Section&nbsp;2</a>), regardless of its type, nature, or implementation, via the manipulation and transfer of representations (<a href="#representations" title="Representations">Section&nbsp;3</a>).
     
    10471047</pre><p id="rfc.section.3.1.3.1.p.4">A language tag is a sequence of one or more case-insensitive subtags, each separated by a hyphen character ("-", %x2D). In
    10481048                     most cases, a language tag consists of a primary language subtag that identifies a broad family of related languages (e.g.,
    1049                      "en" = English) which is optionally followed by a series of subtags that refine or narrow that language's range (e.g., "en-CA"
     1049                     "en" = English), which is optionally followed by a series of subtags that refine or narrow that language's range (e.g., "en-CA"
    10501050                     = the variety of English as communicated in Canada). Whitespace is not allowed within a language tag. Example tags include:
    10511051                  </p>
     
    14411441               <h3 id="rfc.section.4.2.3"><a href="#rfc.section.4.2.3">4.2.3</a>&nbsp;<a href="#cacheable.methods">Cacheable Methods</a></h3>
    14421442               <p id="rfc.section.4.2.3.p.1">Request methods can be defined as "<dfn id="cacheable">cacheable</dfn>" to indicate that responses to them are allowed to be stored for future reuse; for specific requirements see <a href="#RFC7234" id="rfc.xref.RFC7234.1"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Caching">[RFC7234]</cite></a>. In general, safe methods that do not depend on a current or authoritative response are defined as cacheable; this specification
    1443                   defines GET, HEAD and POST as cacheable, although the overwhelming majority of cache implementations only support GET and
     1443                  defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and
    14441444                  HEAD.
    14451445               </p>
     
    14541454                  people speak of retrieving some identifiable information via HTTP, they are generally referring to making a GET request.
    14551455               </p>
    1456                <p id="rfc.section.4.3.1.p.2">It is tempting to think of resource identifiers as remote file system pathnames, and of representations as being a copy of
     1456               <p id="rfc.section.4.3.1.p.2">It is tempting to think of resource identifiers as remote file system pathnames and of representations as being a copy of
    14571457                  the contents of such files. In fact, that is how many resources are implemented (see <a href="#attack.pathname" title="Attacks Based on File and Path Names">Section&nbsp;9.1</a> for related security considerations). However, there are no such limitations in practice. The HTTP interface for a resource
    14581458                  is just as likely to be implemented as a tree of content objects, a programmatic view on various database records, or a gateway
    14591459                  to other information systems. Even when the URI mapping mechanism is tied to a file system, an origin server might be configured
    1460                   to execute the files with the request as input and send the output as the representation, rather than transfer the files directly.
    1461                   Regardless, only the origin server needs to know how each of its resource identifiers corresponds to an implementation, and
     1460                  to execute the files with the request as input and send the output as the representation rather than transfer the files directly.
     1461                  Regardless, only the origin server needs to know how each of its resource identifiers corresponds to an implementation and
    14621462                  how each implementation manages to select and send a current representation of the target resource in a response to GET.
    14631463               </p>
     
    15861586               <div id="rfc.iref.d.2"></div>
    15871587               <p id="rfc.section.4.3.5.p.1">The DELETE method requests that the origin server remove the association between the <a href="#resources" class="smpl">target resource</a> and its current functionality. In effect, this method is similar to the rm command in UNIX: it expresses a deletion operation
    1588                   on the URI mapping of the origin server, rather than an expectation that the previously associated information be deleted.
     1588                  on the URI mapping of the origin server rather than an expectation that the previously associated information be deleted.
    15891589               </p>
    15901590               <p id="rfc.section.4.3.5.p.2">If the target resource has one or more current representations, they might or might not be destroyed by the origin server,
     
    18241824               <div id="rfc.figure.u.22"></div><pre class="inline"><span id="rfc.iref.g.16"></span>  <a href="#header.max-forwards" class="smpl">Max-Forwards</a> = 1*<a href="#imported.abnf" class="smpl">DIGIT</a>
    18251825</pre><p id="rfc.section.5.1.2.p.3">The Max-Forwards value is a decimal integer indicating the remaining number of times this request message can be forwarded.</p>
    1826                <p id="rfc.section.5.1.2.p.4">Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary <em class="bcp14">MUST NOT</em> forward the request; instead, the intermediary <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary <em class="bcp14">MUST</em> generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of: a) the received
    1827                   value decremented by one (1), or b) the recipient's maximum supported value for Max-Forwards.
     1826               <p id="rfc.section.5.1.2.p.4">Each intermediary that receives a TRACE or OPTIONS request containing a Max-Forwards header field <em class="bcp14">MUST</em> check and update its value prior to forwarding the request. If the received value is zero (0), the intermediary <em class="bcp14">MUST NOT</em> forward the request; instead, the intermediary <em class="bcp14">MUST</em> respond as the final recipient. If the received Max-Forwards value is greater than zero, the intermediary <em class="bcp14">MUST</em> generate an updated Max-Forwards field in the forwarded message with a field-value that is the lesser of a) the received value
     1827                  decremented by one (1) or b) the recipient's maximum supported value for Max-Forwards.
    18281828               </p>
    18291829               <p id="rfc.section.5.1.2.p.5">A recipient <em class="bcp14">MAY</em> ignore a Max-Forwards header field received with any other request methods.
     
    21052105               <p id="rfc.section.5.3.5.p.6">A request without any Accept-Language header field implies that the user agent will accept any language in response. If the
    21062106                  header field is present in a request and none of the available representations for the response have a matching language tag,
    2107                   the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation,
     2107                  the origin server can either disregard the header field by treating the response as if it is not subject to content negotiation
    21082108                  or honor the header field by sending a <a href="#status.406" class="smpl">406 (Not Acceptable)</a> response. However, the latter is not encouraged, as doing so can prevent users from accessing content that they might be able
    21092109                  to use (with translation software, for example).
     
    21212121               </p>
    21222122               <p id="rfc.section.5.3.5.p.10">Since intelligibility is highly dependent on the individual user, user agents need to allow user control over the linguistic
    2123                   preference (either through configuration of the user agent itself, or by defaulting to a user controllable system setting).
     2123                  preference (either through configuration of the user agent itself or by defaulting to a user controllable system setting).
    21242124                  A user agent that does not provide such control to the user <em class="bcp14">MUST NOT</em> send an Accept-Language header field.
    21252125               </p>
     
    25282528            <div id="rfc.iref.s.3"></div>
    25292529            <p id="rfc.section.6.2.p.1">The <dfn>1xx (Informational)</dfn> class of status code indicates an interim response for communicating connection status or request progress prior to completing
    2530                the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields,
    2531                and thus are terminated by the empty line at the end of the header section. Since HTTP/1.0 did not define any 1xx status codes,
    2532                a server <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client.
     2530               the requested action and sending a final response. All 1xx responses consist of only the status-line and optional header fields
     2531               and, thus, are terminated by the empty line at the end of the header section. Since HTTP/1.0 did not define any 1xx status
     2532               codes, a server <em class="bcp14">MUST NOT</em> send a 1xx response to an HTTP/1.0 client.
    25332533            </p>
    25342534            <p id="rfc.section.6.2.p.2">A client <em class="bcp14">MUST</em> be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. A user
     
    27772777               <p id="rfc.section.6.4.4.p.2">This status code is applicable to any HTTP method. It is primarily used to allow the output of a POST action to redirect the
    27782778                  user agent to a selected resource, since doing so provides the information corresponding to the POST response in a form that
    2779                   can be separately identified, bookmarked, and cached independent of the original request.
     2779                  can be separately identified, bookmarked, and cached, independent of the original request.
    27802780               </p>
    27812781               <p id="rfc.section.6.4.4.p.3">A 303 response to a GET request indicates that the origin server does not have a representation of the <a href="#resources" class="smpl">target resource</a> that can be transferred by the server over HTTP. However, the <a href="#header.location" class="smpl">Location</a> field value refers to a resource that is descriptive of the target resource, such that making a retrieval request on that
     
    29342934               <p id="rfc.section.6.5.12.p.1">The <dfn>414 (URI Too Long)</dfn> status code indicates that the server is refusing to service the request because the request-target (<a href="p1-messaging.html#request-target" title="Request Target">Section 5.3</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.28"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>) is longer than the server is willing to interpret. This rare condition is only likely to occur when a client has improperly
    29352935                  converted a POST request to a GET request with long query information, when the client has descended into a "black hole" of
    2936                   redirection (e.g., a redirected URI prefix that points to a suffix of itself), or when the server is under attack by a client
     2936                  redirection (e.g., a redirected URI prefix that points to a suffix of itself) or when the server is under attack by a client
    29372937                  attempting to exploit potential security holes.
    29382938               </p>
     
    34643464                  under what conditions, a cache can store a response and use it to satisfy a subsequent request. The new method ought to describe
    34653465                  whether it can be made conditional (<a href="#request.conditionals" title="Conditionals">Section&nbsp;5.2</a>) and, if so, how a server responds when the condition is false. Likewise, if the new method might have some use for partial
    3466                   response semantics (<a href="#RFC7233" id="rfc.xref.RFC7233.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>), it ought to document this too.
     3466                  response semantics (<a href="#RFC7233" id="rfc.xref.RFC7233.11"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Range Requests">[RFC7233]</cite></a>), it ought to document this, too.
    34673467               </p>
    34683468               <div class="note" id="rfc.section.8.1.2.p.4">
     
    38713871               <ul>
    38723872                  <li>
    3873                      <p>Whether the field is a single value, or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).
     3873                     <p>Whether the field is a single value or whether it can be a list (delimited by commas; see <a href="p1-messaging.html#header.fields" title="Header Fields">Section 3.2</a> of <a href="#RFC7230" id="rfc.xref.RFC7230.37"><cite title="Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing">[RFC7230]</cite></a>).
    38743874                     </p>
    38753875                     <p>If it does not use the list syntax, document how to treat messages where the field occurs multiple times (a sensible default
     
    41374137            <p id="rfc.section.9.1.p.1">Origin servers frequently make use of their local file system to manage the mapping from effective request URI to resource
    41384138               representations. Implementers need to be aware that most file systems are not designed to protect against malicious file or
    4139                path names, and thus depend on the origin server to avoid mapping to file names, folders, or directories that have special
     4139               path names and, thus, depend on the origin server to avoid mapping to file names, folders, or directories that have special
    41404140               significance to the system.
    41414141            </p>
Note: See TracChangeset for help on using the changeset viewer.