Ignore:
Timestamp:
19/05/14 13:38:02 (6 years ago)
Author:
julian.reschke@…
Message:

updated AUTH48 version of RFC7231 (#553)

File:
1 edited

Legend:

Unmodified
Added
Removed
  • draft-ietf-httpbis/latest/auth48/rfc7231-to-be.unpg.txt

    r2678 r2682  
    135135     6.3.  Successful 2xx . . . . . . . . . . . . . . . . . . . . . . 51
    136136       6.3.1.  200 OK . . . . . . . . . . . . . . . . . . . . . . . . 51
    137        6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 52
     137       6.3.2.  201 Created  . . . . . . . . . . . . . . . . . . . . . 51
    138138       6.3.3.  202 Accepted . . . . . . . . . . . . . . . . . . . . . 52
    139139       6.3.4.  203 Non-Authoritative Information  . . . . . . . . . . 52
     
    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 only to differ in the product-version
     2603   of the same product name ought to differ only in the product-version
    26042604   portion of the product identifier).
    26052605
     
    28032803   response for communicating connection status or request progress
    28042804   prior to completing the requested action and sending a final
    2805    response.  All 1xx responses consist of only the status-line and
    2806    optional header fields and, thus, are terminated by the empty line at
    2807    the end of the header section.  Since HTTP/1.0 did not define any 1xx
    2808    status codes, a server MUST NOT send a 1xx response to an HTTP/1.0
    2809    client.
     2805   response. 1xx responses are terminated by the first empty line after
     2806   the status-line (the empty line signaling the end of the header
     2807   section).  Since HTTP/1.0 did not define any 1xx status codes, a
     2808   server MUST NOT send a 1xx response to an HTTP/1.0 client.
    28102809
    28112810   A client MUST be able to parse one or more 1xx responses received
     
    28432842   MUST generate an Upgrade header field in the response that indicates
    28442843   which protocol(s) will be switched to immediately after the empty
     2844   line that terminates the 101 response.
    28452845
    28462846
     
    28512851RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    28522852
    2853 
    2854    line that terminates the 101 response.
    28552853
    28562854   It is assumed that the server will only agree to switch protocols
     
    28982896   Section 4.2.2 of [RFC7234]).
    28992897
    2900 
    2901 
    2902 
    2903 
    2904 
    2905 Fielding & Reschke           Standards Track                   [Page 51]
    2906 
    2907 
    2908 RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    2909 
    2910 
    291128986.3.2.  201 Created
    29122899
    29132900   The 201 (Created) status code indicates that the request has been
    29142901   fulfilled and has resulted in one or more new resources being
     2902
     2903
     2904
     2905Fielding & Reschke           Standards Track                   [Page 51]
     2906
     2907
     2908RFC 7231             HTTP/1.1 Semantics and Content             May 2014
     2909
     2910
    29152911   created.  The primary resource created by the request is identified
    29162912   by either a Location header field in the response or, if no Location
     
    29572953
    29582954   A 203 response is cacheable by default; i.e., unless otherwise
    2959 
    2960 
    2961 
    2962 Fielding & Reschke           Standards Track                   [Page 52]
    2963 
    2964 
    2965 RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    2966 
    2967 
    29682955   indicated by the method definition or explicit cache controls (see
    29692956   Section 4.2.2 of [RFC7234]).
     2957
     2958
     2959
     2960
     2961
     2962Fielding & Reschke           Standards Track                   [Page 52]
     2963
     2964
     2965RFC 7231             HTTP/1.1 Semantics and Content             May 2014
     2966
    29702967
    297129686.3.5.  204 No Content
     
    30143011   notepad, canvas, etc.), enters or manipulates data in that space,
    30153012   causes the entered data to be submitted in a request, and then the
    3016 
    3017 
    3018 
    3019 Fielding & Reschke           Standards Track                   [Page 53]
    3020 
    3021 
    3022 RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    3023 
    3024 
    30253013   data entry mechanism is reset for the next entry so that the user can
    30263014   easily initiate another input action.
     3015
     3016
     3017
     3018
     3019Fielding & Reschke           Standards Track                   [Page 53]
     3020
     3021
     3022RFC 7231             HTTP/1.1 Semantics and Content             May 2014
     3023
    30273024
    30283025   Since the 205 status code implies that no additional content will be
     
    30713068      method applied to the redirect target would be the same as the
    30723069      original request or would be rewritten as GET.  Although HTTP
    3073 
    3074 
    3075 
    3076 Fielding & Reschke           Standards Track                   [Page 54]
    3077 
    3078 
    3079 RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    3080 
    3081 
    30823070      originally defined the former semantics for 301 and 302 (to match
    30833071      its original implementation at CERN), and defined 303 (See Other)
    30843072      to match the latter semantics, prevailing practice gradually
     3073
     3074
     3075
     3076Fielding & Reschke           Standards Track                   [Page 54]
     3077
     3078
     3079RFC 7231             HTTP/1.1 Semantics and Content             May 2014
     3080
     3081
    30853082      converged on the latter semantics for 301 and 302 as well.  The
    30863083      first revision of HTTP/1.1 added 307 (Temporary Redirect) to
     
    31283125   A 300 response is cacheable by default; i.e., unless otherwise
    31293126   indicated by the method definition or explicit cache controls (see
     3127   Section 4.2.2 of [RFC7234]).
     3128
     3129
    31303130
    31313131
     
    31363136RFC 7231             HTTP/1.1 Semantics and Content             May 2014
    31373137
    3138 
    3139    Section 4.2.2 of [RFC7234]).
    31403138
    31413139      Note: The original proposal for the 300 status code defined the
     
    31853183   response payload usually contains a short hypertext note with a
    31863184   hyperlink to the different URI(s).
     3185
     3186
    31873187
    31883188
     
    46234623   Origin servers frequently make use of their local file system to
    46244624   manage the mapping from effective request URI to resource
    4625    representations.  Implementers need to be aware that most file
    4626    systems are not designed to protect against malicious file or path
    4627    names and, thus, depend on the origin server to avoid mapping to file
    4628    names, folders, or directories that have special significance to the
    4629    system.
     4625   representations.  Most file systems are not designed to protect
     4626   against malicious file or path names.  Therefore, an origin server
     4627   needs to avoid accessing names that have a special significance to
     4628   the system when mapping the request target to files, folders, or
     4629   directories.
    46304630
    46314631   For example, UNIX, Microsoft Windows, and other operating systems use
     
    54575457   2
    54585458      200 OK (status code)  51
    5459       201 Created (status code)  52
     5459      201 Created (status code)  51
    54605460      202 Accepted (status code)  52
    54615461      203 Non-Authoritative Information (status code)  52
Note: See TracChangeset for help on using the changeset viewer.