Ignore:
Timestamp:
08/05/14 13:46:33 (6 years ago)
Author:
julian.reschke@…
Message:

min. fixes (reg names, punctuation, etc) (see #553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7231.abdiff.txt

    r2659 r2660  
    493493
    494494    All content-coding values are case-insensitive and ought to be
    495     registered within the HTTP Content Coding registry, as defined in
     495    registered within the "HTTP Content Coding Registry", as defined in
    496496    Section 8.4.  They are used in the Accept-Encoding (Section 5.3.4)
    497497    and Content-Encoding (Section 3.1.2.2) header fields.
     
    608608    Additional methods, outside the scope of this specification, have
    609609    been standardized for use in HTTP.  All such methods ought to be
    610     registered within the HTTP Method Registry maintained by IANA, as
    611     defined in Section 8.1.
     610    registered within the "Hypertext Transfer Protocol (HTTP) Method
     611    Registry" maintained by IANA, as defined in Section 8.1.
    612612
    613613NEW:
     
    623623
    624624    This definition of safe methods does not prevent an implementation
    625     from including behavior that is potentially harmful, not entirely
    626     read-only, or which causes side effects while invoking a safe method.
    627     What is important, however, is that the client did not request that
    628     additional behavior and cannot be held accountable for it.  For
    629     example, most servers append request information to access log files
    630     at the completion of every response, regardless of the method, and
    631     that is considered safe even though the log storage might become full
    632     and crash the server.  Likewise, a safe request initiated by
    633     selecting an advertisement on the Web will often have the side effect
    634     of charging an advertising account.
     625    from including behavior that is potentially harmful, that is not
     626    entirely read-only, or that causes side effects while invoking a safe
     627    method.  What is important, however, is that the client did not
     628    request that additional behavior and cannot be held accountable for
     629    it.  For example, most servers append request information to access
     630    log files at the completion of every response, regardless of the
     631    method, and that is considered safe even though the log storage might
     632    become full and crash the server.  Likewise, a safe request initiated
     633    by selecting an advertisement on the Web will often have the side
     634    effect of charging an advertising account.
    635635
    636636NEW:
     
    757757
    758758
    759 Section 6.1., paragraph 2:
    760 OLD:
    761 
    762     Responses with status codes that are defined as cacheable by default
    763     (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, 501 in this
    764     specification) can be reused by a cache with heuristic expiration
    765     unless otherwise indicated by the method definition or explicit cache
    766     controls [RFC7234]; all other status codes are not cacheable by
    767     default.
    768 
    769 NEW:
    770 
    771     Responses with status codes that are defined as cacheable by default
    772     (e.g., 200, 203, 204, 206, 300, 301, 404, 405, 410, 414, and 501 in
    773     this specification) can be reused by a cache with heuristic
    774     expiration unless otherwise indicated by the method definition or
    775     explicit cache controls [RFC7234]; all other status codes are not
    776     cacheable by default.
    777 
    778 
    779759Section 6.4.1., paragraph 5:
    780760OLD:
    781761
    782        Note: The original proposal for 300 defined the URI header field
    783        as providing a list of alternative representations, such that it
    784        would be usable for 200, 300, and 406 responses and be transferred
    785        in responses to the HEAD method.  However, lack of deployment and
    786        disagreement over syntax led to both URI and Alternates (a
    787        subsequent proposal) being dropped from this specification.  It is
    788        possible to communicate the list using a set of Link header fields
    789        [RFC5988], each with a relationship of "alternate", though
    790        deployment is a chicken-and-egg problem.
     762       Note: The original proposal for the 300 status code defined the
     763       URI header field as providing a list of alternative
     764       representations, such that it would be usable for 200, 300, and
     765       406 responses and be transferred in responses to the HEAD method.
     766       However, lack of deployment and disagreement over syntax led to
     767       both URI and Alternates (a subsequent proposal) being dropped from
     768       this specification.  It is possible to communicate the list using
     769       a set of Link header fields [RFC5988], each with a relationship of
     770       "alternate", though deployment is a chicken-and-egg problem.
    791771
    792772NEW:
     
    993973    (Section 4.2.1), idempotent (Section 4.2.2), cacheable
    994974    (Section 4.2.3), what semantics are to be associated with the payload
    995     body if any is present in the request, and what refinements the
    996     method makes to header field or status code semantics.  If the new
    997     method is cacheable, its definition ought to describe how, and under
    998     what conditions, a cache can store a response and use it to satisfy a
     975    body if any is present in the request and what refinements the method
     976    makes to header field or status code semantics.  If the new method is
     977    cacheable, its definition ought to describe how, and under what
     978    conditions, a cache can store a response and use it to satisfy a
    999979    subsequent request.  The new method ought to describe whether it can
    1000980    be made conditional (Section 5.2) and, if so, how a server responds
     
    11701150
    11711151
    1172 Section 9.4., paragraph 3:
    1173 OLD:
    1174 
    1175     Since the Referer header field tells a target site about the context
    1176     that resulted in a request, it has the potential to reveal
    1177     information about the user's immediate browsing history and any
    1178     personal information that might be found in the referring resource's
    1179     URI.  Limitations on Referer are described in Section 5.5.2 to
    1180     address some of its security considerations.
    1181 
    1182 NEW:
    1183 
    1184     Since the Referer header field tells a target site about the context
    1185     that resulted in a request, it has the potential to reveal
    1186     information about the user's immediate browsing history and any
    1187     personal information that might be found in the referring resource's
    1188     URI.  Limitations on the Referer header field are described in
    1189     Section 5.5.2 to address some of its security considerations.
    1190 
    1191 
    11921152Section 11.1., paragraph 9:
    11931153OLD:
     
    13171277OLD:
    13181278
    1319     A new requirement has been added that semantics embedded in a URI
    1320     should be disabled when those semantics are inconsistent with the
    1321     request method, since this is a common cause of interoperability
    1322     failure.  (Section 2)
     1279    A new requirement has been added that semantics embedded in a URI be
     1280    disabled when those semantics are inconsistent with the request
     1281    method, since this is a common cause of interoperability failure.
     1282 
     1283    (Section 2)
    13231284
    13241285NEW:
Note: See TracChangeset for help on using the changeset viewer.