Ignore:
Timestamp:
06/05/14 16:20:31 (6 years ago)
Author:
julian.reschke@…
Message:

mainly grammatical fixes (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/p2-semantics.unpg.txt

    r2645 r2647  
    294294   relation to the identified request target, and responds to that
    295295   request with one or more response messages.  A client constructs
    296    request messages to communicate specific intentions, and examines
     296   request messages to communicate specific intentions, examines
    297297   received responses to see if the intentions were carried out, and
    298    determine how to interpret the results.  This document defines
     298   determines how to interpret the results.  This document defines
    299299   HTTP/1.1 request and response semantics in terms of the architecture
    300300   defined in [RFC7230].
     
    385385   potentially unbounded stream of representation data.
    386386
    387    An origin server might be provided with, or capable of generating,
     387   An origin server might be provided with, or be capable of generating,
    388388   multiple representations that are each intended to reflect the
    389389   current state of a target resource.  In such cases, some algorithm is
     
    461461
    462462   A parameter value that matches the token production can be
    463    transmitted as either a token or within a quoted-string.  The quoted
     463   transmitted either as a token or within a quoted-string.  The quoted
    464464   and unquoted values are equivalent.  For example, the following
    465465   examples are all equivalent, but the first is preferred for
     
    486486     charset = token
    487487
    488    Charset names ought to be registered in IANA Character Set registry
    489    (<http://www.iana.org/assignments/character-sets>) according to the
    490    procedures defined in [RFC2978].
     488   Charset names ought to be registered in the IANA Character Set
     489   registry (<http://www.iana.org/assignments/character-sets>) according
     490   to the procedures defined in [RFC2978].
    491491
    4924923.1.1.3.  Canonicalization and Text Defaults
     
    15551555   reflects the new representation.  This requirement allows a user
    15561556   agent to know when the representation body it has in memory remains
    1557    current as a result of the PUT, thus not in need of retrieving again
    1558    from the origin server, and that the new validator(s) received in the
    1559    response can be used for future conditional requests in order to
    1560    prevent accidental overwrites (Section 5.2).
     1557   current as a result of the PUT, thus not in need of being retrieved
     1558   again from the origin server, and that the new validator(s) received
     1559   in the response can be used for future conditional requests in order
     1560   to prevent accidental overwrites (Section 5.2).
    15611561
    15621562   The fundamental difference between the POST and PUT methods is
     
    17511751
    17521752   The OPTIONS method requests information about the communication
    1753    options available for the target resource, either at the origin
     1753   options available for the target resource, at either the origin
    17541754   server or an intervening intermediary.  This method allows a client
    17551755   to determine the options and/or requirements associated with a
     
    26012601   identifier.  A sender SHOULD NOT generate information in product-
    26022602   version that is not a version identifier (i.e., successive versions
    2603    of the same product name ought to only differ in the product-version
     2603   of the same product name ought only to differ in the product-version
    26042604   portion of the product identifier).
    26052605
     
    32843284
    32853285   The 400 (Bad Request) status code indicates that the server cannot or
    3286    will not process the request due to something which is perceived to
    3287    be a client error (e.g., malformed request syntax, invalid request
     3286   will not process the request due to something that is perceived to be
     3287   a client error (e.g., malformed request syntax, invalid request
    32883288   message framing, or deceptive request routing).
    32893289
     
    38783878
    38793879
    3880    If the Location value provided in a 3xx (Redirection) does not have a
    3881    fragment component, a user agent MUST process the redirection as if
    3882    the value inherits the fragment component of the URI reference used
    3883    to generate the request target (i.e., the redirection inherits the
    3884    original reference's fragment, if any).
     3880   If the Location value provided in a 3xx (Redirection) response does
     3881   not have a fragment component, a user agent MUST process the
     3882   redirection as if the value inherits the fragment component of the
     3883   URI reference used to generate the request target (i.e., the
     3884   redirection inherits the original reference's fragment, if any).
    38853885
    38863886   For example, a GET request generated for the URI reference
     
    42524252   maintained at <http://www.iana.org/assignments/http-status-codes>.
    42534253
    4254    This Section replaces the registration procedure for HTTP Status
     4254   This section replaces the registration procedure for HTTP Status
    42554255   Codes previously defined in Section 7.1 of [RFC2817].
    42564256
     
    44014401
    44024402   Authors of specifications defining new fields are advised to keep the
    4403    name as short as practical and to not prefix the name with "X-"
     4403   name as short as practical and not to prefix the name with "X-"
    44044404   unless the header field will never be used on the Internet.  (The
    4405    "x-" prefix idiom has been extensively misused in practice; it was
     4405   "X-" prefix idiom has been extensively misused in practice; it was
    44064406   intended to only be used as a mechanism for avoiding name collisions
    44074407   inside proprietary software or intranet processing, since the prefix
    44084408   would ensure that private names never collide with a newly registered
    4409    Internet name; see [BCP178] for further information)
     4409   Internet name; see [BCP178] for further information).
    44104410
    44114411   New header field values typically have their syntax defined using
     
    46314631   For example, UNIX, Microsoft Windows, and other operating systems use
    46324632   ".." as a path component to indicate a directory level above the
    4633    current one, and use specially named paths or file names to send data
    4634    to system devices.  Similar naming conventions might exist within
    4635    other types of storage systems.  Likewise, local storage systems have
    4636    an annoying tendency to prefer user-friendliness over security when
    4637    handling invalid or unexpected characters, recomposition of
    4638    decomposed characters, and case-normalization of case-insensitive
    4639    names.
     4633   current one, and they use specially named paths or file names to send
     4634   data to system devices.  Similar naming conventions might exist
     4635   within other types of storage systems.  Likewise, local storage
     4636   systems have an annoying tendency to prefer user-friendliness over
     4637   security when handling invalid or unexpected characters,
     4638   recomposition of decomposed characters, and case-normalization of
     4639   case-insensitive names.
    46404640
    46414641   Attacks based on such special names tend to focus on either denial-
     
    49994999   variety of representations and with extensible header fields.
    50005000   However, RFC 2045 is focused only on email; applications of HTTP have
    5001    many characteristics that differ from email, and hence HTTP has
    5002    features that differ from MIME.  These differences were carefully
    5003    chosen to optimize performance over binary connections, to allow
    5004    greater freedom in the use of new media types, to make date
    5005    comparisons easier, and to acknowledge the practice of some early
    5006    HTTP servers and clients.
     5001   many characteristics that differ from email; hence, HTTP has features
     5002   that differ from MIME.  These differences were carefully chosen to
     5003   optimize performance over binary connections, to allow greater
     5004   freedom in the use of new media types, to make date comparisons
     5005   easier, and to acknowledge the practice of some early HTTP servers
     5006   and clients.
    50075007
    50085008   This appendix describes specific areas where HTTP differs from MIME.
Note: See TracChangeset for help on using the changeset viewer.