Ignore:
Timestamp:
07/05/14 15:47:43 (6 years ago)
Author:
julian.reschke@…
Message:

expand a few status code mentions (#553)

File:
1 edited

Legend:

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

    r2654 r2655  
    633633
    634634
    635 Section 4.3.3., paragraph 6:
    636 OLD:
    637 
    638     An origin server indicates response semantics by choosing an
    639     appropriate status code depending on the result of processing the
    640     POST request; almost all of the status codes defined by this
    641     specification might be received in a response to POST (the exceptions
    642     being 206, 304, and 416).
    643 
    644 NEW:
    645 
    646     An origin server indicates response semantics by choosing an
    647     appropriate status code depending on the result of processing the
    648     POST request; almost all of the status codes defined by this
    649     specification might be received in a response to POST (the exceptions
    650     being 206 (Partial Content), 304 (Not Modified), and 416 (Range Not
    651     Satisfiable)).
    652 
    653 
    654 Section 4.3.6., paragraph 2:
    655 OLD:
    656 
    657     CONNECT is intended only for use in requests to a proxy.  An origin
    658     server that receives a CONNECT request for itself MAY respond with a
    659     2xx status code to indicate that a connection is established.
    660     However, most origin servers do not implement CONNECT.
    661 
    662 NEW:
    663 
    664     CONNECT is intended only for use in requests to a proxy.  An origin
    665     server that receives a CONNECT request for itself MAY respond with a
    666     2xx (Successful) status code to indicate that a connection is
    667     established.  However, most origin servers do not implement CONNECT.
    668 
    669 
    670 Section 4.3.8., paragraph 2:
    671 OLD:
    672 
    673     A client MUST NOT generate header fields in a TRACE request
    674     containing sensitive data that might be disclosed by the response.
    675  
    676     For example, it would be foolish for a user agent to send stored user
    677     credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
    678     final recipient of the request SHOULD exclude any request header
    679     fields that are likely to contain sensitive data when that recipient
    680     generates the response body.
    681 
    682 NEW:
    683 
    684     A client MUST NOT generate header fields in a TRACE request
    685     containing sensitive data that might be disclosed by the response.
    686     For example, it would be foolish for a user agent to send stored user
    687     credentials [RFC7235] or cookies [RFC6265] in a TRACE request.  The
    688     final recipient of the request SHOULD exclude any request header
    689     fields that are likely to contain sensitive data when that recipient
    690     generates the response body.
    691 
    692 
    693635Section 5.1.1., paragraph 3:
    694636OLD:
     
    699641
    700642    The Expect field-value is case insensitive.
    701 
    702 
    703 Section 5.1.1., paragraph 21:
    704 OLD:
    705 
    706        Note: The Expect header field was added after the original
    707        publication of HTTP/1.1 [RFC2068] as both the means to request an
    708        interim 100 response and the general mechanism for indicating
    709        must-understand extensions.  However, the extension mechanism has
    710        not been used by clients and the must-understand requirements have
    711        not been implemented by many servers, rendering the extension
    712        mechanism useless.  This specification has removed the extension
    713        mechanism in order to simplify the definition and processing of
    714        100-continue.
    715 
    716 NEW:
    717 
    718        Note: The Expect header field was added after the original
    719        publication of HTTP/1.1 [RFC2068] as both the means to request an
    720        interim 100 (Continue) response and the general mechanism for
    721        indicating must-understand extensions.  However, the extension
    722        mechanism has not been used by clients and the must-understand
    723        requirements have not been implemented by many servers, rendering
    724        the extension mechanism useless.  This specification has removed
    725        the extension mechanism in order to simplify the definition and
    726        processing of 100-continue.
    727643
    728644
     
    823739    that identified user agent, even if they might not work as well for
    824740    the actual user agent being implemented.
    825 
    826 
    827 Section 6., paragraph 3:
    828 OLD:
    829 
    830     For example, if an unrecognized status code of 471 is received by a
    831     client, the client can assume that there was something wrong with its
    832     request and treat the response as if it had received a 400 status
    833     code.  The response message will usually contain a representation
    834     that explains the status.
    835 
    836 NEW:
    837 
    838     For example, if an unrecognized status code of 471 is received by a
    839     client, the client can assume that there was something wrong with its
    840     request and treat the response as if it had received a 400 (Bad
    841     Request) status code.  The response message will usually contain a
    842     representation that explains the status.
    843741
    844742
     
    1033931        additional parameters are provided in the listed header fields
    1034932        (proactive negotiation).
    1035 
    1036 
    1037 Section 7.2., paragraph 3:
    1038 OLD:
    1039 
    1040     For example, an ETag header field in a 201 response communicates the
    1041     entity-tag of the newly created resource's representation, so that it
    1042     can be used in later conditional requests to prevent the "lost
    1043     update" problem [RFC7232].
    1044 
    1045 NEW:
    1046 
    1047     For example, an ETag header field in a 201 (Created) response
    1048     communicates the entity-tag of the newly created resource's
    1049     representation, so that it can be used in later conditional requests
    1050     to prevent the "lost update" problem [RFC7232].
    1051933
    1052934
Note: See TracChangeset for help on using the changeset viewer.