Changeset 2665


Ignore:
Timestamp:
May 9, 2014, 7:39:08 AM (6 years ago)
Author:
julian.reschke@…
Message:

updated AUTH48 versions of RFC7230 and RFC7231 (#553)

Location:
draft-ietf-httpbis/latest/auth48
Files:
8 edited

Legend:

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

    r2631 r2665  
    9595       3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
    9696       3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
    97        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
     97       3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 24
    9898       3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
    9999       3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
    100100     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
    101101       3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
    102        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
     102       3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 29
    103103       3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
    104104     3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
    105105     3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
    106    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
     106   4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34
    107107     4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
    108108       4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
     
    118118       4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
    119119       4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
    120      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
     120     4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 37
    121121       4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
    122122       4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
     
    124124     4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
    125125     4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
    126    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
     126   5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 39
    127127     5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
    128128     5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
    129129     5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
    130130       5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
    131        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
     131       5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 41
    132132       5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
    133133       5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
     
    136136     5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
    137137     5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
    138        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
     138       5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 46
    139139       5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
    140140   6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
    141141     6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
    142142     6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
    143      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
    144        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
     143     6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 51
     144       6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
    145145       6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
    146146     6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
    147147     6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
    148      6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
     148     6.6.  Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
    149149     6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
    150150   7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
    151    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
    152      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
     151   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 59
     152     8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
    153153     8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
    154      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
     154     8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
    155155       8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
    156156       8.3.2.  Internet Media Type application/http . . . . . . . . . 62
     
    159159       8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
    160160     8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
    161      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
     161     8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64
    162162       8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
    163        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
     163       8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
    164164   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
    165165     9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
     
    174174
    175175     9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
    176      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
     176     9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 67
    177177     9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
    178178     9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
    179179     9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
    180      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
     180     9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
    181181     9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
    182    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
     182   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
    183183   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
    184184     11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
    185      11.2. Informative References . . . . . . . . . . . . . . . . . . 74
    186    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
     185     11.2. Informative References . . . . . . . . . . . . . . . . . . 73
     186   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
    187187     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
    188        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
    189        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
    190        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
    191      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
    192    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
     188       A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 76
     189       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 76
     190       A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
     191     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
     192   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 79
    193193   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
    194194
     
    239239   specification:
    240240
    241       RFC 7230: Message Syntax and Routing
    242 
    243       RFC 7231: Semantics and Content
    244 
    245       RFC 7232: Conditional Requests
    246 
    247       RFC 7233: Range Requests
    248 
    249       RFC 7234: Caching
    250 
    251       RFC 7235: Authentication
    252 
    253    This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
    254    HTTP versioning).  This specification also updates the use of
    255    CONNECT, previously defined in RFC 2817, to establish a tunnel, and
    256    defines the "https" URI scheme that was described informally in RFC
    257    2818.
     241   1.  "Message Syntax and Routing" (this document)
     242
     243   2.  "Semantics and Content" [RFC7231]
     244
     245   3.  "Conditional Requests" [RFC7232]
     246
     247   4.  "Range Requests" [RFC7233]
     248
     249   5.  "Caching" [RFC7234]
     250
     251   6.  "Authentication" [RFC7235]
     252
     253   This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
     254   versioning).  This specification also updates the use of CONNECT to
     255   establish a tunnel, previously defined in RFC 2817, and defines the
     256   "https" URI scheme that was described informally in RFC 2818.
    258257
    259258   HTTP is a generic interface protocol for information systems.  It is
     
    278277   are limited to defining the syntax of communication, the intent of
    279278   received communication, and the expected behavior of recipients.  If
     279   the communication is considered in isolation, then successful actions
    280280
    281281
     
    287287
    288288
    289    the communication is considered in isolation, then successful actions
    290289   ought to be reflected in corresponding changes to the observable
    291290   interface provided by servers.  However, since multiple clients might
     
    335334   evolved over time to support the scalability needs of a worldwide
    336335   hypertext system.  Much of that architecture is reflected in the
     336   terminology and syntax productions used to define HTTP.
    337337
    338338
     
    343343RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    344344
    345 
    346    terminology and syntax productions used to define HTTP.
    347345
    3483462.1.  Client/Server Messaging
     
    392390   body (if any, Section 3.3).
    393391
    394 
    395 
    396 
    397 Fielding & Reschke           Standards Track                    [Page 7]
    398 
    399 
    400 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    401 
    402 
    403392   A server responds to a client's request by sending one or more HTTP
    404393   response messages, each beginning with a status line that includes
     394
     395
     396
     397Fielding & Reschke           Standards Track                    [Page 7]
     398
     399
     400RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     401
     402
    405403   the protocol version, a success or error code, and textual reason
    406404   phrase (Section 3.1.2), possibly followed by header fields containing
     
    449447   sizes.  Likewise, common HTTP origin servers include home automation
    450448   units, configurable networking components, office machines,
    451 
    452 
    453 
    454 Fielding & Reschke           Standards Track                    [Page 8]
    455 
    456 
    457 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    458 
    459 
    460449   autonomous robots, news feeds, traffic cameras, ad selectors, and
    461450   video-delivery platforms.
     451
     452
     453
     454Fielding & Reschke           Standards Track                    [Page 8]
     455
     456
     457RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     458
    462459
    463460   The term "user agent" does not imply that there is a human user
     
    506503   request.  Likewise, later requests might be sent through a different
    507504   path of connections, often based on dynamic configuration for load
     505   balancing.
     506
     507   The terms "upstream" and "downstream" are used to describe
    508508
    509509
     
    515515
    516516
    517    balancing.
    518 
    519    The terms "upstream" and "downstream" are used to describe
    520517   directional requirements in relation to the message flow: all
    521518   messages flow from upstream to downstream.  The terms "inbound" and
     
    550547   extensions to HTTP that are outside the scope of this specification.
    551548   However, an HTTP-to-HTTP gateway that wishes to interoperate with
    552    third-party HTTP servers ought to conform to user-agent requirements
     549   third-party HTTP servers ought to conform to user agent requirements
    553550   on the gateway's inbound connection.
    554551
     
    563560
    564561   The above categories for intermediary only consider those acting as
    565 
    566 
    567 
    568 Fielding & Reschke           Standards Track                   [Page 10]
    569 
    570 
    571 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    572 
    573 
    574562   participants in the HTTP communication.  There are also
    575563   intermediaries that can act on lower layers of the network protocol
    576564   stack, filtering or redirecting HTTP traffic without the knowledge or
     565
     566
     567
     568Fielding & Reschke           Standards Track                   [Page 10]
     569
     570
     571RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     572
     573
    577574   permission of message senders.  Network intermediaries are
    578575   indistinguishable (at a protocol level) from a man-in-the-middle
     
    620617
    621618   A response is "cacheable" if a cache is allowed to store a copy of
    622 
    623 
    624 
    625 Fielding & Reschke           Standards Track                   [Page 11]
    626 
    627 
    628 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    629 
    630 
    631619   the response message for use in answering subsequent requests.  Even
    632620   when a response is cacheable, there might be additional constraints
    633621   placed by the client or by the origin server on when that cached
     622
     623
     624
     625Fielding & Reschke           Standards Track                   [Page 11]
     626
     627
     628RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     629
     630
    634631   response can be used for a particular request.  HTTP requirements for
    635632   cache behavior and cacheable responses are defined in Section 2 of
     
    677674   forwarding a message might parse a header-field into generic field-
    678675   name and field-value components, but then forward the header field
     676   without further parsing inside the field-value.
     677
     678   HTTP does not have specific length limitations for many of its
    679679
    680680
     
    686686
    687687
    688    without further parsing inside the field-value.
    689 
    690    HTTP does not have specific length limitations for many of its
    691688   protocol elements because the lengths that might be appropriate will
    692689   vary widely, depending on the deployment context and purpose of the
     
    734731
    735732   The version of an HTTP message is indicated by an HTTP-version field
     733   in the first line of the message.  HTTP-version is case-sensitive.
     734
     735     HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
    736736
    737737
     
    743743
    744744
    745    in the first line of the message.  HTTP-version is case sensitive.
    746 
    747      HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
    748      HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
     745     HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
    749746
    750747   The HTTP version number consists of two decimal digits separated by a
     
    778775   New header fields can be introduced without changing the protocol
    779776   version if their defined semantics allow them to be safely ignored by
    780    recipients that do not recognize them.  Header-field extensibility is
     777   recipients that do not recognize them.  Header field extensibility is
    781778   discussed in Section 3.2.1.
    782779
     
    792789   features are safe to use for later communication with that sender.
    793790
    794 
    795 
    796 Fielding & Reschke           Standards Track                   [Page 14]
    797 
    798 
    799 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    800 
    801 
    802791   A client SHOULD send a request version equal to the highest version
    803792   to which the client is conformant and whose major version is no
     793
     794
     795
     796Fielding & Reschke           Standards Track                   [Page 14]
     797
     798
     799RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     800
     801
    804802   higher than the highest version supported by the server, if this is
    805803   known.  A client MUST NOT send a version to which it is not
     
    846844   message with a higher minor version, when sent to a recipient that
    847845   has not yet indicated support for that higher version, is
    848    sufficiently backwards compatible to be safely processed by any
     846   sufficiently backwards-compatible to be safely processed by any
    849847   implementation of the same major version.
     848
     849
    850850
    851851
     
    902902   identifiers according to their association with the hierarchical
    903903   namespace governed by a potential HTTP origin server listening for
    904    TCP ([RFC793]) connections on a given port.
     904   TCP ([RFC0793]) connections on a given port.
    905905
    906906     http-URI = "http:" "//" authority path-abempty [ "?" query ]
     
    10421042   path component is equivalent to an absolute path of "/", so the
    10431043   normal form is to provide a path of "/" instead.  The scheme and host
    1044    are case insensitive and normally provided in lowercase; all other
     1044   are case-insensitive and normally provided in lowercase; all other
    10451045   components are compared in a case-sensitive manner.  Characters other
    10461046   than those in the "reserved" set are equivalent to their percent-
     
    11261126   In theory, a client could receive requests and a server could receive
    11271127   responses, distinguishing them by their different start-line formats,
    1128    but, in practice, servers are implemented only to expect a request (a
     1128   but, in practice, servers are implemented to only expect a request (a
    11291129   response is interpreted as an unknown or invalid request method) and
    11301130   clients are implemented to only expect a response.
     
    114411443.1.1.  Request Line
    11451145
    1146    A request-line begins with a method token and is followed by a single
    1147    space (SP), the request-target, another single space (SP), the
    1148    protocol version, and ends with CRLF.
     1146   A request-line begins with a method token, followed by a single space
     1147   (SP), the request-target, another single space (SP), the protocol
     1148   version, and ends with CRLF.
    11491149
    11501150     request-line   = method SP request-target SP HTTP-version CRLF
    11511151
    11521152   The method token indicates the request method to be performed on the
    1153    target resource.  The request method is case sensitive.
     1153   target resource.  The request method is case-sensitive.
    11541154
    11551155     method         = token
     
    12021202
    12031203   The first line of a response message is the status-line, consisting
    1204    of the protocol version, a space (SP), the status code, another space
    1205    (SP), a possibly empty textual phrase describing the status code,
    1206    and, finally, CRLF.
     1204   of the protocol version, a space (SP), the status code, another
     1205   space, a possibly empty textual phrase describing the status code,
     1206   and ending with CRLF.
    12071207
    12081208     status-line = HTTP-version SP status-code SP reason-phrase CRLF
     
    12811281
    12821282   All defined header fields ought to be registered with IANA in the
    1283    "Message Headers" field registry, as described in Section 8.3 of
    1284    [RFC7231].
     1283   "Message Headers" registry, as described in Section 8.3 of [RFC7231].
    12851284
    128612853.2.2.  Field Order
     
    13041303   name into one "field-name: field-value" pair, without changing the
    13051304   semantics of the message, by appending each subsequent field value to
     1305   the combined field value in order, separated by a comma.  The order
    13061306
    13071307
     
    13131313
    13141314
    1315    the combined field value in order, separated by a comma.  The order
    13161315   in which header fields with the same field name are received is
    13171316   therefore significant to the interpretation of the combined field
     
    13231322      list syntax, violating the above requirements on multiple header
    13241323      fields with the same name.  Since it cannot be combined into a
    1325       single field-value, recipients ought to handle Set-Cookie as a
     1324      single field-value, recipients ought to handle "Set-Cookie" as a
    13261325      special case while processing header fields.  (See Appendix A.2.3
    13271326      of [Kri2001] for details.)
     
    13571356                    ; "bad" whitespace
    13581357
    1359 
    1360 
    1361 
    1362 
    1363 
    1364 
    1365 
    1366 Fielding & Reschke           Standards Track                   [Page 24]
    1367 
    1368 
    1369 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1370 
    1371 
    137213583.2.4.  Field Parsing
    13731359
     
    13751361   individual header field names.  The contents within a given field
    13761362   value are not parsed until a later stage of message interpretation
     1363
     1364
     1365
     1366Fielding & Reschke           Standards Track                   [Page 24]
     1367
     1368
     1369RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1370
     1371
    13771372   (usually after the message's entire header section has been
    13781373   processed).  Consequently, this specification does not use ABNF rules
    1379    to define each "field-name: field-value" pair, as was done in
     1374   to define each "Field-Name: Field Value" pair, as was done in
    13801375   previous editions.  Instead, this specification uses ABNF rules that
    13811376   are named according to each registered field name, wherein the rule
     
    14181413   A proxy or gateway that receives an obs-fold in a response message
    14191414   that is not within a message/http container MUST either discard the
    1420 
    1421 
    1422 
    1423 Fielding & Reschke           Standards Track                   [Page 25]
    1424 
    1425 
    1426 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1427 
    1428 
    14291415   message and replace it with a 502 (Bad Gateway) response, preferably
    14301416   with a representation explaining that unacceptable line folding was
     
    14331419   message downstream.
    14341420
     1421
     1422
     1423Fielding & Reschke           Standards Track                   [Page 25]
     1424
     1425
     1426RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1427
     1428
    14351429   A user agent that receives an obs-fold in a response message that is
    14361430   not within a message/http container MUST replace each received obs-
     
    14391433
    14401434   Historically, HTTP has allowed field content with text in the
    1441    ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
    1442    through use of [RFC2047] encoding.  In practice, most HTTP header
    1443    field values use only a subset of the US-ASCII charset [USASCII].
    1444    Newly defined header fields SHOULD limit their field values to
    1445    US-ASCII octets.  A recipient SHOULD treat other octets in field
    1446    content (obs-text) as opaque data.
     1435   ISO-8859-charset [ISO-8859-1], supporting other charsets only through
     1436   use of [RFC2047] encoding.  In practice, most HTTP header field
     1437   values use only a subset of the US-ASCII charset [USASCII].  Newly
     1438   defined header fields SHOULD limit their field values to US-ASCII
     1439   octets.  A recipient SHOULD treat other octets in field content
     1440   (obs-text) as opaque data.
    14471441
    144814423.2.5.  Field Limits
     
    14731467   (DQUOTE and "(),/:;<=>?@[\]{}").
    14741468
    1475 
    1476 
    1477 
    1478 
    1479 
    1480 Fielding & Reschke           Standards Track                   [Page 26]
    1481 
    1482 
    1483 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1484 
    1485 
    14861469     token          = 1*tchar
    14871470
     
    14921475
    14931476   A string of text is parsed as a single value if it is quoted using
     1477
     1478
     1479
     1480Fielding & Reschke           Standards Track                   [Page 26]
     1481
     1482
     1483RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1484
     1485
    14941486   double-quote marks.
    14951487
     
    15301522   requests and responses.
    15311523
    1532    The presence of a message body in a request is signaled by a Content-
    1533    Length or Transfer-Encoding header field.  Request message framing is
    1534 
    1535 
    1536 
    1537 Fielding & Reschke           Standards Track                   [Page 27]
    1538 
    1539 
    1540 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1541 
    1542 
    1543    independent of method semantics, even if the method does not define
    1544    any use for a message body.
     1524   The presence of a message body in a request is signaled by a
     1525   "Content-Length" or Transfer-Encoding header field.  Request message
     1526   framing is independent of method semantics, even if the method does
     1527   not define any use for a message body.
    15451528
    15461529   The presence of a message body in a response depends on both the
     
    15491532   of [RFC7231]) never include a message body because the associated
    15501533   response header fields (e.g., Transfer-Encoding, Content-Length,
     1534
     1535
     1536
     1537Fielding & Reschke           Standards Track                   [Page 27]
     1538
     1539
     1540RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1541
     1542
    15511543   etc.), if present, indicate only what their values would have been if
    15521544   the request method had been GET (Section 4.3.1 of [RFC7231]). 2xx
     
    15871579   by closing the connection.
    15881580
    1589 
    1590 
    1591 
    1592 
    1593 
    1594 Fielding & Reschke           Standards Track                   [Page 28]
    1595 
    1596 
    1597 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1598 
    1599 
    16001581   For example,
    16011582
     
    16081589   Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-
    16091590   Encoding is a property of the message, not of the representation, and
     1591
     1592
     1593
     1594Fielding & Reschke           Standards Track                   [Page 28]
     1595
     1596
     1597RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1598
     1599
    16101600   any recipient along the request/response chain MAY decode the
    16111601   received transfer coding(s) or apply additional transfer coding(s) to
     
    16431633   does not understand SHOULD respond with 501 (Not Implemented).
    16441634
    1645 
    1646 
    1647 
    1648 
    1649 
    1650 
    1651 Fielding & Reschke           Standards Track                   [Page 29]
    1652 
    1653 
    1654 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1655 
    1656 
    165716353.3.2.  Content-Length
    16581636
     
    16681646     Content-Length = 1*DIGIT
    16691647
     1648
     1649
     1650
     1651Fielding & Reschke           Standards Track                   [Page 29]
     1652
     1653
     1654RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1655
     1656
    16701657   An example is
    16711658
     
    17031690   [RFC7231]).
    17041691
    1705 
    1706 
    1707 
    1708 Fielding & Reschke           Standards Track                   [Page 30]
    1709 
    1710 
    1711 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1712 
    1713 
    17141692   Aside from the cases defined above, in the absence of Transfer-
    17151693   Encoding, an origin server SHOULD send a Content-Length header field
     
    17241702   numerals and prevent parsing errors due to integer conversion
    17251703   overflows (Section 9.3).
     1704
     1705
     1706
     1707
     1708Fielding & Reschke           Standards Track                   [Page 30]
     1709
     1710
     1711RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1712
    17261713
    17271714   If a message is received that has multiple Content-Length header
     
    17601747   3.  If a Transfer-Encoding header field is present and the chunked
    17611748       transfer coding (Section 4.1) is the final encoding, the message
    1762 
    1763 
    1764 
    1765 Fielding & Reschke           Standards Track                   [Page 31]
    1766 
    1767 
    1768 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1769 
    1770 
    17711749       body length is determined by reading and decoding the chunked
    17721750       data until the transfer coding indicates the data is complete.
     
    17821760
    17831761       If a message is received with both a Transfer-Encoding and a
     1762
     1763
     1764
     1765Fielding & Reschke           Standards Track                   [Page 31]
     1766
     1767
     1768RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1769
     1770
    17841771       Content-Length header field, the Transfer-Encoding overrides the
    17851772       Content-Length.  Such a message might indicate an attempt to
     
    18171804       connection.
    18181805
    1819 
    1820 
    1821 
    1822 Fielding & Reschke           Standards Track                   [Page 32]
    1823 
    1824 
    1825 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1826 
    1827 
    18281806   Since there is no way to distinguish a successfully completed, close-
    18291807   delimited message from a partially received message interrupted by
     
    18391817   valid Content-Length header field if the message body length is known
    18401818   in advance, rather than the chunked transfer coding, since some
     1819
     1820
     1821
     1822Fielding & Reschke           Standards Track                   [Page 32]
     1823
     1824
     1825RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1826
     1827
    18411828   existing services respond to chunked with a 411 (Length Required)
    18421829   status code even though they understand the chunked transfer coding.
     
    18741861
    18751862   If a response terminates in the middle of the header section (before
    1876 
    1877 
    1878 
    1879 Fielding & Reschke           Standards Track                   [Page 33]
    1880 
    1881 
    1882 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1883 
    1884 
    18851863   the empty line is received) and the status code might rely on header
    18861864   fields to convey the full meaning of the response, then the client
     
    18961874   connection and, thus, is considered complete regardless of the number
    18971875   of message body octets received, provided that the header section was
     1876
     1877
     1878
     1879Fielding & Reschke           Standards Track                   [Page 33]
     1880
     1881
     1882RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1883
     1884
    18981885   received intact.
    18991886
     
    19311918   receives a sequence of octets that does not match the HTTP-message
    19321919   grammar aside from the robustness exceptions listed above, the server
    1933 
    1934 
    1935 
    1936 Fielding & Reschke           Standards Track                   [Page 34]
    1937 
    1938 
    1939 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1940 
    1941 
    19421920   SHOULD respond with a 400 (Bad Request) response.
    19431921
     
    19511929   that is being transferred.
    19521930
     1931
     1932
     1933
     1934
     1935
     1936Fielding & Reschke           Standards Track                   [Page 34]
     1937
     1938
     1939RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1940
     1941
    19531942     transfer-coding    = "chunked" ; Section 4.1
    19541943                        / "compress" ; Section 4.2.1
     
    19621951     transfer-parameter = token BWS "=" BWS ( token / quoted-string )
    19631952
    1964    All transfer-coding names are case insensitive and ought to be
    1965    registered within the "HTTP Transfer Coding" registry, as defined in
     1953   All transfer-coding names are case-insensitive and ought to be
     1954   registered within the HTTP Transfer Coding registry, as defined in
    19661955   Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
    19671956   Encoding (Section 3.3.1) header fields.
     
    19891978     chunk-data     = 1*OCTET ; a sequence of chunk-size octets
    19901979
    1991 
    1992 
    1993 Fielding & Reschke           Standards Track                   [Page 35]
    1994 
    1995 
    1996 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    1997 
    1998 
    19991980   The chunk-size field is a string of hex digits indicating the size of
    20001981   the chunk-data in octets.  The chunked transfer coding is complete
     
    20041985   A recipient MUST be able to parse and decode the chunked transfer
    20051986   coding.
     1987
     1988
     1989
     1990
     1991
     1992
     1993Fielding & Reschke           Standards Track                   [Page 35]
     1994
     1995
     1996RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     1997
    20061998
    200719994.1.1.  Chunk Extensions
     
    20452037
    20462038   A sender MUST NOT generate a trailer that contains a field necessary
    2047 
    2048 
    2049 
    2050 Fielding & Reschke           Standards Track                   [Page 36]
    2051 
    2052 
    2053 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2054 
    2055 
    20562039   for message framing (e.g., Transfer-Encoding and Content-Length),
    20572040   routing (e.g., Host), request modifiers (e.g., controls and
     
    20622045
    20632046   When a chunked message containing a non-empty trailer is received,
     2047
     2048
     2049
     2050Fielding & Reschke           Standards Track                   [Page 36]
     2051
     2052
     2053RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2054
     2055
    20642056   the recipient MAY process the fields (aside from those forbidden
    20652057   above) as if they were appended to the message's header section.  A
     
    21022094     Remove Trailer from existing header fields
    21032095
    2104 
    2105 
    2106 
    2107 Fielding & Reschke           Standards Track                   [Page 37]
    2108 
    2109 
    2110 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2111 
    2112 
    211320964.2.  Compression Codings
    21142097
    21152098   The codings defined below can be used to compress the payload of a
    21162099   message.
     2100
     2101
     2102
     2103
     2104
     2105
     2106
     2107Fielding & Reschke           Standards Track                   [Page 37]
     2108
     2109
     2110RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2111
    21172112
    211821134.2.1.  Compress Coding
     
    21602155   Three examples of TE use are below.
    21612156
    2162 
    2163 
    2164 Fielding & Reschke           Standards Track                   [Page 38]
    2165 
    2166 
    2167 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2168 
    2169 
    21702157     TE: deflate
    21712158     TE:
    21722159     TE: trailers, deflate;q=0.5
     2160
     2161
     2162
     2163
     2164Fielding & Reschke           Standards Track                   [Page 38]
     2165
     2166
     2167RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2168
    21732169
    21742170   The presence of the keyword "trailers" indicates that the client is
     
    22132209     Trailer = 1#field-name
    22142210
    2215 
    2216 
    2217 
    2218 
    2219 
    2220 
    2221 Fielding & Reschke           Standards Track                   [Page 39]
    2222 
    2223 
    2224 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2225 
    2226 
    222722115.  Message Routing
    22282212
     
    22322216   response routing follows the same connection chain back to the
    22332217   client.
     2218
     2219
     2220
     2221Fielding & Reschke           Standards Track                   [Page 39]
     2222
     2223
     2224RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2225
    22342226
    223522275.1.  Identifying a Target Resource
     
    22732265   directly to an authority for the target resource.  How that is
    22742266   accomplished is dependent on the target URI scheme and defined by its
    2275 
    2276 
    2277 
    2278 Fielding & Reschke           Standards Track                   [Page 40]
    2279 
    2280 
    2281 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2282 
    2283 
    22842267   associated specification, similar to how this specification defines
    22852268   origin server access for resolution of the "http" (Section 2.7.1) and
     
    22882271   HTTP requirements regarding connection management are defined in
    22892272   Section 6.
     2273
     2274
     2275
     2276
     2277
     2278Fielding & Reschke           Standards Track                   [Page 40]
     2279
     2280
     2281RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2282
    22902283
    229122845.3.  Request Target
     
    23302323   followed by the remainder of the request message.
    23312324
    2332 
    2333 
    2334 
    2335 Fielding & Reschke           Standards Track                   [Page 41]
    2336 
    2337 
    2338 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2339 
    2340 
    234123255.3.2.  absolute-form
    23422326
     
    23462330
    23472331     absolute-form  = absolute-URI
     2332
     2333
     2334
     2335Fielding & Reschke           Standards Track                   [Page 41]
     2336
     2337
     2338RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2339
    23482340
    23492341   The proxy is requested to either service that request from a valid
     
    23872379   send only "*" (%x2A) as the request-target.  For example,
    23882380
    2389 
    2390 
    2391 
    2392 Fielding & Reschke           Standards Track                   [Page 42]
    2393 
    2394 
    2395 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2396 
    2397 
    23982381     OPTIONS * HTTP/1.1
    23992382
     
    24032386   request-target of "*" when it forwards the request to the indicated
    24042387   origin server.
     2388
     2389
     2390
     2391
     2392Fielding & Reschke           Standards Track                   [Page 42]
     2393
     2394
     2395RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2396
    24052397
    24062398   For example, the request
     
    24442436   A client MUST send a Host header field in an HTTP/1.1 request even if
    24452437   the request-target is in the absolute-form, since this allows the
    2446 
    2447 
    2448 
    2449 Fielding & Reschke           Standards Track                   [Page 43]
    2450 
    2451 
    2452 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2453 
    2454 
    24552438   Host information to be forwarded through ancient HTTP/1.0 proxies
    24562439   that might not have implemented Host.
     
    24612444   target.  A proxy that forwards such a request MUST generate a new
    24622445   Host field-value based on the received request-target rather than
     2446
     2447
     2448
     2449Fielding & Reschke           Standards Track                   [Page 43]
     2450
     2451
     2452RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2453
     2454
    24632455   forward the received Host field-value.
    24642456
     
    25012493      fixed URI authority component, that authority is used for the
    25022494      effective request URI.  If not, then if the request-target is in
    2503 
    2504 
    2505 
    2506 Fielding & Reschke           Standards Track                   [Page 44]
    2507 
    2508 
    2509 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2510 
    2511 
    25122495      authority-form, the effective request URI's authority component is
    25132496      the same as the request-target.  If not, then if a Host header
     
    25182501      differs from the default port for the effective request URI's
    25192502      scheme, then a colon (":") and the incoming port number (in
     2503
     2504
     2505
     2506Fielding & Reschke           Standards Track                   [Page 44]
     2507
     2508
     2509RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2510
     2511
    25202512      decimal form) are appended to the authority component.
    25212513
     
    25582550   the connection in which the request was received.  For example, the
    25592551   request might have been misdirected, deliberately or accidentally,
    2560 
    2561 
    2562 
    2563 Fielding & Reschke           Standards Track                   [Page 45]
    2564 
    2565 
    2566 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2567 
    2568 
    25692552   such that the information within a received request-target or Host
    25702553   header field differs from the host or port upon which the connection
     
    25742557   non-public content, or poison a cache.  See Section 9 for security
    25752558   considerations regarding message routing.
     2559
     2560
     2561
     2562
     2563Fielding & Reschke           Standards Track                   [Page 45]
     2564
     2565
     2566RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2567
    25762568
    257725695.6.  Associating a Response to a Request
     
    26122604   directly.
    26132605
    2614 
    2615 
    2616 
    2617 
    2618 
    2619 
    2620 Fielding & Reschke           Standards Track                   [Page 46]
    2621 
    2622 
    2623 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2624 
    2625 
    262626065.7.1.  Via
    26272607
     
    26332613   request loops, and identifying the protocol capabilities of senders
    26342614   along the request/response chain.
     2615
     2616
     2617
     2618
     2619
     2620Fielding & Reschke           Standards Track                   [Page 46]
     2621
     2622
     2623RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2624
    26352625
    26362626     Via = 1#( received-protocol RWS received-by [ RWS comment ] )
     
    26722662   A sender MAY generate comments in the Via header field to identify
    26732663   the software of each recipient, analogous to the User-Agent and
    2674 
    2675 
    2676 
    2677 Fielding & Reschke           Standards Track                   [Page 47]
    2678 
    2679 
    2680 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2681 
    2682 
    26832664   Server header fields.  However, all comments in the Via field are
    26842665   optional, and a recipient MAY remove them prior to forwarding the
     
    26912672   www.example.com.  The request received by www.example.com would then
    26922673   have the following Via header field:
     2674
     2675
     2676
     2677Fielding & Reschke           Standards Track                   [Page 47]
     2678
     2679
     2680RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2681
    26932682
    26942683     Via: 1.0 fred, 1.1 p.example.net
     
    27292718   An HTTP-to-HTTP proxy is called a "transforming proxy" if it is
    27302719   designed or configured to modify messages in a semantically
    2731 
    2732 
    2733 
    2734 Fielding & Reschke           Standards Track                   [Page 48]
    2735 
    2736 
    2737 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2738 
    2739 
    27402720   meaningful way (i.e., modifications, beyond those required by normal
    27412721   HTTP processing, that change the message in a way that would be
     
    27492729
    27502730   If a proxy receives a request-target with a host name that is not a
     2731
     2732
     2733
     2734Fielding & Reschke           Standards Track                   [Page 48]
     2735
     2736
     2737RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2738
     2739
    27512740   fully qualified domain name, it MAY add its own domain to the host
    27522741   name it received when forwarding the request.  A proxy MUST NOT
     
    27862775   session-layer connection protocol(s).  HTTP only presumes a reliable
    27872776   transport with in-order delivery of requests and the corresponding
    2788 
    2789 
    2790 
    2791 Fielding & Reschke           Standards Track                   [Page 49]
    2792 
    2793 
    2794 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2795 
    2796 
    27972777   in-order delivery of responses.  The mapping of HTTP request and
    27982778   response structures onto the data units of an underlying transport
     
    28052785   default TCP port of 80, but the client might be configured to use a
    28062786   proxy via some other connection, port, or protocol.
     2787
     2788
     2789
     2790
     2791Fielding & Reschke           Standards Track                   [Page 49]
     2792
     2793
     2794RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2795
    28072796
    28082797   HTTP implementations are expected to engage in connection management,
     
    28262815   When a header field aside from Connection is used to supply control
    28272816   information for or about the current connection, the sender MUST list
    2828    the corresponding field-name within the "Connection" header field.  A
     2817   the corresponding field-name within the Connection header field.  A
    28292818   proxy or gateway MUST parse a received Connection header field before
    28302819   a message is forwarded and, for each connection-option in this field,
     
    28442833   The Connection header field's value has the following grammar:
    28452834
    2846 
    2847 
    2848 Fielding & Reschke           Standards Track                   [Page 50]
    2849 
    2850 
    2851 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2852 
    2853 
    28542835     Connection        = 1#connection-option
    28552836     connection-option = token
    28562837
    2857    Connection options are case insensitive.
     2838   Connection options are case-insensitive.
    28582839
    28592840   A sender MUST NOT send a connection option corresponding to a header
     
    28612842   example, Cache-Control is never appropriate as a connection option
    28622843   (Section 5.2 of [RFC7234]).
     2844
     2845
     2846
     2847
     2848Fielding & Reschke           Standards Track                   [Page 50]
     2849
     2850
     2851RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2852
    28632853
    28642854   The connection options do not always correspond to a header field
     
    29012891   protocols.  Each connection applies to only one transport link.
    29022892
    2903 
    2904 
    2905 Fielding & Reschke           Standards Track                   [Page 51]
    2906 
    2907 
    2908 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2909 
    2910 
    291128936.3.  Persistence
    29122894
     
    29182900
    29192901   A recipient determines whether a connection is persistent or not
     2902
     2903
     2904
     2905Fielding & Reschke           Standards Track                   [Page 51]
     2906
     2907
     2908RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2909
     2910
    29202911   based on the most recently received message's protocol version and
    29212912   Connection header field (if any):
     
    29552946   with HTTP/1.0 clients.
    29562947
    2957 
    2958 
    2959 
    2960 
    2961 
    2962 Fielding & Reschke           Standards Track                   [Page 52]
    2963 
    2964 
    2965 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    2966 
    2967 
    296829486.3.1.  Retrying Requests
    29692949
     
    29772957   4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry non-
    29782958   idempotent requests.
     2959
     2960
     2961
     2962Fielding & Reschke           Standards Track                   [Page 52]
     2963
     2964
     2965RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     2966
    29792967
    29802968   A user agent MUST NOT automatically retry a request with a non-
     
    30143002   Idempotent methods (Section 4.2.2 of [RFC7231]) are significant to
    30153003   pipelining because they can be automatically retried after a
    3016 
    3017 
    3018 
    3019 Fielding & Reschke           Standards Track                   [Page 53]
    3020 
    3021 
    3022 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3023 
    3024 
    30253004   connection failure.  A user agent SHOULD NOT pipeline requests after
    30263005   a non-idempotent method, until the final response status code for
     
    30353014   response, the pipelining intermediary MAY attempt to retry a sequence
    30363015   of requests that have yet to receive a response if the requests all
     3016
     3017
     3018
     3019Fielding & Reschke           Standards Track                   [Page 53]
     3020
     3021
     3022RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3023
     3024
    30373025   have idempotent methods; otherwise, the pipelining intermediary
    30383026   SHOULD forward any received responses and then close the
     
    30713059   existence) of this timeout for either the client or the server.
    30723060
    3073 
    3074 
    3075 
    3076 Fielding & Reschke           Standards Track                   [Page 54]
    3077 
    3078 
    3079 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3080 
    3081 
    30823061   A client or server that wishes to time out SHOULD issue a graceful
    30833062   close on the connection.  Implementations SHOULD constantly monitor
     
    30933072   request is in progress.
    30943073
     3074
     3075
     3076Fielding & Reschke           Standards Track                   [Page 54]
     3077
     3078
     3079RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3080
     3081
    30953082   A server SHOULD sustain persistent connections, when possible, and
    30963083   allow the underlying transport's flow-control mechanisms to resolve
     
    31063093   the connection.
    31073094
    3108 6.6.  Teardown
     30956.6.  Tear-down
    31093096
    31103097   The Connection header field (Section 6.1) provides a "close"
     
    31133100
    31143101   A client that sends a "close" connection option MUST NOT send further
    3115    requests on that connection (after the one containing close) and MUST
    3116    close the connection after reading the final response message
     3102   requests on that connection (after the one containing "close") and
     3103   MUST close the connection after reading the final response message
    31173104   corresponding to this request.
    31183105
    31193106   A server that receives a "close" connection option MUST initiate a
    31203107   close of the connection (see below) after it sends the final response
    3121    to the request that contained close.  The server SHOULD send a close
    3122    connection option in its final response on that connection.  The
    3123    server MUST NOT process any further requests received on that
     3108   to the request that contained "close".  The server SHOULD send a
     3109   "close" connection option in its final response on that connection.
     3110   The server MUST NOT process any further requests received on that
    31243111   connection.
    31253112
    31263113   A server that sends a "close" connection option MUST initiate a close
    31273114   of the connection (see below) after it sends the response containing
    3128    close.  The server MUST NOT process any further requests received on
    3129    that connection.
    3130 
    3131 
    3132 
    3133 Fielding & Reschke           Standards Track                   [Page 55]
    3134 
    3135 
    3136 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3137 
     3115   "close".  The server MUST NOT process any further requests received
     3116   on that connection.
    31383117
    31393118   A client that receives a "close" connection option MUST cease sending
    31403119   requests on that connection and close the connection after reading
    3141    the response message containing the close; if additional pipelined
     3120   the response message containing the "close"; if additional pipelined
    31423121   requests had been sent on the connection, the client SHOULD NOT
    31433122   assume that they will be processed by the server.
     
    31493128   sent by the client before receiving the server's response, the
    31503129   server's TCP stack will send a reset packet to the client;
     3130
     3131
     3132
     3133Fielding & Reschke           Standards Track                   [Page 55]
     3134
     3135
     3136RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3137
     3138
    31513139   unfortunately, the reset packet might erase the client's
    31523140   unacknowledged input buffers before they can be read and interpreted
     
    31853173   A server that sends a 101 (Switching Protocols) response MUST send an
    31863174   Upgrade header field to indicate the new protocol(s) to which the
    3187 
    3188 
    3189 
    3190 Fielding & Reschke           Standards Track                   [Page 56]
    3191 
    3192 
    3193 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3194 
    3195 
    31963175   connection is being switched; if multiple protocol layers are being
    31973176   switched, the sender MUST list the protocols in layer-ascending
     
    32053184   Upgrade header field to indicate the acceptable protocols, in order
    32063185   of descending preference.
     3186
     3187
     3188
     3189
     3190Fielding & Reschke           Standards Track                   [Page 56]
     3191
     3192
     3193RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3194
    32073195
    32083196   A server MAY send an Upgrade header field in any other response to
     
    32393227   protocol; an OPTIONS request can be honored by any protocol.
    32403228
    3241 
    3242 
    3243 
    3244 
    3245 
    3246 
    3247 Fielding & Reschke           Standards Track                   [Page 57]
    3248 
    3249 
    3250 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3251 
    3252 
    32533229   The following is an example response to the above hypothetical
    32543230   request:
     
    32663242   intermediaries that might not implement the listed protocols.  A
    32673243   server MUST ignore an Upgrade header field that is received in an
     3244
     3245
     3246
     3247Fielding & Reschke           Standards Track                   [Page 57]
     3248
     3249
     3250RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3251
     3252
    32683253   HTTP/1.0 request.
    32693254
     
    32993284   single comma (",") and optional whitespace (OWS).
    33003285
    3301 
    3302 
    3303 
    3304 Fielding & Reschke           Standards Track                   [Page 58]
    3305 
    3306 
    3307 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3308 
    3309 
    33103286   In any production that uses the list construct, a sender MUST NOT
    33113287   generate empty list elements.  In other words, a sender MUST generate
     
    33233299
    33243300   For compatibility with legacy list rules, a recipient MUST parse and
     3301
     3302
     3303
     3304Fielding & Reschke           Standards Track                   [Page 58]
     3305
     3306
     3307RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3308
     3309
    33253310   ignore a reasonable number of empty list elements: enough to handle
    33263311   common mistakes by senders that merge values, but not so much that
     
    33383323     example-list-elmt = token ; see Section 3.2.6
    33393324
    3340    Then, the following are valid values for example-list (not including
     3325   Then the following are valid values for example-list (not including
    33413326   the double quotes, which are present for delimitation only):
    33423327
     
    33553340   constructs have been expanded.
    33563341
    3357 
    3358 
    3359 
    3360 
    3361 Fielding & Reschke           Standards Track                   [Page 59]
    3362 
    3363 
    3364 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3365 
    3366 
    336733428.  IANA Considerations
    33683343
    336933448.1.  Header Field Registration
    33703345
    3371    HTTP header fields are registered within the "Message Header" field
     3346   HTTP header fields are registered within the "Message Headers"
    33723347   registry maintained at
    33733348   <http://www.iana.org/assignments/message-headers/>.
     
    33763351   "Permanent Message Header Field Names" registry has been updated
    33773352   accordingly (see [BCP90]).
     3353
     3354
     3355
     3356
     3357
     3358
     3359
     3360
     3361Fielding & Reschke           Standards Track                   [Page 59]
     3362
     3363
     3364RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3365
    33783366
    33793367   +-------------------+----------+----------+---------------+
     
    33923380   Furthermore, the header field-name "Close" has been registered as
    33933381   "reserved", since using that name as an HTTP header field might
    3394    conflict with the "close" connection option of the "Connection"
    3395    header field (Section 6.1).
     3382   conflict with the "close" connection option of the Connection header
     3383   field (Section 6.1).
    33963384
    33973385   +-------------------+----------+----------+-------------+
     
    34113399   This document defines the following URI schemes, so the "Permanent
    34123400   URI Schemes" registry has been updated accordingly.
    3413 
    3414 
    3415 
    3416 
    3417 
    3418 Fielding & Reschke           Standards Track                   [Page 60]
    3419 
    3420 
    3421 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3422 
    34233401
    34243402   +------------+------------------------------------+---------------+
     
    34353413
    34363414   This document serves as the specification for the Internet media
     3415
     3416
     3417
     3418Fielding & Reschke           Standards Track                   [Page 60]
     3419
     3420
     3421RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3422
     3423
    34373424   types "message/http" and "application/http".  The following has been
    34383425   registered with IANA.
     
    34673454   Interoperability considerations:  N/A
    34683455
     3456   Published specification:  This specification (see Section 8.3.1).
     3457
     3458   Applications that use this media type:  N/A
     3459
     3460   Fragment identifier considerations:  N/A
     3461
     3462   Additional information:
     3463
     3464      Magic number(s):  N/A
     3465
     3466      Deprecated alias names for this type:  N/A
     3467
     3468      File extension(s):  N/A
    34693469
    34703470
     
    34793479
    34803480
    3481    Published specification:  This specification (see Section 8.3.1).
    3482 
    3483    Applications that use this media type:  N/A
    3484 
    3485    Fragment identifier considerations:  N/A
    3486 
    3487    Additional information:
    3488 
    3489       Magic number(s):  N/A
    3490 
    3491       Deprecated alias names for this type:  N/A
    3492 
    3493       File extension(s):  N/A
    3494 
    34953481      Macintosh file type code(s):  N/A
    34963482
    34973483   Person and email address to contact for further information:
    3498       See Authors' Addresses  Section.
     3484      See Authors' Addresses Section.
    34993485
    35003486   Intended usage:  COMMON
     
    35273513         body.
    35283514
    3529 
    3530 
    3531 
    3532 Fielding & Reschke           Standards Track                   [Page 62]
    3533 
    3534 
    3535 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3536 
    3537 
    35383515   Encoding considerations:  HTTP messages enclosed by this type are in
    35393516      "binary" format; use of an appropriate Content-Transfer-Encoding
     
    35483525   Applications that use this media type:  N/A
    35493526
     3527
     3528
     3529
     3530
     3531
     3532Fielding & Reschke           Standards Track                   [Page 62]
     3533
     3534
     3535RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3536
     3537
    35503538   Fragment identifier considerations:  N/A
    35513539
     
    357335618.4.  Transfer Coding Registry
    35743562
    3575    The "HTTP Transfer Coding" registry defines the namespace for
     3563   The "HTTP Transfer Coding Registry" defines the namespace for
    35763564   transfer coding names.  It is maintained at
    35773565   <http://www.iana.org/assignments/http-parameters>.
     
    35823570
    35833571   o  Name
    3584 
    3585 
    3586 
    3587 
    3588 
    3589 Fielding & Reschke           Standards Track                   [Page 63]
    3590 
    3591 
    3592 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3593 
    35943572
    35953573   o  Description
     
    36053583   4.1 of [RFC5226]), and MUST conform to the purpose of transfer coding
    36063584   defined in this specification.
     3585
     3586
     3587
     3588
     3589Fielding & Reschke           Standards Track                   [Page 63]
     3590
     3591
     3592RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3593
    36073594
    36083595   Use of program names for the identification of encoding formats is
     
    36323619   <http://www.iana.org/assignments/http-parameters>.
    36333620
    3634    The "HTTP Content Codings Registry" has been updated with the
     3621   The "HTTP Content Coding Registry" has been updated with the
    36353622   registrations below:
    3636 
    3637 
    3638 
    3639 
    3640 
    3641 
    3642 
    3643 
    3644 
    3645 
    3646 Fielding & Reschke           Standards Track                   [Page 64]
    3647 
    3648 
    3649 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3650 
    36513623
    36523624   +------------+--------------------------------------+---------------+
     
    36693641   <http://www.iana.org/assignments/http-upgrade-tokens>.
    36703642
     3643
     3644
     3645
     3646Fielding & Reschke           Standards Track                   [Page 64]
     3647
     3648
     3649RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3650
     3651
    367136528.6.1.  Procedure
    36723653
     
    36993680       cannot be contacted.
    37003681
    3701 
    3702 
    3703 Fielding & Reschke           Standards Track                   [Page 65]
    3704 
    3705 
    3706 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3707 
    3708 
    37093682   This registration procedure for HTTP Upgrade Tokens replaces that
    37103683   previously defined in Section 7.2 of [RFC2817].
     
    371236858.6.2.  Upgrade Token Registration
    37133686
    3714    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
    3715    updated with the registration below:
     3687   The "HTTP" entry in the upgrade token registry has been updated with
     3688   the registration below:
    37163689
    37173690   +-------+----------------------+----------------------+-------------+
     
    37253698   The responsible party is: "IETF (iesg@ietf.org) - Internet
    37263699   Engineering Task Force".
     3700
     3701
     3702
     3703Fielding & Reschke           Standards Track                   [Page 65]
     3704
     3705
     3706RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3707
    37273708
    372837099.  Security Considerations
     
    37553736   unknown or untrusted source.
    37563737
    3757 
    3758 
    3759 
    3760 Fielding & Reschke           Standards Track                   [Page 66]
    3761 
    3762 
    3763 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3764 
    3765 
    37663738   When a registered name is used in the authority component, the "http"
    37673739   URI scheme (Section 2.7.1) relies on the user's local name resolution
     
    37723744   Domain Name Service (DNS), and the hierarchy of servers from which it
    37733745   obtains resolution results, could impact the authenticity of address
    3774    mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
     3746   mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
    37753747   improve authenticity.
    37763748
     
    37833755   authority, provided that the negotiated TLS connection is secured and
    37843756   the client properly verifies that the communicating server's identity
     3757
     3758
     3759
     3760Fielding & Reschke           Standards Track                   [Page 66]
     3761
     3762
     3763RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3764
     3765
    37853766   matches the target URI's authority component (see [RFC2818]).
    37863767   Correctly implementing such verification can be difficult (see
     
    38113792   than the people who run them; HTTP itself cannot solve this problem.
    38123793
    3813 
    3814 
    3815 
    3816 
    3817 Fielding & Reschke           Standards Track                   [Page 67]
    3818 
    3819 
    3820 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3821 
    3822 
    382337949.3.  Attacks via Protocol Element Length
    38243795
     
    38413812
    38423813   Recipients ought to carefully limit the extent to which they process
     3814
     3815
     3816
     3817Fielding & Reschke           Standards Track                   [Page 67]
     3818
     3819
     3820RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3821
     3822
    38433823   other protocol elements, including (but not limited to) request
    38443824   methods, response status phrases, header field-names, numeric values,
     
    38693849
    38703850   For example, a parameter within the request-target might be read by
    3871 
    3872 
    3873 
    3874 Fielding & Reschke           Standards Track                   [Page 68]
    3875 
    3876 
    3877 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3878 
    3879 
    38803851   an application server and reused within a redirect, resulting in the
    38813852   same parameter being echoed in the Location header field of the
     
    38973868   stream.
    38983869
     3870
     3871
     3872
     3873
     3874Fielding & Reschke           Standards Track                   [Page 68]
     3875
     3876
     3877RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3878
     3879
    389938809.5.  Request Smuggling
    39003881
     
    39263907   User agents are encouraged to implement configurable means for
    39273908   detecting and reporting failures of message integrity such that those
    3928 
    3929 
    3930 
    3931 Fielding & Reschke           Standards Track                   [Page 69]
    3932 
    3933 
    3934 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3935 
    3936 
    39373909   means can be enabled within environments for which integrity is
    39383910   necessary.  For example, a browser being used to view medical history
     
    39403912   such information is detected by the protocol to be incomplete,
    39413913   expired, or corrupted during transfer.  Such mechanisms might be
    3942    selectively enabled via user-agent extensions or the presence of
     3914   selectively enabled via user agent extensions or the presence of
    39433915   message integrity metadata in a response.  At a minimum, user agents
    39443916   ought to provide some indication that allows a user to distinguish
     
    39543926   the selection of such transports being identified by the choice of
    39553927   URI scheme or within user agent configuration.
     3928
     3929
     3930
     3931Fielding & Reschke           Standards Track                   [Page 69]
     3932
     3933
     3934RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3935
    39563936
    39573937   The "https" scheme can be used to identify resources that require a
     
    39823962   fraud control.
    39833963
    3984 
    3985 
    3986 
    3987 
    3988 Fielding & Reschke           Standards Track                   [Page 70]
    3989 
    3990 
    3991 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    3992 
    3993 
    3994396410.  Acknowledgments
    39953965
     
    40133983   Anthony Bryan, Asbjorn Ulsberg, Ashok Kumar, Balachander
    40143984   Krishnamurthy, Barry Leiba, Ben Laurie, Benjamin Carlyle, Benjamin
     3985
     3986
     3987
     3988Fielding & Reschke           Standards Track                   [Page 70]
     3989
     3990
     3991RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     3992
     3993
    40153994   Niven-Jenkins, Benoit Claise, Bil Corry, Bill Burke, Bjoern
    40163995   Hoehrmann, Bob Scheifler, Boris Zbarsky, Brett Slatkin, Brian Kell,
     
    40404019   Sicking, Jonathan A. Rees, Jonathan Billington, Jonathan Moore,
    40414020   Jonathan Silvera, Jordi Ros, Joris Dobbelsteen, Josh Cohen, Julien
    4042 
    4043 
    4044 
    4045 Fielding & Reschke           Standards Track                   [Page 71]
    4046 
    4047 
    4048 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4049 
    4050 
    40514021   Pierre, Jungshik Shin, Justin Chapweske, Justin Erenkrantz, Justin
    40524022   James, Kalvinder Singh, Karl Dubost, Kathleen Moriarty, Keith
     
    40704040   Simpson, Robert Brewer, Robert Collins, Robert Mattson, Robert
    40714041   O'Callahan, Robert Olofsson, Robert Sayre, Robert Siemer, Robert de
     4042
     4043
     4044
     4045Fielding & Reschke           Standards Track                   [Page 71]
     4046
     4047
     4048RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4049
     4050
    40724051   Wilde, Roberto Javier Godoy, Roberto Peon, Roland Zink, Ronny
    40734052   Widjaja, Ryan Hamilton, S. Mike Dierken, Salvatore Loreto, Sam
     
    4095407411.1.  Normative References
    40964075
     4076   [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
     4077                 RFC 793, September 1981.
     4078
    40974079   [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
    40984080                 Format Specification version 3.3", RFC 1950, May 1996.
    4099 
    4100 
    4101 
    4102 Fielding & Reschke           Standards Track                   [Page 72]
    4103 
    4104 
    4105 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4106 
    41074081
    41084082   [RFC1951]     Deutsch, P., "DEFLATE Compressed Data Format
     
    41244098                 January 2008.
    41254099
     4100
     4101
     4102Fielding & Reschke           Standards Track                   [Page 72]
     4103
     4104
     4105RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4106
     4107
    41264108   [RFC7231]     Fielding, R., Ed. and J. Reschke, Ed., "Hypertext
    41274109                 Transfer Protocol (HTTP/1.1): Semantics and Content",
     
    41444126                 RFC 7235, May 2014.
    41454127
    4146    [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
    4147                  RFC 793, September 1981.
    4148 
    41494128   [USASCII]     American National Standards Institute, "Coded Character
    41504129                 Set -- 7-bit American Standard Code for Information
     
    41534132   [Welch]       Welch, T., "A Technique for High-Performance Data
    41544133                 Compression", IEEE Computer 17(6), June 1984.
    4155 
    4156 
    4157 
    4158 
    4159 Fielding & Reschke           Standards Track                   [Page 73]
    4160 
    4161 
    4162 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4163 
    41644134
    4165413511.2.  Informative References
     
    41854155                 <http://doi.acm.org/10.1145/2382196.2382204>.
    41864156
     4157
     4158
     4159Fielding & Reschke           Standards Track                   [Page 73]
     4160
     4161
     4162RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4163
     4164
    41874165   [ISO-8859-1]  International Organization for Standardization,
    41884166                 "Information technology -- 8-bit single-byte coded
     
    42114189                 May 1996.
    42124190
    4213 
    4214 
    4215 
    4216 Fielding & Reschke           Standards Track                   [Page 74]
    4217 
    4218 
    4219 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4220 
    4221 
    42224191   [RFC2045]     Freed, N. and N. Borenstein, "Multipurpose Internet
    42234192                 Mail Extensions (MIME) Part One: Format of Internet
     
    42434212                 HTTP/1.1", RFC 2817, May 2000.
    42444213
     4214
     4215
     4216Fielding & Reschke           Standards Track                   [Page 74]
     4217
     4218
     4219RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4220
     4221
    42454222   [RFC2818]     Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
    42464223
     
    42674244   [RFC5322]     Resnick, P., "Internet Message Format", RFC 5322,
    42684245                 October 2008.
    4269 
    4270 
    4271 
    4272 
    4273 Fielding & Reschke           Standards Track                   [Page 75]
    4274 
    4275 
    4276 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4277 
    42784246
    42794247   [RFC6265]     Barth, A., "HTTP State Management Mechanism", RFC 6265,
     
    43004268
    43014269   HTTP/1.1 remains compatible with HTTP/1.0 by including more stringent
     4270
     4271
     4272
     4273Fielding & Reschke           Standards Track                   [Page 75]
     4274
     4275
     4276RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4277
     4278
    43024279   requirements that enable reliable implementations, adding only those
    43034280   features that can either be safely ignored by an HTTP/1.0 recipient
     
    43244301   This section summarizes major differences between versions HTTP/1.0
    43254302   and HTTP/1.1.
    4326 
    4327 
    4328 
    4329 
    4330 Fielding & Reschke           Standards Track                   [Page 76]
    4331 
    4332 
    4333 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4334 
    43354303
    43364304A.1.1.  Multihomed Web Servers
     
    43574325   the request and closed by the server after sending the response.
    43584326   However, some implementations implement the explicitly negotiated
     4327
     4328
     4329
     4330Fielding & Reschke           Standards Track                   [Page 76]
     4331
     4332
     4333RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4334
     4335
    43594336   ("Keep-Alive") version of persistent connections described in Section
    43604337   19.7.1 of [RFC2068].
     
    43824359   monitor the connection for "hung" requests (which indicate that the
    43834360   client ought stop sending the header field), and this mechanism ought
    4384 
    4385 
    4386 
    4387 Fielding & Reschke           Standards Track                   [Page 77]
    4388 
    4389 
    4390 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4391 
    4392 
    43934361   not be used by clients at all when a proxy is being used.
    43944362
     
    44014369A.2.  Changes from RFC 2616
    44024370
    4403    HTTP's approach to error handling has been explained (Section 2.5).
    4404 
    4405    The HTTP-version ABNF production has been clarified to be case
     4371   HTTP's approach to error handling has been explained.  (Section 2.5)
     4372
     4373   The HTTP-version ABNF production has been clarified to be case-
    44064374   sensitive.  Additionally, version numbers have been restricted to
    44074375   single digits, due to the fact that implementations are known to
    4408    handle multi-digit version numbers incorrectly (Section 2.6).
     4376   handle multi-digit version numbers incorrectly.  (Section 2.6)
    44094377
    44104378   Userinfo (i.e., username and password) are now disallowed in HTTP and
    44114379   HTTPS URIs, because of security issues related to their transmission
    4412    on the wire (Section 2.7.1).
     4380   on the wire.  (Section 2.7.1)
    44134381
    44144382   The HTTPS URI scheme is now defined by this specification;
    4415    previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
    4416    it implies end-to-end security (Section 2.7.2).
     4383   previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
     4384
     4385
     4386
     4387Fielding & Reschke           Standards Track                   [Page 77]
     4388
     4389
     4390RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4391
     4392
     4393   implies end-to-end security.  (Section 2.7.2)
    44174394
    44184395   HTTP messages can be (and often are) buffered by implementations;
     
    44204397   fundamentally a message-oriented protocol.  Minimum supported sizes
    44214398   for various protocol elements have been suggested, to improve
    4422    interoperability (Section 3).
     4399   interoperability.  (Section 3)
    44234400
    44244401   Invalid whitespace around field-names is now required to be rejected,
    44254402   because accepting it represents a security vulnerability.  The ABNF
    4426    productions defining header fields now only list the field value
    4427    (Section 3.2).
     4403   productions defining header fields now only list the field value.
     4404   (Section 3.2)
    44284405
    44294406   Rules about implicit linear whitespace between certain grammar
    44304407   productions have been removed; now whitespace is only allowed where
    4431    specifically defined in the ABNF (Section 3.2.3).
     4408   specifically defined in the ABNF.  (Section 3.2.3)
    44324409
    44334410   Header fields that span multiple lines ("line folding") are
    4434    deprecated (Section 3.2.4).
     4411   deprecated.  (Section 3.2.4)
    44354412
    44364413   The NUL octet is no longer allowed in comment and quoted-string text,
     
    44384415   quoted-pair rule no longer allows escaping control characters other
    44394416   than HTAB.  Non-US-ASCII content in header fields and the reason
    4440    phrase has been obsoleted and made opaque (the TEXT rule was removed)
    4441 
    4442 
    4443 
    4444 Fielding & Reschke           Standards Track                   [Page 78]
    4445 
    4446 
    4447 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4448 
    4449 
    4450    (Section 3.2.6).
    4451 
    4452    Bogus "Content-Length" header fields are now required to be handled
    4453    as errors by recipients (Section 3.3.2).
     4417   phrase has been obsoleted and made opaque (the TEXT rule was
     4418   removed).  (Section 3.2.6)
     4419
     4420   Bogus Content-Length header fields are now required to be handled as
     4421   errors by recipients.  (Section 3.3.2)
    44544422
    44554423   The algorithm for determining the message body length has been
     
    44584426   elements cannot define such special cases.  CONNECT is a new, special
    44594427   case in determining message body length. "multipart/byteranges" is no
    4460    longer a way of determining message body length detection
    4461    (Section 3.3.3).
    4462 
    4463    The "identity" transfer coding token has been removed (Sections 3.3
    4464    and 4).
     4428   longer a way of determining message body length detection.
     4429   (Section 3.3.3)
     4430
     4431   The "identity" transfer coding token has been removed. (Sections 3.3
     4432   and 4)
    44654433
    44664434   Chunk length does not include the count of the octets in the chunk
    4467    header and trailer.  Line folding in chunk extensions is disallowed
    4468    (Section 4.1).
    4469 
    4470    The meaning of the "deflate" content coding has been clarified
    4471    (Section 4.2.2).
     4435   header and trailer.  Line folding in chunk extensions is disallowed.
     4436   (Section 4.1)
     4437
     4438   The meaning of the "deflate" content coding has been clarified.
     4439   (Section 4.2.2)
     4440
     4441
     4442
     4443
     4444Fielding & Reschke           Standards Track                   [Page 78]
     4445
     4446
     4447RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4448
    44724449
    44734450   The segment + query components of RFC 3986 have been used to define
    44744451   the request-target, instead of abs_path from RFC 1808.  The asterisk-
    4475    form of the request-target is only allowed with the OPTIONS method
    4476    (Section 5.3).
    4477 
    4478    The term "Effective Request URI" has been introduced (Section 5.5).
    4479 
    4480    Gateways do not need to generate Via header fields anymore
    4481    (Section 5.7.1).
     4452   form of the request-target is only allowed with the OPTIONS method.
     4453   (Section 5.3)
     4454
     4455   The term "Effective Request URI" has been introduced.  (Section 5.5)
     4456
     4457   Gateways do not need to generate Via header fields anymore.
     4458   (Section 5.7.1)
    44824459
    44834460   Exactly when "close" connection options have to be sent has been
    44844461   clarified.  Also, "hop-by-hop" header fields are required to appear
    44854462   in the Connection header field; just because they're defined as hop-
    4486    by-hop in this specification doesn't exempt them (Section 6.1).
     4463   by-hop in this specification doesn't exempt them.  (Section 6.1)
    44874464
    44884465   The limit of two connections per server has been removed.  An
     
    44914468   the server prematurely closes the connection has been removed.  Also,
    44924469   some extraneous requirements about when servers are allowed to close
    4493    connections prematurely have been removed (Section 6.3).
     4470   connections prematurely have been removed.  (Section 6.3)
    44944471
    44954472   The semantics of the Upgrade header field is now defined in responses
    44964473   other than 101 (this was incorporated from [RFC2817]).  Furthermore,
    4497    the ordering in the field value is now significant (Section 6.7).
    4498 
    4499 
    4500 
    4501 Fielding & Reschke           Standards Track                   [Page 79]
    4502 
    4503 
    4504 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4505 
     4474   the ordering in the field value is now significant.  (Section 6.7)
    45064475
    45074476   Empty list elements in list productions (e.g., a list header field
    4508    containing ", ,") have been deprecated (Section 7).
     4477   containing ", ,") have been deprecated.  (Section 7)
    45094478
    45104479   Registration of Transfer Codings now requires IETF Review
    4511    (Section 8.4).
    4512 
    4513    This specification now defines the "HTTP Upgrade Tokens" registry,
    4514    previously defined in Section 7.2 of [RFC2817] (Section 8.6).
    4515 
    4516    The expectation to support HTTP/0.9 requests has been removed
    4517    (Appendix A).
     4480   (Section 8.4)
     4481
     4482   This specification now defines the Upgrade Token Registry, previously
     4483   defined in Section 7.2 of [RFC2817].  (Section 8.6)
     4484
     4485   The expectation to support HTTP/0.9 requests has been removed.
     4486   (Appendix A)
    45184487
    45194488   Issues with the Keep-Alive and Proxy-Connection header fields in
    45204489   requests are pointed out, with use of the latter being discouraged
    4521    altogether (Appendix A.1.2).
     4490   altogether.  (Appendix A.1.2)
    45224491
    45234492Appendix B.  Collected ABNF
     
    45274496   Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
    45284497    connection-option ] )
     4498
     4499
     4500
     4501Fielding & Reschke           Standards Track                   [Page 79]
     4502
     4503
     4504RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4505
     4506
    45294507   Content-Length = 1*DIGIT
    45304508
     
    45534531   absolute-URI = <absolute-URI, defined in [RFC3986], Section 4.3>
    45544532   absolute-form = absolute-URI
    4555 
    4556 
    4557 
    4558 Fielding & Reschke           Standards Track                   [Page 80]
    4559 
    4560 
    4561 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4562 
    4563 
    45644533   absolute-path = 1*( "/" segment )
    45654534   asterisk-form = "*"
     
    45844553   field-name = token
    45854554   field-value = *( field-content / obs-fold )
     4555
     4556
     4557
     4558Fielding & Reschke           Standards Track                   [Page 80]
     4559
     4560
     4561RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4562
     4563
    45864564   field-vchar = VCHAR / obs-text
    45874565   fragment = <fragment, defined in [RFC3986], Section 3.5>
     
    46094587   protocol-version = token
    46104588   pseudonym = token
    4611 
    4612 
    4613 
    4614 
    4615 Fielding & Reschke           Standards Track                   [Page 81]
    4616 
    4617 
    4618 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4619 
    46204589
    46214590   qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
     
    46404609   status-code = 3DIGIT
    46414610   status-line = HTTP-version SP status-code SP reason-phrase CRLF
     4611
     4612
     4613
     4614
     4615Fielding & Reschke           Standards Track                   [Page 81]
     4616
     4617
     4618RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4619
    46424620
    46434621   t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
     
    46574635
    46584636   A
    4659       absolute-form (of request-target)  42
     4637      absolute-form (of request-target)  41
    46604638      accelerator  10
    46614639      application/http Media Type  62
     
    46664644   B
    46674645      browser  7
    4668 
    4669 
    4670 
    4671 
    4672 Fielding & Reschke           Standards Track                   [Page 82]
    4673 
    4674 
    4675 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4676 
    46774646
    46784647   C
     
    46864655      connection  7
    46874656      Connection header field  50, 55
    4688       Content-Length header field  30
     4657      Content-Length header field  29
    46894658
    46904659   D
    46914660      deflate (Coding Format)  38
    46924661      Delimiters  26
    4693       downstream  10
     4662      downstream  9
    46944663
    46954664   E
     
    46984667   G
    46994668      gateway  10
     4669
     4670
     4671
     4672Fielding & Reschke           Standards Track                   [Page 82]
     4673
     4674
     4675RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4676
     4677
    47004678      Grammar
    4701          absolute-form  41-42
     4679         absolute-form  41
    47024680         absolute-path  16
    47034681         absolute-URI  16
     
    47154693         chunked-body  35-36
    47164694         comment  27
    4717          Connection  51
    4718          connection-option  51
    4719          Content-Length  30
     4695         Connection  50
     4696         connection-option  50
     4697         Content-Length  29
    47204698         CR  6
    47214699         CRLF  6
     
    47244702         DIGIT  6
    47254703         DQUOTE  6
    4726 
    4727 
    4728 
    4729 Fielding & Reschke           Standards Track                   [Page 83]
    4730 
    4731 
    4732 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4733 
    4734 
    47354704         field-content  22
    47364705         field-name  22, 39
     
    47434712         HTAB  6
    47444713         HTTP-message  19
    4745          HTTP-name  14
     4714         HTTP-name  13
    47464715         http-URI  16
    4747          HTTP-version  14
     4716         HTTP-version  13
    47484717         https-URI  18
    47494718         last-chunk  35
     
    47554724         OCTET  6
    47564725         origin-form  41
     4726
     4727
     4728
     4729Fielding & Reschke           Standards Track                   [Page 83]
     4730
     4731
     4732RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4733
     4734
    47574735         OWS  24
    47584736         partial-URI  16
     
    47804758         t-codings  38
    47814759         t-ranking  38
    4782          tchar  27
    4783 
    4784 
    4785 
    4786 Fielding & Reschke           Standards Track                   [Page 84]
    4787 
    4788 
    4789 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4790 
    4791 
     4760         tchar  26
    47924761         TE  38
    4793          token  27
     4762         token  26
    47944763         Trailer  39
    47954764         trailer-part  35-36
     
    48134782      https URI scheme  18
    48144783
     4784
     4785
     4786Fielding & Reschke           Standards Track                   [Page 84]
     4787
     4788
     4789RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4790
     4791
    48154792   I
    4816       inbound  10
     4793      inbound  9
    48174794      interception proxy  11
    48184795      intermediary  9
     
    48324809      origin server  7
    48334810      origin-form (of request-target)  41
    4834       outbound  10
     4811      outbound  9
    48354812
    48364813   P
    48374814      phishing  66
    48384815      proxy  10
    4839 
    4840 
    4841 
    4842 
    4843 Fielding & Reschke           Standards Track                   [Page 85]
    4844 
    4845 
    4846 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4847 
    48484816
    48494817   R
     
    48704838      tunnel  10
    48714839
     4840
     4841
     4842
     4843Fielding & Reschke           Standards Track                   [Page 85]
     4844
     4845
     4846RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
     4847
     4848
    48724849   U
    48734850      Upgrade header field  56
    4874       upstream  10
     4851      upstream  9
    48754852      URI scheme
    48764853         http  16
     
    48794856
    48804857   V
    4881       Via header field  47
     4858      Via header field  46
    48824859
    48834860Authors' Addresses
     
    48934870
    48944871
    4895 
    4896 
    4897 
    4898 
    4899 
    4900 Fielding & Reschke           Standards Track                   [Page 86]
    4901 
    4902 
    4903 RFC 7230           HTTP/1.1 Message Syntax and Routing          May 2014
    4904 
    4905 
    49064872   Julian F. Reschke (editor)
    49074873   greenbytes GmbH
     
    49324898
    49334899
    4934 
    4935 
    4936 
    4937 
    4938 
    4939 
    4940 
    4941 
    4942 
    4943 
    4944 
    4945 
    4946 
    4947 
    4948 
    4949 
    4950 
    4951 
    4952 
    4953 
    4954 
    4955 
    4956 
    4957 Fielding & Reschke           Standards Track                   [Page 87]
    4958 
    4959 
     4900Fielding & Reschke           Standards Track                   [Page 86]
     4901
     4902
  • draft-ietf-httpbis/latest/auth48/rfc7230-to-be.xml

    r2664 r2665  
    1818
    1919<!-- [rfced] Please note that xml2rfc v2 is not producing the Index correctly
    20 at this time.  We have filed a ticket to get this fixed (see
    21 http://trac.tools.ietf.org/tools/xml2rfc/trac/ticket/249).  If it is not fixed
    22 by the time this cluster is ready to be published, we will use v1 to produce
    23 the final text. 
    24 -->
     20at this time.  We have switched to v1 per the request of the authors.  -->
    2521
    2622<front>
     
    6056  <area>Applications</area>
    6157  <workgroup>HTTPbis Working Group</workgroup>
    62 
    63 <!-- [rfced] Please insert any keywords (beyond those that appear in
    64 the title) for use on http://www.rfc-editor.org/search.
    65 -->
    66 
    67 <keyword>example</keyword>
    68 
    69 
    70 <!-- [rfced] Throughout the text, the following terminology appears in
    71 two or more forms.
    72 
    73 a.) Please review these occurrences and let us know if/how they may be made
    74 consistent. 
    75 
    76 Hyphenation:
    77 
    78 field-name vs. field name
    79 field-value vs. field value
    80 
    81 
    82 b.) We believe the forms on the right are the intended forms and will
    83 update (globally) as such unless we hear objection:
    84 
    85 Hyphenation:
    86 
    87 absolute form vs. absolute-form
    88 absolute URI vs. absolute-URI
    89 
    90 Quotation:
    91 
    92 header field name quotation
    93  e.g., "Expect" header field vs. Expect header field.
    94 
    95    Note: We believe the intention was to introduce the field names in double
    96    quotes.  However, this isn't used consistently and subsequent uses are
    97    sometimes quoted as well.  We will remove all quotation unless we hear
    98    otherwise.
    99 
    100 -->
    101 
    102 
     58 
     59  <keyword>Hypertext Transfer Protocol</keyword>
     60  <keyword>HTTP</keyword>
     61  <keyword>HTTP message format</keyword>
     62 
    10363<abstract>
    10464<t>
     
    12282   network-based hypertext information systems. This document is the first in
    12383   a series of documents that collectively form the HTTP/1.1 specification:
    124    <list style="empty">
    125     <t>RFC 7230: Message Syntax and Routing</t>
    126     <t>RFC 7231: Semantics and Content</t>
    127     <t>RFC 7232: Conditional Requests</t>
    128     <t>RFC 7233: Range Requests</t>
    129     <t>RFC 7234: Caching</t>
    130     <t>RFC 7235: Authentication</t>
     84   <list style="numbers">
     85    <t>"Message Syntax and Routing" (this document)</t>
     86    <t>"Semantics and Content" <xref target="RFC7231"/></t>
     87    <t>"Conditional Requests" <xref target="RFC7232"/></t>
     88    <t>"Range Requests" <xref target="RFC7233"/></t>
     89    <t>"Caching" <xref target="RFC7234"/></t>
     90    <t>"Authentication" <xref target="RFC7235"/></t>
    13191   </list>
    13292</t>
    13393<t>
    13494   This HTTP/1.1 specification obsoletes
    135    <xref target="RFC2616"/> and
    136    <xref target="RFC2145"/> (on HTTP versioning).
    137    This specification also updates the use of CONNECT, previously defined in RFC 2817, to establish a tunnel, and defines the "https" URI scheme that was described informally in
     95   RFC 2616 and
     96   RFC 2145 (on HTTP versioning).
     97   This specification also updates the use of CONNECT to establish a tunnel,
     98   previously defined in RFC 2817,
     99   and defines the "https" URI scheme that was described informally in
    138100   RFC 2818.
    139101</t>
     
    256218<iref primary="true" item="connection"/>
    257219<t>
    258 
    259 <!--[rfced] Please note that we have made occurrences of "transport
    260 and session-layer" appear as "transport- and session-layer" (meaning
    261 transport-layer and session-layer).  If this is in error, please let
    262 us know.
    263 
    264 -->
    265220   HTTP is a stateless request/response protocol that operates by exchanging
    266221   messages (<xref target="http.message"/>) across a reliable
     
    479434   the scope of this specification.  However, an HTTP-to-HTTP gateway
    480435   that wishes to interoperate with third-party HTTP servers ought to conform
    481    to user-agent requirements on the gateway's inbound connection.
     436   to user agent requirements on the gateway's inbound connection.
    482437</t>
    483438<t><iref primary="true" item="tunnel"/>
     
    661616<t>
    662617   The version of an HTTP message is indicated by an HTTP-version field
    663    in the first line of the message. HTTP-version is case sensitive.
     618   in the first line of the message. HTTP-version is case-sensitive.
    664619</t>
    665620<figure><iref primary="true" item="Grammar" subitem="HTTP-version"/><iref primary="true" item="Grammar" subitem="HTTP-name"/><artwork type="abnf2616"><![CDATA[
    666621  HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
    667   HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
     622  HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
    668623]]></artwork></figure>
    669624<t>
     
    701656   New header fields can be introduced without changing the protocol version
    702657   if their defined semantics allow them to be safely ignored by recipients
    703    that do not recognize them. Header-field extensibility is discussed in
     658   that do not recognize them. Header field extensibility is discussed in
    704659   <xref target="field.extensibility"/>.
    705660</t>
     
    768723   recipient is conformant. A recipient can assume that a message with a
    769724   higher minor version, when sent to a recipient that has not yet indicated
    770    support for that higher version, is sufficiently backwards compatible to be
     725   support for that higher version, is sufficiently backwards-compatible to be
    771726   safely processed by any implementation of the same major version.
    772727</t>
     
    801756   URI generic syntax.
    802757   An "absolute-path" rule is defined for protocol elements that can contain a
    803    non-empty path component. (This rule differs slightly from the
    804    path-abempty rule of RFC 3986, which allows for an empty path to be used in references,
     758   non-empty path component. (This rule differs slightly from the path-abempty
     759   rule of RFC 3986, which allows for an empty path to be used in references,
    805760   and path-absolute rule, which does not allow paths that begin with "//".)
    806761   A "partial-URI" rule is defined for protocol elements
     
    841796   identifiers according to their association with the hierarchical
    842797   namespace governed by a potential HTTP origin server listening for
    843    TCP (<xref target="RFC793"/>) connections on a given port.
     798   TCP (<xref target="RFC0793"/>) connections on a given port.
    844799</t>
    845800<figure><iref primary="true" item="Grammar" subitem="http-URI"><!--terminal production--></iref><artwork type="abnf2616"><![CDATA[
     
    974929   request target of an OPTIONS request, an empty path component is equivalent
    975930   to an absolute path of "/", so the normal form is to provide a path of "/"
    976    instead. The scheme and host are case insensitive and normally provided in
     931   instead. The scheme and host are case-insensitive and normally provided in
    977932   lowercase; all other components are compared in a case-sensitive manner.
    978933   Characters other than those in the "reserved" set are equivalent to their
     
    10621017</t>
    10631018
    1064 
    1065 <!--[rfced] In the text, we note the use of "start-line" and
    1066 "status-line"; however, the section titles "Start Line" and "Status
    1067 Line" (without hyphens) are used.  Please review this possible
    1068 inconsistency and let us know if/how we should update.
    1069 
    1070 -->
    10711019<section title="Start Line" anchor="start.line">
    10721020 
     
    10811029   In theory, a client could receive requests and a server could receive
    10821030   responses, distinguishing them by their different start-line formats,
    1083    but, in practice, servers are implemented only to expect a request
     1031   but, in practice, servers are implemented to only expect a request
    10841032   (a response is interpreted as an unknown or invalid request method)
    10851033   and clients are implemented to only expect a response.
     
    10931041 
    10941042<t>
    1095    A request-line begins with a method token and is followed by a single
     1043   A request-line begins with a method token, followed by a single
    10961044   space (SP), the request-target, another single space (SP), the
    10971045   protocol version, and ends with CRLF.
     
    11031051<t anchor="method">
    11041052   The method token indicates the request method to be performed on the
    1105    target resource. The request method is case sensitive.
     1053   target resource. The request method is case-sensitive.
    11061054</t>
    11071055<figure><iref primary="true" item="Grammar" subitem="method"/><artwork type="abnf2616"><![CDATA[
     
    11571105<t>
    11581106   The first line of a response message is the status-line, consisting
    1159    of the protocol version, a space (SP), the status code, another space (SP),
    1160    a possibly empty textual phrase describing the status code, and, finally, CRLF.
     1107   of the protocol version, a space (SP), the status code, another space,
     1108   a possibly empty textual phrase describing the status code, and
     1109   ending with CRLF.
    11611110</t>
    11621111<figure><iref primary="true" item="Grammar" subitem="status-line"/><artwork type="abnf2616"><![CDATA[
     
    12441193</t>
    12451194<t>
    1246 
    1247 
    12481195   All defined header fields ought to be registered with IANA in the
    1249    "Message Headers" field registry, as described in Section 8.3 of <xref target="RFC7231"/>.
     1196   "Message Headers" registry, as described in Section 8.3 of <xref target="RFC7231"/>.
    12501197</t>
    12511198</section>
     
    12851232   list syntax, violating the above requirements on multiple header fields
    12861233   with the same name. Since it cannot be combined into a single field-value,
    1287    recipients ought to handle Set-Cookie as a special case while processing
     1234   recipients ought to handle "Set-Cookie" as a special case while processing
    12881235   header fields. (See Appendix A.2.3 of <xref target="Kri2001"/> for details.)
    12891236  </t>
     
    13371284   message's entire header section has been processed).
    13381285   Consequently, this specification does not use ABNF rules to define each
    1339    "field-name: field-value" pair, as was done in previous editions.
     1286   "Field-Name: Field Value" pair, as was done in previous editions.
    13401287   Instead, this specification uses ABNF rules that are named according to
    13411288   each registered field name, wherein the rule defines the valid grammar for
     
    13971344</t>
    13981345<t>
    1399    Historically, HTTP has allowed field content with text in the ISO&nbhy;8859&nbhy;1
    1400    <xref target="ISO-8859-1"/> charset, supporting other charsets only
     1346   Historically, HTTP has allowed field content with text in the ISO&nbhy;8859&nbhy;charset <xref target="ISO-8859-1"/>, supporting other charsets only
    14011347   through use of <xref target="RFC2047"/> encoding.
    14021348   In practice, most HTTP header field values use only a subset of the
    1403    US&nbhy;ASCII charset <xref target="USASCII"/>. Newly defined
     1349   US-ASCII charset <xref target="USASCII"/>. Newly defined
    14041350   header fields SHOULD limit their field values to US&nbhy;ASCII octets.
    14051351   A recipient SHOULD treat other octets in field content (obs&nbhy;text) as
     
    15121458<t>
    15131459   The presence of a message body in a request is signaled by a
    1514    <xref target="header.content-length" format="none">Content-Length</xref> or <xref target="header.transfer-encoding" format="none">Transfer-Encoding</xref> header
     1460   "<xref target="header.content-length" format="none">Content-Length</xref>" or <xref target="header.transfer-encoding" format="none">Transfer-Encoding</xref> header
    15151461   field. Request message framing is independent of method semantics,
    15161462   even if the method does not define any use for a message body.
     
    15431489   Transfer codings are defined in <xref target="transfer.codings"/>.
    15441490</t>
    1545 
    1546 <!-- [rfced] We note that RFC 2616 allows the use of "#"; however, please note
    1547 that Bill Fenner's ABNF checker yields the following:
    1548 
    1549 Errors are noted by line number and column, e.g. line:column: Something bad.
    1550 
    1551 stdin(0:22): error: Illegal character '#' - skipping to end of line
    1552 stdin(1:0): error: syntax error
    1553 
    1554 parsing failed: 2 errors encountered
    1555 
    1556   Transfer-Encoding = 1#transfer-coding 
    1557 
    1558 There are a handful of similar cases throughout the document.  Please confirm
    1559 that this grammar is correct.
    1560 -->
    1561 
    15621491<figure><iref primary="true" item="Grammar" subitem="Transfer-Encoding"/><artwork type="abnf2616"><![CDATA[
    15631492  Transfer-Encoding = 1#transfer-coding
     
    19571886]]></artwork></figure>
    19581887<t>
    1959 
    1960    All transfer-coding names are case insensitive and ought to be registered
    1961    within the "HTTP Transfer Coding" registry, as defined in
     1888   All transfer-coding names are case-insensitive and ought to be registered
     1889   within the HTTP Transfer Coding registry, as defined in
    19621890   <xref target="transfer.coding.registry"/>.
    19631891   They are used in the <xref target="header.te" format="none">TE</xref> (<xref target="header.te"/>) and
     
    21462074<iref item="gzip (Coding Format)"/>
    21472075<t>
    2148    The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check (CRC) that is commonly
     2076   The "gzip" coding is an LZ77 coding with a 32-bit Cyclic Redundancy Check
     2077   (CRC) that is commonly
    21492078   produced by the gzip file compression program <xref target="RFC1952"/>.
    21502079   A recipient SHOULD consider "x-gzip" to be equivalent to "gzip".
     
    21732102   chunked is always acceptable for HTTP/1.1 recipients.
    21742103</t>
    2175 
    21762104<figure><iref primary="true" item="Grammar" subitem="TE"/><iref primary="true" item="Grammar" subitem="t-codings"/><iref primary="true" item="Grammar" subitem="t-ranking"/><iref primary="true" item="Grammar" subitem="rank"/><artwork type="abnf2616"><![CDATA[
    21772105  TE        = #t-codings
     
    28892817   When a header field aside from Connection is used to supply control
    28902818   information for or about the current connection, the sender MUST list
    2891    the corresponding field-name within the "Connection" header field.
     2819   the corresponding field-name within the Connection header field.
    28922820   A proxy or gateway MUST parse a received Connection
    28932821   header field before a message is forwarded and, for each
     
    29142842]]></artwork></figure>
    29152843<t>
    2916    Connection options are case insensitive.
     2844   Connection options are case-insensitive.
    29172845</t>
    29182846<t>
     
    31503078<t>
    31513079   A server SHOULD sustain persistent connections, when possible, and allow
    3152    the underlying
    3153    transport's flow-control mechanisms to resolve temporary overloads, rather
     3080   the underlying transport's flow-control mechanisms to resolve temporary overloads, rather
    31543081   than terminate connections with the expectation that clients will retry.
    31553082   The latter technique can exacerbate network congestion.
     
    31653092</section>
    31663093   
    3167 <section title="Teardown" anchor="persistent.tear-down">
     3094<section title="Tear-down" anchor="persistent.tear-down">
    31683095  <iref primary="false" item="Connection header field"/>
    31693096  <iref primary="false" item="close"/>
     
    31773104   A client that sends a "<xref target="header.connection" format="none">close</xref>" connection option MUST NOT
    31783105   send further requests on that connection (after the one containing
    3179    <xref target="header.connection" format="none">close</xref>) and MUST close the connection after reading the
     3106   "close") and MUST close the connection after reading the
    31803107   final response message corresponding to this request.
    31813108</t>
     
    31833110   A server that receives a "<xref target="header.connection" format="none">close</xref>" connection option MUST
    31843111   initiate a close of the connection (see below) after it sends the
    3185    final response to the request that contained <xref target="header.connection" format="none">close</xref>.
    3186    The server SHOULD send a <xref target="header.connection" format="none">close</xref> connection option
     3112   final response to the request that contained "close".
     3113   The server SHOULD send a "close" connection option
    31873114   in its final response on that connection. The server MUST NOT process
    31883115   any further requests received on that connection.
     
    31913118   A server that sends a "<xref target="header.connection" format="none">close</xref>" connection option MUST
    31923119   initiate a close of the connection (see below) after it sends the
    3193    response containing <xref target="header.connection" format="none">close</xref>. The server MUST NOT process
     3120   response containing "close". The server MUST NOT process
    31943121   any further requests received on that connection.
    31953122</t>
     
    31973124   A client that receives a "<xref target="header.connection" format="none">close</xref>" connection option MUST
    31983125   cease sending requests on that connection and close the connection
    3199    after reading the response message containing the close; if additional
     3126   after reading the response message containing the "close"; if additional
    32003127   pipelined requests had been sent on the connection, the client SHOULD NOT
    32013128   assume that they will be processed by the server.
     
    33933320]]></artwork></figure>
    33943321<t>
    3395    Then, the following are valid values for example-list (not including the
     3322   Then the following are valid values for example-list (not including the
    33963323   double quotes, which are present for delimitation only):
    33973324</t>
     
    34203347<section title="Header Field Registration" anchor="header.field.registration">
    34213348<t>
    3422    HTTP header fields are registered within the "Message Header" field registry
     3349   HTTP header fields are registered within the "Message Headers" registry
    34233350   maintained at
    3424    &lt;http://www.iana.org/assignments/message-headers/&gt;.
     3351   <eref target="http://www.iana.org/assignments/message-headers/"/>.
    34253352</t>
    34263353<t>
     
    34913418   Furthermore, the header field-name "Close" has been registered as
    34923419   "reserved", since using that name as an HTTP header field might
    3493    conflict with the "close" connection option of the "<xref target="header.connection" format="none">Connection</xref>"
    3494    header field (<xref target="header.connection"/>).
     3420   conflict with the "close" connection option of the <xref target="header.connection" format="none">Connection</xref> header field (<xref target="header.connection"/>).
    34953421</t>
    34963422<texttable align="left" suppress-title="true">
     
    35153441<t>
    35163442   IANA maintains the registry of URI Schemes <xref target="BCP115"/> at
    3517    &lt;http://www.iana.org/assignments/uri-schemes/&gt;.
    3518 </t>
    3519 <t>
    3520    This document defines the following URI schemes, so the
    3521    "Permanent URI Schemes" registry has been updated accordingly.
     3443   <eref target="http://www.iana.org/assignments/uri-schemes/"/>.
     3444</t>
     3445<t>
     3446   This document defines the following URI schemes, so the "Permanent URI
     3447   Schemes" registry has been updated accordingly.
    35223448</t>
    35233449<texttable align="left" suppress-title="true">
     
    35393465<t>
    35403466   IANA maintains the registry of Internet media types <xref target="BCP13"/> at
    3541    &lt;http://www.iana.org/assignments/media-types&gt;.
     3467   <eref target="http://www.iana.org/assignments/media-types"/>.
    35423468</t>
    35433469<t>
     
    35553481</t>
    35563482<t>
    3557 <!-- [rfced] http://www.iana.org/assignments/media-types/message/http includes
    3558 the following:
    3559 
    3560    (registered by RFC2616, last updated 2014-02-13)
    3561 
    3562 Does this text need to be updated?
    3563 -->
    3564 
    3565 
    35663483  <list style="hanging">
    35673484    <t hangText="Type name:">
     
    36163533    </t>
    36173534    <t hangText="Person and email address to contact for further information:">
    3618       See&nbsp;Authors'&nbsp;Addresses&nbsp; Section.
     3535      See&nbsp;Authors'&nbsp;Addresses&nbsp;Section.
    36193536    </t>
    36203537    <t hangText="Intended usage:">
     
    36413558</t>
    36423559<t>
    3643 <!-- [rfced] http://www.iana.org/assignments/media-types/application/http
    3644      includes the following:
    3645 
    3646    (registered by RFC2616, last updated 2014-02-13)
    3647 
    3648 Does this text need to be updated?
    3649 
    3650 -->
    3651 
    3652 
    36533560  <list style="hanging">
    36543561    <t hangText="Type name:">
     
    37273634<section title="Transfer Coding Registry" anchor="transfer.coding.registry">
    37283635<t>
    3729    The "HTTP Transfer Coding" registry defines the namespace for transfer
    3730    coding names. It is maintained at &lt;http://www.iana.org/assignments/http-parameters&gt;.
     3636   The "HTTP Transfer Coding Registry" defines the namespace for transfer
     3637   coding names. It is maintained at <eref target="http://www.iana.org/assignments/http-parameters"/>.
    37313638</t>
    37323639
     
    38053712<t>
    38063713   IANA maintains the "HTTP Content Coding Registry" at
    3807    &lt;http://www.iana.org/assignments/http-parameters&gt;.
    3808 </t>
    3809 <t>
    3810    The "HTTP Content Codings Registry" has been updated with the registrations
     3714   <eref target="http://www.iana.org/assignments/http-parameters"/>.
     3715</t>
     3716<t>
     3717   The "HTTP Content Coding Registry" has been updated with the registrations
    38113718   below:
    38123719</t>
     
    38483755   The "Hypertext Transfer Protocol (HTTP) Upgrade Token Registry" defines the namespace for protocol-name
    38493756   tokens used to identify protocols in the <xref target="header.upgrade" format="none">Upgrade</xref> header
    3850    field. The registry is maintained at &lt;http://www.iana.org/assignments/http-upgrade-tokens&gt;.
     3757   field. The registry is maintained at <eref target="http://www.iana.org/assignments/http-upgrade-tokens"/>.
    38513758</t>
    38523759
     
    38863793<section title="Upgrade Token Registration" anchor="upgrade.token.registration">
    38873794<t>
    3888    The "HTTP" entry in the "HTTP Upgrade Token" registry shall be updated with
     3795   The "HTTP" entry in the upgrade token registry has been updated with
    38893796   the registration below:
    38903797</t>
     
    39503857   (DNS), and the hierarchy of servers from which it obtains resolution
    39513858   results, could impact the authenticity of address mappings;
    3952    DNS Security Extensions (DNSSEC) (<xref target="RFC4033"/>) is one way to improve authenticity.
     3859   DNS Security Extensions (DNSSEC, <xref target="RFC4033"/>) are one way to
     3860   improve authenticity.
    39533861</t>
    39543862<t>
     
    41064014   information needs to indicate to the user when such information is detected
    41074015   by the protocol to be incomplete, expired, or corrupted during transfer.
    4108    Such mechanisms might be selectively enabled via user-agent extensions or
     4016   Such mechanisms might be selectively enabled via user agent extensions or
    41094017   the presence of message integrity metadata in a response.
    41104018   At a minimum, user agents ought to provide some indication that allows a
     
    45234431</reference>
    45244432
    4525 
    4526 <!--draft-ietf-httpbis-p5-range-26; Companion Doc; RFC 7233  -->
    4527 <!-- [rfced] RFC 7233 is not cited in the body of the document, except in the
    4528 Introduction.  Should this document be mentioned elsewhere, or should the list
    4529 of documents making up HTTP/1.1 be turned into citations?
    4530 
    4531 From the intro:
    4532 
    4533 This document is the
    4534    first in a series of documents that collectively form the HTTP/1.1
    4535    specification:
    4536 
    4537       RFC 7230: Message Syntax and Routing
    4538       RFC 7231: Semantics and Content
    4539       RFC 7232: Conditional Requests
    4540       RFC 7233: Range Requests
    4541       RFC 7234: Caching
    4542       RFC 7235: Authentication
    4543 -->
    4544 
    45454433<reference anchor="RFC7233">
    45464434  <front>
     
    46704558</reference>
    46714559
    4672 <reference anchor="RFC793">
     4560<reference anchor="RFC0793">
    46734561  <front>
    46744562    <title>Transmission Control Protocol</title>
     
    47484636  <front>
    47494637    <title>A Technique for High-Performance Data Compression</title>
    4750     <author initials="T.A." surname="Welch" fullname="Terry A. Welch"/>
     4638    <author initials="T. A." surname="Welch" fullname="Terry A. Welch"/>
    47514639    <date month="June" year="1984"/>
    47524640  </front>
     
    52925180<section title="Changes from RFC 2616" anchor="changes.from.rfc.2616">
    52935181<t>
    5294   HTTP's approach to error handling has been explained
    5295   (<xref target="conformance"/>).
    5296 </t>
    5297 <t>
    5298   The HTTP-version ABNF production has been clarified to be case sensitive.
     5182  HTTP's approach to error handling has been explained.
     5183  (<xref target="conformance"/>)
     5184</t>
     5185<t>
     5186  The HTTP-version ABNF production has been clarified to be case-sensitive.
    52995187  Additionally, version numbers have been restricted to single digits, due
    53005188  to the fact that implementations are known to handle multi-digit version
    5301   numbers incorrectly
    5302   (<xref target="http.version"/>).
     5189  numbers incorrectly.
     5190  (<xref target="http.version"/>)
    53035191</t>
    53045192<t>
    53055193  Userinfo (i.e., username and password) are now disallowed in HTTP and
    53065194  HTTPS URIs, because of security issues related to their transmission on the
    5307   wire
    5308   (<xref target="http.uri"/>).
     5195  wire.
     5196  (<xref target="http.uri"/>)
    53095197</t>
    53105198<t>
    53115199  The HTTPS URI scheme is now defined by this specification; previously,
    5312   it was defined in Section 2.4 of <xref target="RFC2818"/>.
    5313   Furthermore, it implies end-to-end security
    5314   (<xref target="https.uri"/>).
     5200  it was done in Section 2.4 of <xref target="RFC2818"/>.
     5201  Furthermore, it implies end-to-end security.
     5202  (<xref target="https.uri"/>)
    53155203</t>
    53165204<t>
     
    53195207  message-oriented protocol.
    53205208  Minimum supported sizes for various protocol elements have been
    5321   suggested, to improve interoperability
    5322   (<xref target="http.message"/>).
     5209  suggested, to improve interoperability.
     5210  (<xref target="http.message"/>)
    53235211</t>
    53245212<t>
    53255213  Invalid whitespace around field-names is now required to be rejected,
    53265214  because accepting it represents a security vulnerability.
    5327   The ABNF productions defining header fields now only list the field value
    5328   (<xref target="header.fields"/>).
     5215  The ABNF productions defining header fields now only list the field value.
     5216  (<xref target="header.fields"/>)
    53295217</t>
    53305218<t>
    53315219  Rules about implicit linear whitespace between certain grammar productions
    53325220  have been removed; now whitespace is only allowed where specifically
    5333   defined in the ABNF
    5334   (<xref target="whitespace"/>).
    5335 </t>
    5336 <t>
    5337   Header fields that span multiple lines ("line folding") are deprecated
    5338   (<xref target="field.parsing"/>).
     5221  defined in the ABNF.
     5222  (<xref target="whitespace"/>)
     5223</t>
     5224<t>
     5225  Header fields that span multiple lines ("line folding") are deprecated.
     5226  (<xref target="field.parsing"/>)
    53395227</t>
    53405228<t> 
     
    53445232  HTAB.
    53455233  Non-US-ASCII content in header fields and the reason phrase has been obsoleted
    5346   and made opaque (the TEXT rule was removed)
    5347   (<xref target="field.components"/>).
     5234  and made opaque (the TEXT rule was removed).
     5235  (<xref target="field.components"/>)
    53485236</t> 
    53495237<t>
    5350   Bogus "<xref target="header.content-length" format="none">Content-Length</xref>" header fields are now required to be
    5351   handled as errors by recipients
    5352   (<xref target="header.content-length"/>).
     5238  Bogus <xref target="header.content-length" format="none">Content-Length</xref> header fields are now required to be
     5239  handled as errors by recipients.
     5240  (<xref target="header.content-length"/>)
    53535241</t>
    53545242<t>
     
    53595247  CONNECT is a new, special case in determining message body length.
    53605248  "multipart/byteranges" is no longer a way of determining message body length
    5361   detection
    5362   (<xref target="message.body.length"/>).
    5363 </t>
    5364 <t>
    5365   The "identity" transfer coding token has been removed
     5249  detection.
     5250  (<xref target="message.body.length"/>)
     5251</t>
     5252<t>
     5253  The "identity" transfer coding token has been removed.
    53665254  (Sections <xref format="counter" target="message.body"/> and
    5367   <xref format="counter" target="transfer.codings"/>).
     5255  <xref format="counter" target="transfer.codings"/>)
    53685256</t>
    53695257<t>
    53705258  Chunk length does not include the count of the octets in the
    53715259  chunk header and trailer.
    5372   Line folding in chunk extensions is  disallowed
    5373   (<xref target="chunked.encoding"/>).
    5374 </t>
    5375 <t>
    5376   The meaning of the "deflate" content coding has been clarified
    5377   (<xref target="deflate.coding"/>).
     5260  Line folding in chunk extensions is  disallowed.
     5261  (<xref target="chunked.encoding"/>)
     5262</t>
     5263<t>
     5264  The meaning of the "deflate" content coding has been clarified.
     5265  (<xref target="deflate.coding"/>)
    53785266</t>
    53795267<t>
     
    53815269  request-target, instead of abs_path from RFC 1808.
    53825270  The asterisk-form of the request-target is only allowed with the OPTIONS
    5383   method
    5384   (<xref target="request-target"/>).
    5385 </t>
    5386 <t>
    5387   The term "Effective Request URI" has been introduced
    5388   (<xref target="effective.request.uri"/>).
    5389 </t>
    5390 <t>
    5391   Gateways do not need to generate <xref target="header.via" format="none">Via</xref> header fields anymore
    5392   (<xref target="header.via"/>).
     5271  method.
     5272  (<xref target="request-target"/>)
     5273</t>
     5274<t>
     5275  The term "Effective Request URI" has been introduced.
     5276  (<xref target="effective.request.uri"/>)
     5277</t>
     5278<t>
     5279  Gateways do not need to generate <xref target="header.via" format="none">Via</xref> header fields anymore.
     5280  (<xref target="header.via"/>)
    53935281</t>
    53945282<t>
     
    53965284  Also, "hop-by-hop" header fields are required to appear in the Connection header
    53975285  field; just because they're defined as hop-by-hop in this specification
    5398   doesn't exempt them
    5399   (<xref target="header.connection"/>).
     5286  doesn't exempt them.
     5287  (<xref target="header.connection"/>)
    54005288</t>
    54015289<t>
     
    54055293  server prematurely closes the connection has been removed.
    54065294  Also, some extraneous requirements about when servers are allowed to close
    5407   connections prematurely have been removed
    5408   (<xref target="persistent.connections"/>).
     5295  connections prematurely have been removed.
     5296  (<xref target="persistent.connections"/>)
    54095297</t>
    54105298<t>
    54115299  The semantics of the <xref target="header.upgrade" format="none">Upgrade</xref> header field is now defined in
    54125300  responses other than 101 (this was incorporated from <xref target="RFC2817"/>). Furthermore, the ordering in the field value is now
    5413   significant
    5414   (<xref target="header.upgrade"/>).
     5301  significant.
     5302  (<xref target="header.upgrade"/>)
    54155303</t>
    54165304<t>
    54175305  Empty list elements in list productions (e.g., a list header field containing
    5418   ", ,") have been deprecated
    5419   (<xref target="abnf.extension"/>).
     5306  ", ,") have been deprecated.
     5307  (<xref target="abnf.extension"/>)
    54205308</t>
    54215309<t>
    54225310  Registration of Transfer Codings now requires IETF Review
    5423   (<xref target="transfer.coding.registry"/>).
    5424 </t>
    5425 <t>
    5426   This specification now defines the "HTTP Upgrade Tokens" registry, previously
    5427   defined in Section 7.2 of <xref target="RFC2817"/>
    5428   (<xref target="upgrade.token.registry"/>).
    5429 </t>
    5430 <t>
    5431   The expectation to support HTTP/0.9 requests has been removed
    5432   (<xref target="compatibility"/>).
     5311  (<xref target="transfer.coding.registry"/>)
     5312</t>
     5313<t>
     5314  This specification now defines the Upgrade Token Registry, previously
     5315  defined in Section 7.2 of <xref target="RFC2817"/>.
     5316  (<xref target="upgrade.token.registry"/>)
     5317</t>
     5318<t>
     5319  The expectation to support HTTP/0.9 requests has been removed.
     5320  (<xref target="compatibility"/>)
    54335321</t>
    54345322<t>
    54355323  Issues with the Keep-Alive and Proxy-Connection header fields in requests
    5436   are pointed out, with use of the latter being discouraged altogether
    5437   (<xref target="compatibility.with.http.1.0.persistent.connections"/>).
     5324  are pointed out, with use of the latter being discouraged altogether.
     5325  (<xref target="compatibility.with.http.1.0.persistent.connections"/>)
    54385326</t>
    54395327</section>
     
    55605448</section>
    55615449
    5562 
    5563 
    55645450</back>
    55655451</rfc>
  • draft-ietf-httpbis/latest/auth48/rfc7230.abdiff.txt

    r2663 r2665  
    232232        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
    233233        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
    234         3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 25
     234        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 24
    235235        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
    236236        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
    237237      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
    238238        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
    239         3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 30
     239        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 29
    240240        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
    241241      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
    242242      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
    243     4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 35
     243    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34
    244244      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
    245245        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
    246246        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
    247247        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
    248       4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 38
     248      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 37
    249249        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
    250250        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
     
    252252      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
    253253      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
    254     5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 40
     254    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 39
    255255      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
    256256      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
    257257      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
    258258        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
    259         5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 42
     259        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 41
    260260        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
    261261        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
     
    264264      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
    265265      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
    266         5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 47
     266        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 46
    267267        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
    268268    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
    269269      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
    270270      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
    271       6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 52
    272         6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 53
     271      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 51
     272        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
    273273        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
    274274      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
    275275      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
    276       6.6.  Teardown . . . . . . . . . . . . . . . . . . . . . . . . . 55
     276      6.6.  Tear-down . . . . . . . . . . . . . . . . . . . . . . . . 55
    277277      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
    278278    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
    279     8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 60
    280       8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 60
     279    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 59
     280      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
    281281      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
    282       8.3.  Internet Media Type Registration . . . . . . . . . . . . . 61
     282      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
    283283        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
    284284        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
     
    287287        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
    288288      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
    289       8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 65
     289      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64
    290290        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
    291         8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 66
     291        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
    292292    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
    293293      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
    294294      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
    295       9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 68
     295      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 67
    296296      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
    297297      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
    298298      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
    299       9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 70
     299      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
    300300      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
    301     10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 71
     301    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
    302302    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
    303303      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
    304       11.2. Informative References . . . . . . . . . . . . . . . . . . 74
    305     Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 76
     304      11.2. Informative References . . . . . . . . . . . . . . . . . . 73
     305    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
    306306      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
    307         A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 77
    308         A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77
    309         A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 78
    310       A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 78
    311     Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80
     307        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 76
     308        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 76
     309        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
     310      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
     311    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 79
    312312    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
    313 
    314 
    315 Section 1., paragraph 2:
    316 OLD:
    317 
    318     1.  "Message Syntax and Routing" (this document)
    319 
    320 NEW:
    321 
    322        RFC 7230: Message Syntax and Routing
    323 
    324 
    325 Section 1., paragraph 3:
    326 OLD:
    327 
    328     2.  "Semantics and Content" [RFC7231]
    329 
    330 NEW:
    331 
    332        RFC 7231: Semantics and Content
    333 
    334 
    335 Section 1., paragraph 4:
    336 OLD:
    337 
    338     3.  "Conditional Requests" [RFC7232]
    339 
    340 NEW:
    341 
    342        RFC 7232: Conditional Requests
    343 
    344 
    345 Section 1., paragraph 5:
    346 OLD:
    347 
    348     4.  "Range Requests" [RFC7233]
    349 
    350 NEW:
    351 
    352        RFC 7233: Range Requests
    353 
    354 
    355 Section 1., paragraph 6:
    356 OLD:
    357 
    358     5.  "Caching" [RFC7234]
    359 
    360 NEW:
    361 
    362        RFC 7234: Caching
    363 
    364 
    365 Section 1., paragraph 7:
    366 OLD:
    367 
    368     6.  "Authentication" [RFC7235]
    369 
    370 NEW:
    371 
    372        RFC 7235: Authentication
    373 
    374 
    375 Section 1., paragraph 8:
    376 OLD:
    377 
    378     This HTTP/1.1 specification obsoletes RFC 2616 and RFC 2145 (on HTTP
    379     versioning).  This specification also updates the use of CONNECT to
    380     establish a tunnel, previously defined in RFC 2817, and defines the
    381     "https" URI scheme that was described informally in RFC 2818.
    382 
    383 NEW:
    384 
    385     This HTTP/1.1 specification obsoletes [RFC2616] and [RFC2145] (on
    386     HTTP versioning).  This specification also updates the use of
    387     CONNECT, previously defined in RFC 2817, to establish a tunnel, and
    388     defines the "https" URI scheme that was described informally in RFC
    389     2818.
    390 
    391 
    392 Section 2.3., paragraph 7:
    393 OLD:
    394 
    395     All HTTP requirements applicable to an origin server also apply to
    396     the outbound communication of a gateway.  A gateway communicates with
    397     inbound servers using any protocol that it desires, including private
    398     extensions to HTTP that are outside the scope of this specification.
    399     However, an HTTP-to-HTTP gateway that wishes to interoperate with
    400     third-party HTTP servers ought to conform to user agent requirements
    401     on the gateway's inbound connection.
    402 
    403 NEW:
    404 
    405     All HTTP requirements applicable to an origin server also apply to
    406     the outbound communication of a gateway.  A gateway communicates with
    407     inbound servers using any protocol that it desires, including private
    408     extensions to HTTP that are outside the scope of this specification.
    409     However, an HTTP-to-HTTP gateway that wishes to interoperate with
    410     third-party HTTP servers ought to conform to user-agent requirements
    411     on the gateway's inbound connection.
    412 
    413 
    414 Section 2.6., paragraph 2:
    415 OLD:
    416 
    417     The version of an HTTP message is indicated by an HTTP-version field
    418     in the first line of the message.  HTTP-version is case-sensitive.
    419 
    420 NEW:
    421 
    422     The version of an HTTP message is indicated by an HTTP-version field
    423     in the first line of the message.  HTTP-version is case sensitive.
    424 
    425 
    426 Section 2.6., paragraph 3:
    427 OLD:
    428 
    429       HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
    430       HTTP-name     = %x48.54.54.50 ; "HTTP", case-sensitive
    431 
    432 NEW:
    433 
    434       HTTP-version  = HTTP-name "/" DIGIT "." DIGIT
    435       HTTP-name     = %x48.54.54.50 ; "HTTP", case sensitive
    436 
    437 
    438 Section 2.6., paragraph 7:
    439 OLD:
    440 
    441     New header fields can be introduced without changing the protocol
    442     version if their defined semantics allow them to be safely ignored by
    443     recipients that do not recognize them.  Header field extensibility is
    444     discussed in Section 3.2.1.
    445 
    446 NEW:
    447 
    448     New header fields can be introduced without changing the protocol
    449     version if their defined semantics allow them to be safely ignored by
    450     recipients that do not recognize them.  Header-field extensibility is
    451     discussed in Section 3.2.1.
    452 
    453 
    454 Section 2.6., paragraph 14:
    455 OLD:
    456 
    457     When an HTTP message is received with a major version number that the
    458     recipient implements, but a higher minor version number than what the
    459     recipient implements, the recipient SHOULD process the message as if
    460     it were in the highest minor version within that major version to
    461     which the recipient is conformant.  A recipient can assume that a
    462     message with a higher minor version, when sent to a recipient that
    463     has not yet indicated support for that higher version, is
    464     sufficiently backwards-compatible to be safely processed by any
    465     implementation of the same major version.
    466 
    467 NEW:
    468 
    469     When an HTTP message is received with a major version number that the
    470     recipient implements, but a higher minor version number than what the
    471     recipient implements, the recipient SHOULD process the message as if
    472     it were in the highest minor version within that major version to
    473     which the recipient is conformant.  A recipient can assume that a
    474     message with a higher minor version, when sent to a recipient that
    475     has not yet indicated support for that higher version, is
    476     sufficiently backwards compatible to be safely processed by any
    477     implementation of the same major version.
    478 
    479 
    480 Section 2.7.1., paragraph 1:
    481 OLD:
    482 
    483     The "http" URI scheme is hereby defined for the purpose of minting
    484     identifiers according to their association with the hierarchical
    485     namespace governed by a potential HTTP origin server listening for
    486     TCP ([RFC0793]) connections on a given port.
    487 
    488 NEW:
    489 
    490     The "http" URI scheme is hereby defined for the purpose of minting
    491     identifiers according to their association with the hierarchical
    492     namespace governed by a potential HTTP origin server listening for
    493     TCP ([RFC793]) connections on a given port.
    494 
    495 
    496 Section 2.1, paragraph 0:
    497 OLD:
    498 
    499     If the port is equal to the default port for a scheme, the normal
    500     form is to omit the port subcomponent.  When not being used in
    501     absolute form as the request target of an OPTIONS request, an empty
    502     path component is equivalent to an absolute path of "/", so the
    503     normal form is to provide a path of "/" instead.  The scheme and host
    504     are case-insensitive and normally provided in lowercase; all other
    505     components are compared in a case-sensitive manner.  Characters other
    506     than those in the "reserved" set are equivalent to their percent-
    507     encoded octets: the normal form is to not encode them (see Sections
    508     2.1 and 2.2 of [RFC3986]).
    509 
    510 NEW:
    511 
    512     If the port is equal to the default port for a scheme, the normal
    513     form is to omit the port subcomponent.  When not being used in
    514     absolute form as the request target of an OPTIONS request, an empty
    515     path component is equivalent to an absolute path of "/", so the
    516     normal form is to provide a path of "/" instead.  The scheme and host
    517     are case insensitive and normally provided in lowercase; all other
    518     components are compared in a case-sensitive manner.  Characters other
    519     than those in the "reserved" set are equivalent to their percent-
    520     encoded octets: the normal form is to not encode them (see Sections
    521     2.1 and 2.2 of [RFC3986]).
    522 
    523 
    524 Section 3.1., paragraph 2:
    525 OLD:
    526 
    527     In theory, a client could receive requests and a server could receive
    528     responses, distinguishing them by their different start-line formats,
    529     but, in practice, servers are implemented to only expect a request (a
    530     response is interpreted as an unknown or invalid request method) and
    531     clients are implemented to only expect a response.
    532 
    533 NEW:
    534 
    535     In theory, a client could receive requests and a server could receive
    536     responses, distinguishing them by their different start-line formats,
    537     but, in practice, servers are implemented only to expect a request (a
    538     response is interpreted as an unknown or invalid request method) and
    539     clients are implemented to only expect a response.
    540 
    541 
    542 Section 3.1.1., paragraph 1:
    543 OLD:
    544 
    545     A request-line begins with a method token, followed by a single space
    546     (SP), the request-target, another single space (SP), the protocol
    547     version, and ends with CRLF.
    548 
    549 NEW:
    550 
    551     A request-line begins with a method token and is followed by a single
    552     space (SP), the request-target, another single space (SP), the
    553     protocol version, and ends with CRLF.
    554 
    555 
    556 Section 3.1.1., paragraph 3:
    557 OLD:
    558 
    559     The method token indicates the request method to be performed on the
    560     target resource.  The request method is case-sensitive.
    561 
    562 NEW:
    563 
    564     The method token indicates the request method to be performed on the
    565     target resource.  The request method is case sensitive.
    566 
    567 
    568 Section 3.1.2., paragraph 1:
    569 OLD:
    570 
    571     The first line of a response message is the status-line, consisting
    572     of the protocol version, a space (SP), the status code, another
    573     space, a possibly empty textual phrase describing the status code,
    574     and ending with CRLF.
    575 
    576 NEW:
    577 
    578     The first line of a response message is the status-line, consisting
    579     of the protocol version, a space (SP), the status code, another space
    580     (SP), a possibly empty textual phrase describing the status code,
    581     and, finally, CRLF.
    582 
    583 
    584 Section 3.2.1., paragraph 4:
    585 OLD:
    586 
    587     All defined header fields ought to be registered with IANA in the
    588     "Message Headers" registry, as described in Section 8.3 of [RFC7231].
    589 
    590 NEW:
    591 
    592     All defined header fields ought to be registered with IANA in the
    593     "Message Headers" field registry, as described in Section 8.3 of
    594     [RFC7231].
    595 
    596 
    597 Section 3.2.2., paragraph 4:
    598 OLD:
    599 
    600        Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
    601        appears multiple times in a response message and does not use the
    602        list syntax, violating the above requirements on multiple header
    603        fields with the same name.  Since it cannot be combined into a
    604        single field-value, recipients ought to handle "Set-Cookie" as a
    605        special case while processing header fields.  (See Appendix A.2.3
    606        of [Kri2001] for details.)
    607 
    608 NEW:
    609 
    610        Note: In practice, the "Set-Cookie" header field ([RFC6265]) often
    611        appears multiple times in a response message and does not use the
    612        list syntax, violating the above requirements on multiple header
    613        fields with the same name.  Since it cannot be combined into a
    614        single field-value, recipients ought to handle Set-Cookie as a
    615        special case while processing header fields.  (See Appendix A.2.3
    616        of [Kri2001] for details.)
    617 
    618 
    619 Section 3.2.4., paragraph 1:
    620 OLD:
    621 
    622     Messages are parsed using a generic algorithm, independent of the
    623     individual header field names.  The contents within a given field
    624     value are not parsed until a later stage of message interpretation
    625     (usually after the message's entire header section has been
    626     processed).  Consequently, this specification does not use ABNF rules
    627     to define each "Field-Name: Field Value" pair, as was done in
    628     previous editions.  Instead, this specification uses ABNF rules that
    629     are named according to each registered field name, wherein the rule
    630     defines the valid grammar for that field's corresponding field values
    631     (i.e., after the field-value has been extracted from the header
    632     section by a generic field parser).
    633 
    634 NEW:
    635 
    636     Messages are parsed using a generic algorithm, independent of the
    637     individual header field names.  The contents within a given field
    638     value are not parsed until a later stage of message interpretation
    639     (usually after the message's entire header section has been
    640     processed).  Consequently, this specification does not use ABNF rules
    641     to define each "field-name: field-value" pair, as was done in
    642     previous editions.  Instead, this specification uses ABNF rules that
    643     are named according to each registered field name, wherein the rule
    644     defines the valid grammar for that field's corresponding field values
    645     (i.e., after the field-value has been extracted from the header
    646     section by a generic field parser).
    647313
    648314
     
    661327
    662328    Historically, HTTP has allowed field content with text in the
    663     ISO-8859-1 [ISO-8859-1] charset, supporting other charsets only
    664     through use of [RFC2047] encoding.  In practice, most HTTP header
    665     field values use only a subset of the US-ASCII charset [USASCII].
    666     Newly defined header fields SHOULD limit their field values to
    667     US-ASCII octets.  A recipient SHOULD treat other octets in field
    668     content (obs-text) as opaque data.
    669 
    670 
    671 Section 4., paragraph 5:
    672 OLD:
    673 
    674     All transfer-coding names are case-insensitive and ought to be
    675     registered within the HTTP Transfer Coding registry, as defined in
    676     Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
    677     Encoding (Section 3.3.1) header fields.
    678 
    679 NEW:
    680 
    681     All transfer-coding names are case insensitive and ought to be
    682     registered within the "HTTP Transfer Coding" registry, as defined in
    683     Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
    684     Encoding (Section 3.3.1) header fields.
    685 
    686 
    687 Section 5.3.4., paragraph 3:
    688 OLD:
    689 
    690     When a client wishes to request OPTIONS for the server as a whole, as
    691     opposed to a specific named resource of that server, the client MUST
    692     send only "*" (%x2A) as the request-target.  For example,
    693  
    694       OPTIONS * HTTP/1.1
    695 
    696 NEW:
    697 
    698     When a client wishes to request OPTIONS for the server as a whole, as
    699     opposed to a specific named resource of that server, the client MUST
    700     send only "*" (%x2A) as the request-target.  For example,
    701       OPTIONS * HTTP/1.1
     329    ISO-8859-charset [ISO-8859-1], supporting other charsets only through
     330    use of [RFC2047] encoding.  In practice, most HTTP header field
     331    values use only a subset of the US-ASCII charset [USASCII].  Newly
     332    defined header fields SHOULD limit their field values to US-ASCII
     333    octets.  A recipient SHOULD treat other octets in field content
     334    (obs-text) as opaque data.
     335
     336
     337Section 3.3., paragraph 4:
     338OLD:
     339
     340    The presence of a message body in a request is signaled by a Content-
     341    Length or Transfer-Encoding header field.  Request message framing is
     342    independent of method semantics, even if the method does not define
     343    any use for a message body.
     344
     345NEW:
     346
     347    The presence of a message body in a request is signaled by a
     348    "Content-Length" or Transfer-Encoding header field.  Request message
     349    framing is independent of method semantics, even if the method does
     350    not define any use for a message body.
    702351
    703352
     
    740389
    741390
    742 Section 6.1., paragraph 6:
    743 OLD:
    744 
    745     Connection options are case-insensitive.
    746 
    747 NEW:
    748 
    749     Connection options are case insensitive.
    750 
    751 
    752 Section 6.5., paragraph 6:
    753 OLD:
    754 
    755  6.6.  Tear-down
    756 
    757 NEW:
    758 
    759  6.6.  Teardown
    760 
    761 
    762 Section 6.5., paragraph 8:
    763 OLD:
    764 
    765     A client that sends a "close" connection option MUST NOT send further
    766     requests on that connection (after the one containing "close") and
    767     MUST close the connection after reading the final response message
    768     corresponding to this request.
    769 
    770 NEW:
    771 
    772     A client that sends a "close" connection option MUST NOT send further
    773     requests on that connection (after the one containing close) and MUST
    774     close the connection after reading the final response message
    775     corresponding to this request.
    776 
    777 
    778 Section 6.5., paragraph 9:
    779 OLD:
    780 
    781     A server that receives a "close" connection option MUST initiate a
    782     close of the connection (see below) after it sends the final response
    783     to the request that contained "close".  The server SHOULD send a
    784     "close" connection option in its final response on that connection.
    785     The server MUST NOT process any further requests received on that
    786     connection.
    787 
    788 NEW:
    789 
    790     A server that receives a "close" connection option MUST initiate a
    791     close of the connection (see below) after it sends the final response
    792     to the request that contained close.  The server SHOULD send a close
    793     connection option in its final response on that connection.  The
    794     server MUST NOT process any further requests received on that
    795     connection.
    796 
    797 
    798 Section 6.5., paragraph 10:
    799 OLD:
    800 
    801     A server that sends a "close" connection option MUST initiate a close
    802     of the connection (see below) after it sends the response containing
    803     "close".  The server MUST NOT process any further requests received
    804     on that connection.
    805 
    806 NEW:
    807 
    808     A server that sends a "close" connection option MUST initiate a close
    809     of the connection (see below) after it sends the response containing
    810     close.  The server MUST NOT process any further requests received on
    811     that connection.
    812 
    813 
    814 Section 6.5., paragraph 11:
    815 OLD:
    816 
    817     A client that receives a "close" connection option MUST cease sending
    818     requests on that connection and close the connection after reading
    819     the response message containing the "close"; if additional pipelined
    820     requests had been sent on the connection, the client SHOULD NOT
    821     assume that they will be processed by the server.
    822 
    823 NEW:
    824 
    825     A client that receives a "close" connection option MUST cease sending
    826     requests on that connection and close the connection after reading
    827     the response message containing the close; if additional pipelined
    828     requests had been sent on the connection, the client SHOULD NOT
    829     assume that they will be processed by the server.
    830 
    831 
    832 Section 7., paragraph 14:
    833 OLD:
    834 
    835     Then the following are valid values for example-list (not including
    836     the double quotes, which are present for delimitation only):
    837 
    838 NEW:
    839 
    840     Then, the following are valid values for example-list (not including
    841     the double quotes, which are present for delimitation only):
    842 
    843 
    844 Section 8.1., paragraph 1:
    845 OLD:
    846 
    847     HTTP header fields are registered within the "Message Headers"
    848     registry maintained at
    849     <http://www.iana.org/assignments/message-headers/>.
    850 
    851 NEW:
    852 
    853     HTTP header fields are registered within the "Message Header" field
    854     registry maintained at
    855     <http://www.iana.org/assignments/message-headers/>.
    856 
    857 
    858 Section 8.3.1., paragraph 10:
    859 OLD:
    860 
    861     Interoperability considerations:  N/A
    862  
    863     Published specification:  This specification (see Section 8.3.1).
    864 
    865 NEW:
    866 
    867     Interoperability considerations:  N/A
    868     Published specification:  This specification (see Section 8.3.1).
    869 
    870 
    871 Section 8.3.1., paragraph 16:
    872 OLD:
    873 
    874        File extension(s):  N/A
    875        Macintosh file type code(s):  N/A
    876 
    877 NEW:
    878 
    879        File extension(s):  N/A
    880  
    881        Macintosh file type code(s):  N/A
    882 
    883 
    884 Section 8.3.2., paragraph 12:
    885 OLD:
    886 
    887     Applications that use this media type:  N/A
    888     Fragment identifier considerations:  N/A
    889 
    890 NEW:
    891 
    892     Applications that use this media type:  N/A
    893  
    894     Fragment identifier considerations:  N/A
    895 
    896 
    897 Section 8.4., paragraph 1:
    898 OLD:
    899 
    900     The "HTTP Transfer Coding Registry" defines the namespace for
    901     transfer coding names.  It is maintained at
    902     <http://www.iana.org/assignments/http-parameters>.
    903 
    904 NEW:
    905 
    906     The "HTTP Transfer Coding" registry defines the namespace for
    907     transfer coding names.  It is maintained at
    908     <http://www.iana.org/assignments/http-parameters>.
    909 
    910 
    911 Section 8.4.1., paragraph 2:
    912 OLD:
    913 
    914     o  Name
    915  
    916     o  Description
    917 
    918 NEW:
    919 
    920     o  Name
    921     o  Description
    922 
    923 
    924 Section 8.5., paragraph 2:
    925 OLD:
    926 
    927     The "HTTP Content Coding Registry" has been updated with the
    928     registrations below:
    929 
    930 NEW:
    931 
    932     The "HTTP Content Codings Registry" has been updated with the
    933     registrations below:
    934 
    935 
    936 Section 8.6.2., paragraph 1:
    937 OLD:
    938 
    939     The "HTTP" entry in the upgrade token registry has been updated with
    940     the registration below:
    941 
    942 NEW:
    943 
    944     The "HTTP" entry in the "HTTP Upgrade Token" registry shall be
    945     updated with the registration below:
    946 
    947 
    948 Section 9.1., paragraph 3:
    949 OLD:
    950 
    951     When a registered name is used in the authority component, the "http"
    952     URI scheme (Section 2.7.1) relies on the user's local name resolution
    953     service to determine where it can find authoritative responses.  This
    954     means that any attack on a user's network host table, cached names,
    955     or name resolution libraries becomes an avenue for attack on
    956     establishing authority.  Likewise, the user's choice of server for
    957     Domain Name Service (DNS), and the hierarchy of servers from which it
    958     obtains resolution results, could impact the authenticity of address
    959     mappings; DNS Security Extensions (DNSSEC, [RFC4033]) are one way to
    960     improve authenticity.
    961 
    962 NEW:
    963 
    964     When a registered name is used in the authority component, the "http"
    965     URI scheme (Section 2.7.1) relies on the user's local name resolution
    966     service to determine where it can find authoritative responses.  This
    967     means that any attack on a user's network host table, cached names,
    968     or name resolution libraries becomes an avenue for attack on
    969     establishing authority.  Likewise, the user's choice of server for
    970     Domain Name Service (DNS), and the hierarchy of servers from which it
    971     obtains resolution results, could impact the authenticity of address
    972     mappings; DNS Security Extensions (DNSSEC) ([RFC4033]) is one way to
    973     improve authenticity.
     391Section 6.1., paragraph 2:
     392OLD:
     393
     394    When a header field aside from Connection is used to supply control
     395    information for or about the current connection, the sender MUST list
     396    the corresponding field-name within the "Connection" header field.  A
     397    proxy or gateway MUST parse a received Connection header field before
     398    a message is forwarded and, for each connection-option in this field,
     399    remove any header field(s) from the message with the same name as the
     400    connection-option, and then remove the Connection header field itself
     401    (or replace it with the intermediary's own connection options for the
     402    forwarded message).
     403
     404NEW:
     405
     406    When a header field aside from Connection is used to supply control
     407    information for or about the current connection, the sender MUST list
     408    the corresponding field-name within the Connection header field.  A
     409    proxy or gateway MUST parse a received Connection header field before
     410    a message is forwarded and, for each connection-option in this field,
     411    remove any header field(s) from the message with the same name as the
     412    connection-option, and then remove the Connection header field itself
     413    (or replace it with the intermediary's own connection options for the
     414    forwarded message).
     415
     416
     417Section 8.1., paragraph 4:
     418OLD:
     419
     420    Furthermore, the header field-name "Close" has been registered as
     421    "reserved", since using that name as an HTTP header field might
     422    conflict with the "close" connection option of the "Connection"
     423    header field (Section 6.1).
     424
     425NEW:
     426
     427    Furthermore, the header field-name "Close" has been registered as
     428    "reserved", since using that name as an HTTP header field might
     429    conflict with the "close" connection option of the Connection header
     430    field (Section 6.1).
    974431
    975432
     
    1002459
    1003460
    1004 Section 9.6., paragraph 2:
    1005 OLD:
    1006 
    1007     User agents are encouraged to implement configurable means for
    1008     detecting and reporting failures of message integrity such that those
    1009     means can be enabled within environments for which integrity is
    1010     necessary.  For example, a browser being used to view medical history
    1011     or drug interaction information needs to indicate to the user when
    1012     such information is detected by the protocol to be incomplete,
    1013     expired, or corrupted during transfer.  Such mechanisms might be
    1014     selectively enabled via user agent extensions or the presence of
    1015     message integrity metadata in a response.  At a minimum, user agents
    1016     ought to provide some indication that allows a user to distinguish
    1017     between a complete and incomplete response message (Section 3.4) when
    1018     such verification is desired.
    1019 
    1020 NEW:
    1021 
    1022     User agents are encouraged to implement configurable means for
    1023     detecting and reporting failures of message integrity such that those
    1024     means can be enabled within environments for which integrity is
    1025     necessary.  For example, a browser being used to view medical history
    1026     or drug interaction information needs to indicate to the user when
    1027     such information is detected by the protocol to be incomplete,
    1028     expired, or corrupted during transfer.  Such mechanisms might be
    1029     selectively enabled via user-agent extensions or the presence of
    1030     message integrity metadata in a response.  At a minimum, user agents
    1031     ought to provide some indication that allows a user to distinguish
    1032     between a complete and incomplete response message (Section 3.4) when
    1033     such verification is desired.
    1034 
    1035 
    1036 Section 11.1., paragraph 1:
    1037 OLD:
    1038 
    1039     [RFC0793]     Postel, J., "Transmission Control Protocol", STD 7,
    1040                   RFC 793, September 1981.
    1041  
    1042     [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
    1043                   Format Specification version 3.3", RFC 1950, May 1996.
    1044 
    1045 NEW:
    1046 
    1047     [RFC1950]     Deutsch, L. and J-L. Gailly, "ZLIB Compressed Data
    1048                   Format Specification version 3.3", RFC 1950, May 1996.
    1049 
    1050 
    1051 Section 11.1., paragraph 7:
     461Section 11.1., paragraph 8:
    1052462OLD:
    1053463
     
    1064474
    1065475
    1066 Section 11.1., paragraph 8:
     476Section 11.1., paragraph 9:
    1067477OLD:
    1068478
     
    1079489
    1080490
    1081 Section 11.1., paragraph 9:
     491Section 11.1., paragraph 10:
    1082492OLD:
    1083493
     
    1094504
    1095505
    1096 Section 11.1., paragraph 10:
     506Section 11.1., paragraph 11:
    1097507OLD:
    1098508
     
    1109519
    1110520
    1111 Section 11.1., paragraph 11:
     521Section 11.1., paragraph 12:
    1112522OLD:
    1113523
     
    1122532                  Transfer Protocol (HTTP/1.1): Authentication",
    1123533                  RFC 7235, May 2014.
    1124  
    1125     [RFC793]      Postel, J., "Transmission Control Protocol", STD 7,
    1126                   RFC 793, September 1981.
    1127534
    1128535
     
    1135542
    1136543 A.1.1.  Multihomed Web Servers
    1137 
    1138 
    1139 Section 19.7.1, paragraph 8:
    1140 OLD:
    1141 
    1142     HTTP's approach to error handling has been explained.  (Section 2.5)
    1143 
    1144 NEW:
    1145 
    1146     HTTP's approach to error handling has been explained (Section 2.5).
    1147544
    1148545
     
    1160557NEW:
    1161558
    1162     The HTTP-version ABNF production has been clarified to be case
     559    The HTTP-version ABNF production has been clarified to be case-
    1163560    sensitive.  Additionally, version numbers have been restricted to
    1164561    single digits, due to the fact that implementations are known to
    1165     handle multi-digit version numbers incorrectly (Section 2.6).
     562    handle multi-digit version numbers incorrectly.  (Section 2.6)
    1166563 
    1167564    Userinfo (i.e., username and password) are now disallowed in HTTP and
    1168565    HTTPS URIs, because of security issues related to their transmission
    1169     on the wire (Section 2.7.1).
    1170 
    1171 
    1172 Section 19.7.1, paragraph 10:
    1173 OLD:
    1174 
    1175     The HTTPS URI scheme is now defined by this specification;
    1176     previously, it was done in Section 2.4 of [RFC2818].  Furthermore, it
    1177     implies end-to-end security.  (Section 2.7.2)
    1178 
    1179 NEW:
    1180 
    1181     The HTTPS URI scheme is now defined by this specification;
    1182     previously, it was defined in Section 2.4 of [RFC2818].  Furthermore,
    1183     it implies end-to-end security (Section 2.7.2).
    1184 
    1185 
    1186 Section 19.7.1, paragraph 11:
    1187 OLD:
    1188 
    1189     HTTP messages can be (and often are) buffered by implementations;
    1190     despite it sometimes being available as a stream, HTTP is
    1191     fundamentally a message-oriented protocol.  Minimum supported sizes
    1192     for various protocol elements have been suggested, to improve
    1193     interoperability.  (Section 3)
    1194 
    1195 NEW:
    1196 
    1197     HTTP messages can be (and often are) buffered by implementations;
    1198     despite it sometimes being available as a stream, HTTP is
    1199     fundamentally a message-oriented protocol.  Minimum supported sizes
    1200     for various protocol elements have been suggested, to improve
    1201     interoperability (Section 3).
    1202 
    1203 
    1204 Section 19.7.1, paragraph 12:
    1205 OLD:
    1206 
    1207     Invalid whitespace around field-names is now required to be rejected,
    1208     because accepting it represents a security vulnerability.  The ABNF
    1209     productions defining header fields now only list the field value.
    1210     (Section 3.2)
    1211 
    1212 NEW:
    1213 
    1214     Invalid whitespace around field-names is now required to be rejected,
    1215     because accepting it represents a security vulnerability.  The ABNF
    1216     productions defining header fields now only list the field value
    1217     (Section 3.2).
    1218 
    1219 
    1220 Section 19.7.1, paragraph 13:
    1221 OLD:
    1222 
    1223     Rules about implicit linear whitespace between certain grammar
    1224     productions have been removed; now whitespace is only allowed where
    1225     specifically defined in the ABNF.  (Section 3.2.3)
    1226 
    1227 NEW:
    1228 
    1229     Rules about implicit linear whitespace between certain grammar
    1230     productions have been removed; now whitespace is only allowed where
    1231     specifically defined in the ABNF (Section 3.2.3).
    1232 
    1233 
    1234 Section 19.7.1, paragraph 14:
    1235 OLD:
    1236 
    1237     Header fields that span multiple lines ("line folding") are
    1238     deprecated.  (Section 3.2.4)
    1239 
    1240 NEW:
    1241 
    1242     Header fields that span multiple lines ("line folding") are
    1243     deprecated (Section 3.2.4).
    1244 
    1245 
    1246 Section 19.7.1, paragraph 15:
    1247 OLD:
    1248 
    1249     The NUL octet is no longer allowed in comment and quoted-string text,
    1250     and handling of backslash-escaping in them has been clarified.  The
    1251     quoted-pair rule no longer allows escaping control characters other
    1252     than HTAB.  Non-US-ASCII content in header fields and the reason
    1253     phrase has been obsoleted and made opaque (the TEXT rule was
    1254     removed).  (Section 3.2.6)
    1255 
    1256 NEW:
    1257 
    1258     The NUL octet is no longer allowed in comment and quoted-string text,
    1259     and handling of backslash-escaping in them has been clarified.  The
    1260     quoted-pair rule no longer allows escaping control characters other
    1261     than HTAB.  Non-US-ASCII content in header fields and the reason
    1262     phrase has been obsoleted and made opaque (the TEXT rule was removed)
    1263     (Section 3.2.6).
     566    on the wire.  (Section 2.7.1)
    1264567
    1265568
     
    1272575NEW:
    1273576
    1274     Bogus "Content-Length" header fields are now required to be handled
    1275     as errors by recipients (Section 3.3.2).
    1276 
    1277 
    1278 Section 19.7.1, paragraph 17:
    1279 OLD:
    1280 
    1281     The algorithm for determining the message body length has been
    1282     clarified to indicate all of the special cases (e.g., driven by
    1283     methods or status codes) that affect it, and that new protocol
    1284     elements cannot define such special cases.  CONNECT is a new, special
    1285     case in determining message body length. "multipart/byteranges" is no
    1286     longer a way of determining message body length detection.
    1287     (Section 3.3.3)
    1288 
    1289 NEW:
    1290 
    1291     The algorithm for determining the message body length has been
    1292     clarified to indicate all of the special cases (e.g., driven by
    1293     methods or status codes) that affect it, and that new protocol
    1294     elements cannot define such special cases.  CONNECT is a new, special
    1295     case in determining message body length. "multipart/byteranges" is no
    1296     longer a way of determining message body length detection
    1297     (Section 3.3.3).
    1298 
    1299 
    1300 Section 19.7.1, paragraph 18:
    1301 OLD:
    1302 
    1303     The "identity" transfer coding token has been removed.  (Sections 3.3
    1304     and 4)
    1305 
    1306 NEW:
    1307 
    1308     The "identity" transfer coding token has been removed (Sections 3.3
    1309     and 4).
    1310 
    1311 
    1312 Section 19.7.1, paragraph 19:
    1313 OLD:
    1314 
    1315     Chunk length does not include the count of the octets in the chunk
    1316     header and trailer.  Line folding in chunk extensions is disallowed.
    1317     (Section 4.1)
    1318 
    1319 NEW:
    1320 
    1321     Chunk length does not include the count of the octets in the chunk
    1322     header and trailer.  Line folding in chunk extensions is disallowed
    1323     (Section 4.1).
     577    Bogus Content-Length header fields are now required to be handled as
     578    errors by recipients.  (Section 3.3.2)
    1324579
    1325580
     
    1329584    The meaning of the "deflate" content coding has been clarified.
    1330585    (Section 4.2.2)
    1331 
    1332 NEW:
    1333 
    1334     The meaning of the "deflate" content coding has been clarified
    1335     (Section 4.2.2).
    1336 
    1337 
    1338 Section 19.7.1, paragraph 21:
    1339 OLD:
    1340 
     586 
    1341587    The segment + query components of RFC 3986 have been used to define
    1342588    the request-target, instead of abs_path from RFC 1808.  The asterisk-
     
    1346592NEW:
    1347593
     594    The meaning of the "deflate" content coding has been clarified.
     595    (Section 4.2.2)
    1348596    The segment + query components of RFC 3986 have been used to define
    1349597    the request-target, instead of abs_path from RFC 1808.  The asterisk-
    1350     form of the request-target is only allowed with the OPTIONS method
    1351     (Section 5.3).
    1352 
    1353 
    1354 Section 19.7.1, paragraph 22:
    1355 OLD:
    1356 
    1357     The term "Effective Request URI" has been introduced.  (Section 5.5)
    1358 
    1359 NEW:
    1360 
    1361     The term "Effective Request URI" has been introduced (Section 5.5).
    1362 
    1363 
    1364 Section 19.7.1, paragraph 23:
    1365 OLD:
    1366 
    1367     Gateways do not need to generate Via header fields anymore.
    1368     (Section 5.7.1)
    1369 
    1370 NEW:
    1371 
    1372     Gateways do not need to generate Via header fields anymore
    1373     (Section 5.7.1).
    1374 
    1375 
    1376 Section 19.7.1, paragraph 24:
    1377 OLD:
    1378 
    1379     Exactly when "close" connection options have to be sent has been
    1380     clarified.  Also, "hop-by-hop" header fields are required to appear
    1381     in the Connection header field; just because they're defined as hop-
    1382     by-hop in this specification doesn't exempt them.  (Section 6.1)
    1383 
    1384 NEW:
    1385 
    1386     Exactly when "close" connection options have to be sent has been
    1387     clarified.  Also, "hop-by-hop" header fields are required to appear
    1388     in the Connection header field; just because they're defined as hop-
    1389     by-hop in this specification doesn't exempt them (Section 6.1).
    1390 
    1391 
    1392 Section 19.7.1, paragraph 25:
    1393 OLD:
    1394 
    1395     The limit of two connections per server has been removed.  An
    1396     idempotent sequence of requests is no longer required to be retried.
    1397     The requirement to retry requests under certain circumstances when
    1398     the server prematurely closes the connection has been removed.  Also,
    1399     some extraneous requirements about when servers are allowed to close
    1400     connections prematurely have been removed.  (Section 6.3)
    1401 
    1402 NEW:
    1403 
    1404     The limit of two connections per server has been removed.  An
    1405     idempotent sequence of requests is no longer required to be retried.
    1406     The requirement to retry requests under certain circumstances when
    1407     the server prematurely closes the connection has been removed.  Also,
    1408     some extraneous requirements about when servers are allowed to close
    1409     connections prematurely have been removed (Section 6.3).
    1410 
    1411 
    1412 Section 19.7.1, paragraph 26:
    1413 OLD:
    1414 
    1415     The semantics of the Upgrade header field is now defined in responses
    1416     other than 101 (this was incorporated from [RFC2817]).  Furthermore,
    1417     the ordering in the field value is now significant.  (Section 6.7)
    1418 
    1419 NEW:
    1420 
    1421     The semantics of the Upgrade header field is now defined in responses
    1422     other than 101 (this was incorporated from [RFC2817]).  Furthermore,
    1423     the ordering in the field value is now significant (Section 6.7).
    1424 
    1425 
    1426 Section 19.7.1, paragraph 27:
    1427 OLD:
    1428 
    1429     Empty list elements in list productions (e.g., a list header field
    1430     containing ", ,") have been deprecated.  (Section 7)
    1431 
    1432 NEW:
    1433 
    1434     Empty list elements in list productions (e.g., a list header field
    1435     containing ", ,") have been deprecated (Section 7).
    1436 
    1437 
    1438 Section 19.7.1, paragraph 28:
    1439 OLD:
    1440 
    1441     Registration of Transfer Codings now requires IETF Review
    1442     (Section 8.4)
    1443 
    1444 NEW:
    1445 
    1446     Registration of Transfer Codings now requires IETF Review
    1447     (Section 8.4).
    1448 
    1449 
    1450 Section 19.7.1, paragraph 29:
    1451 OLD:
    1452 
    1453     This specification now defines the Upgrade Token Registry, previously
    1454     defined in Section 7.2 of [RFC2817].  (Section 8.6)
    1455 
    1456 NEW:
    1457 
    1458     This specification now defines the "HTTP Upgrade Tokens" registry,
    1459     previously defined in Section 7.2 of [RFC2817] (Section 8.6).
    1460 
    1461 
    1462 Section 19.7.1, paragraph 30:
    1463 OLD:
    1464 
    1465     The expectation to support HTTP/0.9 requests has been removed.
    1466     (Appendix A)
    1467 
    1468 NEW:
    1469 
    1470     The expectation to support HTTP/0.9 requests has been removed
    1471     (Appendix A).
    1472 
    1473 
    1474 Section 19.7.1, paragraph 31:
    1475 OLD:
    1476 
    1477     Issues with the Keep-Alive and Proxy-Connection header fields in
    1478     requests are pointed out, with use of the latter being discouraged
    1479     altogether.  (Appendix A.1.2)
    1480 
    1481 NEW:
    1482 
    1483     Issues with the Keep-Alive and Proxy-Connection header fields in
    1484     requests are pointed out, with use of the latter being discouraged
    1485     altogether (Appendix A.1.2).
    1486 
    1487 
    1488 Appendix B., paragraph 16:
    1489 OLD:
    1490 
    1491     partial-URI = relative-part [ "?" query ]
    1492     path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
    1493     port = <port, defined in [RFC3986], Section 3.2.3>
    1494     protocol = protocol-name [ "/" protocol-version ]
    1495     protocol-name = token
    1496     protocol-version = token
    1497     pseudonym = token
    1498  
    1499     qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
    1500      / %x5D-7E ; ']'-'~'
    1501      / obs-text
    1502     query = <query, defined in [RFC3986], Section 3.4>
    1503     quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
    1504     quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
    1505 
    1506 NEW:
    1507 
    1508     partial-URI = relative-part [ "?" query ]
    1509     path-abempty = <path-abempty, defined in [RFC3986], Section 3.3>
    1510     port = <port, defined in [RFC3986], Section 3.2.3>
    1511     protocol = protocol-name [ "/" protocol-version ]
    1512     protocol-name = token
    1513     protocol-version = token
    1514     pseudonym = token
    1515     qdtext = HTAB / SP / "!" / %x23-5B ; '#'-'['
    1516      / %x5D-7E ; ']'-'~'
    1517      / obs-text
    1518     query = <query, defined in [RFC3986], Section 3.4>
    1519     quoted-pair = "\" ( HTAB / SP / VCHAR / obs-text )
    1520     quoted-string = DQUOTE *( qdtext / quoted-pair ) DQUOTE
    1521 
    1522 
    1523 Appendix B., paragraph 22:
    1524 OLD:
    1525 
    1526     A
    1527        absolute-form (of request-target)  41
    1528        accelerator  10
    1529        application/http Media Type  62
    1530        asterisk-form (of request-target)  42
    1531        authoritative response  66
    1532        authority-form (of request-target)  42
    1533 
    1534 NEW:
    1535 
    1536     A
    1537        absolute-form (of request-target)  42
    1538        accelerator  10
    1539        application/http Media Type  62
    1540        asterisk-form (of request-target)  42
    1541        authoritative response  66
    1542        authority-form (of request-target)  42
    1543 
    1544 
    1545 Appendix B., paragraph 24:
    1546 OLD:
    1547 
    1548     C
    1549        cache  11
    1550        cacheable  11
    1551        captive portal  11
    1552        chunked (Coding Format)  28, 31, 35
    1553        client  7
    1554        close  50, 55
    1555        compress (Coding Format)  38
    1556        connection  7
    1557        Connection header field  50, 55
    1558        Content-Length header field  29
    1559 
    1560 NEW:
    1561 
    1562     C
    1563        cache  11
    1564        cacheable  11
    1565        captive portal  11
    1566        chunked (Coding Format)  28, 31, 35
    1567        client  7
    1568        close  50, 55
    1569        compress (Coding Format)  38
    1570        connection  7
    1571        Connection header field  50, 55
    1572        Content-Length header field  30
    1573 
    1574 
    1575 Appendix B., paragraph 25:
    1576 OLD:
    1577 
    1578     D
    1579        deflate (Coding Format)  38
    1580        Delimiters  26
    1581        downstream  9
    1582 
    1583 NEW:
    1584 
    1585     D
    1586        deflate (Coding Format)  38
    1587        Delimiters  26
    1588        downstream  10
     598    form of the request-target is only allowed with the OPTIONS method.
     599    (Section 5.3)
     600
     601
     602Appendix B., paragraph 2:
     603OLD:
     604
     605    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
     606     connection-option ] )
     607    Content-Length = 1*DIGIT
     608
     609NEW:
     610
     611    Connection = *( "," OWS ) connection-option *( OWS "," [ OWS
     612     connection-option ] )
     613 
     614    Content-Length = 1*DIGIT
     615
     616
     617Appendix B., paragraph 19:
     618OLD:
     619
     620    scheme = <scheme, defined in [RFC3986], Section 3.1>
     621    segment = <segment, defined in [RFC3986], Section 3.3>
     622    start-line = request-line / status-line
     623    status-code = 3DIGIT
     624    status-line = HTTP-version SP status-code SP reason-phrase CRLF
     625 
     626    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
     627    t-ranking = OWS ";" OWS "q=" rank
     628    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
     629     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
     630    token = 1*tchar
     631    trailer-part = *( header-field CRLF )
     632    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
     633     transfer-extension
     634    transfer-extension = token *( OWS ";" OWS transfer-parameter )
     635    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
     636
     637NEW:
     638
     639    scheme = <scheme, defined in [RFC3986], Section 3.1>
     640    segment = <segment, defined in [RFC3986], Section 3.3>
     641    start-line = request-line / status-line
     642    status-code = 3DIGIT
     643    status-line = HTTP-version SP status-code SP reason-phrase CRLF
     644    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
     645    t-ranking = OWS ";" OWS "q=" rank
     646    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
     647     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
     648    token = 1*tchar
     649    trailer-part = *( header-field CRLF )
     650    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
     651     transfer-extension
     652    transfer-extension = token *( OWS ";" OWS transfer-parameter )
     653    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
    1589654
    1590655
     
    1689754       gateway  10
    1690755       Grammar
    1691           absolute-form  41-42
     756          absolute-form  41
    1692757          absolute-path  16
    1693758          absolute-URI  16
     
    1705770          chunked-body  35-36
    1706771          comment  27
    1707           Connection  51
    1708           connection-option  51
    1709           Content-Length  30
     772          Connection  50
     773          connection-option  50
     774          Content-Length  29
    1710775          CR  6
    1711776          CRLF  6
     
    1724789          HTAB  6
    1725790          HTTP-message  19
    1726           HTTP-name  14
     791          HTTP-name  13
    1727792          http-URI  16
    1728           HTTP-version  14
     793          HTTP-version  13
    1729794          https-URI  18
    1730795          last-chunk  35
     
    1761826          t-codings  38
    1762827          t-ranking  38
    1763           tchar  27
     828          tchar  26
    1764829          TE  38
    1765           token  27
     830          token  26
    1766831          Trailer  39
    1767832          trailer-part  35-36
     
    1777842       gzip (Coding Format)  38
    1778843
    1779 
    1780 Appendix B., paragraph 29:
    1781 OLD:
    1782 
    1783     I
    1784        inbound  9
    1785        interception proxy  11
    1786        intermediary  9
    1787 
    1788 NEW:
    1789 
    1790     I
    1791        inbound  10
    1792        interception proxy  11
    1793        intermediary  9
    1794 
    1795 
    1796 Appendix B., paragraph 32:
    1797 OLD:
    1798 
    1799     O
    1800        origin server  7
    1801        origin-form (of request-target)  41
    1802        outbound  9
    1803 
    1804 NEW:
    1805 
    1806     O
    1807        origin server  7
    1808        origin-form (of request-target)  41
    1809        outbound  10
    1810 
    1811 
    1812 Appendix B., paragraph 37:
    1813 OLD:
    1814 
    1815     U
    1816        Upgrade header field  56
    1817        upstream  9
    1818        URI scheme
    1819           http  16
    1820           https  18
    1821        user agent  7
    1822 
    1823 NEW:
    1824 
    1825     U
    1826        Upgrade header field  56
    1827        upstream  10
    1828        URI scheme
    1829           http  16
    1830           https  18
    1831        user agent  7
    1832 
    1833 
    1834 Appendix B., paragraph 38:
    1835 OLD:
    1836 
    1837     V
    1838        Via header field  46
    1839 
    1840 NEW:
    1841 
    1842     V
    1843        Via header field  47
    1844 
    1845 
    1846 Section 345, paragraph 1:
    1847 OLD:
    1848 
    1849     EMail: fielding@gbiv.com
    1850     URI:   http://roy.gbiv.com/
    1851  
    1852     Julian F. Reschke (editor)
    1853     greenbytes GmbH
    1854     Hafenweg 16
    1855     Muenster, NW  48155
    1856     Germany
    1857 
    1858 NEW:
    1859 
    1860     EMail: fielding@gbiv.com
    1861     URI:   http://roy.gbiv.com/
    1862     Julian F. Reschke (editor)
    1863     greenbytes GmbH
    1864     Hafenweg 16
    1865     Muenster, NW  48155
    1866     Germany
    1867 
  • draft-ietf-httpbis/latest/auth48/rfc7230.diff.html

    r2663 r2665  
    110110      <tr><td class="lineno" valign="top"></td><td class="left">   publication of this document.  Please review these documents</td><td> </td><td class="right">   publication of this document.  Please review these documents</td><td class="lineno" valign="top"></td></tr>
    111111      <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    112       <tr bgcolor="gray" ><td></td><th><a name="part-l2" /><small>skipping to change at</small><em> page 3, line 4</em></th><th> </th><th><a name="part-r2" /><small>skipping to change at</small><em> page 2, line 33</em></th><td></td></tr>
    113       <tr><td class="lineno" valign="top"></td><td class="left">     2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7</td><td> </td><td class="right">     2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7</td><td class="lineno" valign="top"></td></tr>
    114       <tr><td class="lineno" valign="top"></td><td class="left">     2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8</td><td> </td><td class="right">     2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8</td><td class="lineno" valign="top"></td></tr>
    115       <tr><td class="lineno" valign="top"></td><td class="left">     2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9</td><td> </td><td class="right">     2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9</td><td class="lineno" valign="top"></td></tr>
    116       <tr><td class="lineno" valign="top"></td><td class="left">     2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11</td><td> </td><td class="right">     2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11</td><td class="lineno" valign="top"></td></tr>
    117       <tr><td class="lineno" valign="top"></td><td class="left">     2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12</td><td> </td><td class="right">     2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12</td><td class="lineno" valign="top"></td></tr>
    118       <tr><td class="lineno" valign="top"></td><td class="left">     2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13</td><td> </td><td class="right">     2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13</td><td class="lineno" valign="top"></td></tr>
    119       <tr><td class="lineno" valign="top"></td><td class="left">     2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16</td><td> </td><td class="right">     2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16</td><td class="lineno" valign="top"></td></tr>
    120       <tr><td class="lineno" valign="top"></td><td class="left">       2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16</td><td> </td><td class="right">       2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16</td><td class="lineno" valign="top"></td></tr>
    121       <tr><td class="lineno" valign="top"></td><td class="left">       2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18</td><td> </td><td class="right">       2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18</td><td class="lineno" valign="top"></td></tr>
    122       <tr><td class="lineno" valign="top"></td><td class="left">       2.7.3.  http and https URI Normalization and Comparison  . . . 19</td><td> </td><td class="right">       2.7.3.  http and https URI Normalization and Comparison  . . . 19</td><td class="lineno" valign="top"></td></tr>
    123       <tr><td><a name="diff0008" /></td></tr>
    124       <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">                                                                         </span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
    125       <tr><td class="lineno" valign="top"></td><td class="left">   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19</td><td> </td><td class="right">   3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19</td><td class="lineno" valign="top"></td></tr>
    126       <tr><td class="lineno" valign="top"></td><td class="left">     3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20</td><td> </td><td class="right">     3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20</td><td class="lineno" valign="top"></td></tr>
    127       <tr><td class="lineno" valign="top"></td><td class="left">       3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21</td><td> </td><td class="right">       3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21</td><td class="lineno" valign="top"></td></tr>
    128       <tr><td class="lineno" valign="top"></td><td class="left">       3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22</td><td> </td><td class="right">       3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22</td><td class="lineno" valign="top"></td></tr>
    129       <tr><td class="lineno" valign="top"></td><td class="left">     3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22</td><td> </td><td class="right">     3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22</td><td class="lineno" valign="top"></td></tr>
    130       <tr><td class="lineno" valign="top"></td><td class="left">       3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23</td><td> </td><td class="right">       3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23</td><td class="lineno" valign="top"></td></tr>
    131       <tr><td class="lineno" valign="top"></td><td class="left">       3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23</td><td> </td><td class="right">       3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23</td><td class="lineno" valign="top"></td></tr>
    132       <tr><td class="lineno" valign="top"></td><td class="left">       3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24</td><td> </td><td class="right">       3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24</td><td class="lineno" valign="top"></td></tr>
    133       <tr><td><a name="diff0009" /></td></tr>
    134       <tr><td class="lineno" valign="top"></td><td class="lblock">       3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 2<span class="delete">4</span></td><td> </td><td class="rblock">       3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 2<span class="insert">5</span></td><td class="lineno" valign="top"></td></tr>
    135       <tr><td class="lineno" valign="top"></td><td class="left">       3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26</td><td> </td><td class="right">       3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26</td><td class="lineno" valign="top"></td></tr>
    136       <tr><td class="lineno" valign="top"></td><td class="left">       3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26</td><td> </td><td class="right">       3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26</td><td class="lineno" valign="top"></td></tr>
    137       <tr><td class="lineno" valign="top"></td><td class="left">     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27</td><td> </td><td class="right">     3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27</td><td class="lineno" valign="top"></td></tr>
    138       <tr><td class="lineno" valign="top"></td><td class="left">       3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28</td><td> </td><td class="right">       3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28</td><td class="lineno" valign="top"></td></tr>
    139       <tr><td><a name="diff0010" /></td></tr>
    140       <tr><td class="lineno" valign="top"></td><td class="lblock">       3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . <span class="delete">29</span></td><td> </td><td class="rblock">       3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . <span class="insert">30</span></td><td class="lineno" valign="top"></td></tr>
    141       <tr><td class="lineno" valign="top"></td><td class="left">       3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31</td><td> </td><td class="right">       3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31</td><td class="lineno" valign="top"></td></tr>
    142       <tr><td class="lineno" valign="top"></td><td class="left">     3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33</td><td> </td><td class="right">     3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33</td><td class="lineno" valign="top"></td></tr>
    143       <tr><td class="lineno" valign="top"></td><td class="left">     3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34</td><td> </td><td class="right">     3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34</td><td class="lineno" valign="top"></td></tr>
    144       <tr><td><a name="diff0011" /></td></tr>
    145       <tr><td class="lineno" valign="top"></td><td class="lblock">   4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 3<span class="delete">4</span></td><td> </td><td class="rblock">   4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 3<span class="insert">5</span></td><td class="lineno" valign="top"></td></tr>
    146       <tr><td class="lineno" valign="top"></td><td class="left">     4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35</td><td> </td><td class="right">     4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35</td><td class="lineno" valign="top"></td></tr>
    147       <tr><td class="lineno" valign="top"></td><td class="left">       4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36</td><td> </td><td class="right">       4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36</td><td class="lineno" valign="top"></td></tr>
    148       <tr><td class="lineno" valign="top"></td><td class="left">       4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36</td><td> </td><td class="right">       4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36</td><td class="lineno" valign="top"></td></tr>
    149       <tr><td class="lineno" valign="top"></td><td class="left">       4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37</td><td> </td><td class="right">       4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37</td><td class="lineno" valign="top"></td></tr>
    150       <tr><td><a name="diff0012" /></td></tr>
    151       <tr><td class="lineno" valign="top"></td><td class="lblock">     4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 3<span class="delete">7</span></td><td> </td><td class="rblock">     4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 3<span class="insert">8</span></td><td class="lineno" valign="top"></td></tr>
    152       <tr><td class="lineno" valign="top"></td><td class="left">       4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38</td><td> </td><td class="right">       4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38</td><td class="lineno" valign="top"></td></tr>
    153       <tr><td class="lineno" valign="top"></td><td class="left">       4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38</td><td> </td><td class="right">       4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38</td><td class="lineno" valign="top"></td></tr>
    154       <tr><td class="lineno" valign="top"></td><td class="left">       4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38</td><td> </td><td class="right">       4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38</td><td class="lineno" valign="top"></td></tr>
    155       <tr><td class="lineno" valign="top"></td><td class="left">     4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38</td><td> </td><td class="right">     4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38</td><td class="lineno" valign="top"></td></tr>
    156       <tr><td class="lineno" valign="top"></td><td class="left">     4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39</td><td> </td><td class="right">     4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39</td><td class="lineno" valign="top"></td></tr>
    157       <tr><td><a name="diff0013" /></td></tr>
    158       <tr><td class="lineno" valign="top"></td><td class="lblock">   5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . <span class="delete">39</span></td><td> </td><td class="rblock">   5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . <span class="insert">40</span></td><td class="lineno" valign="top"></td></tr>
    159       <tr><td class="lineno" valign="top"></td><td class="left">     5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40</td><td> </td><td class="right">     5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40</td><td class="lineno" valign="top"></td></tr>
    160       <tr><td class="lineno" valign="top"></td><td class="left">     5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40</td><td> </td><td class="right">     5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40</td><td class="lineno" valign="top"></td></tr>
    161       <tr><td class="lineno" valign="top"></td><td class="left">     5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41</td><td> </td><td class="right">     5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41</td><td class="lineno" valign="top"></td></tr>
    162       <tr><td class="lineno" valign="top"></td><td class="left">       5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41</td><td> </td><td class="right">       5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41</td><td class="lineno" valign="top"></td></tr>
    163       <tr><td><a name="diff0014" /></td></tr>
    164       <tr><td class="lineno" valign="top"></td><td class="lblock">       5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 4<span class="delete">1</span></td><td> </td><td class="rblock">       5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 4<span class="insert">2</span></td><td class="lineno" valign="top"></td></tr>
    165       <tr><td class="lineno" valign="top"></td><td class="left">       5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42</td><td> </td><td class="right">       5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42</td><td class="lineno" valign="top"></td></tr>
    166       <tr><td class="lineno" valign="top"></td><td class="left">       5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42</td><td> </td><td class="right">       5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42</td><td class="lineno" valign="top"></td></tr>
    167       <tr><td class="lineno" valign="top"></td><td class="left">     5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43</td><td> </td><td class="right">     5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43</td><td class="lineno" valign="top"></td></tr>
    168       <tr><td class="lineno" valign="top"></td><td class="left">     5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44</td><td> </td><td class="right">     5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44</td><td class="lineno" valign="top"></td></tr>
    169       <tr><td class="lineno" valign="top"></td><td class="left">     5.6.  Associating a Response to a Request  . . . . . . . . . . . 46</td><td> </td><td class="right">     5.6.  Associating a Response to a Request  . . . . . . . . . . . 46</td><td class="lineno" valign="top"></td></tr>
    170       <tr><td class="lineno" valign="top"></td><td class="left">     5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46</td><td> </td><td class="right">     5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46</td><td class="lineno" valign="top"></td></tr>
    171       <tr><td><a name="diff0015" /></td></tr>
    172       <tr><td class="lineno" valign="top"></td><td class="lblock">       5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 4<span class="delete">6</span></td><td> </td><td class="rblock">       5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 4<span class="insert">7</span></td><td class="lineno" valign="top"></td></tr>
    173       <tr><td class="lineno" valign="top"></td><td class="left">       5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48</td><td> </td><td class="right">       5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48</td><td class="lineno" valign="top"></td></tr>
    174       <tr><td class="lineno" valign="top"></td><td class="left">   6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49</td><td> </td><td class="right">   6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49</td><td class="lineno" valign="top"></td></tr>
    175       <tr><td class="lineno" valign="top"></td><td class="left">     6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50</td><td> </td><td class="right">     6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50</td><td class="lineno" valign="top"></td></tr>
    176       <tr><td class="lineno" valign="top"></td><td class="left">     6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51</td><td> </td><td class="right">     6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51</td><td class="lineno" valign="top"></td></tr>
    177       <tr><td><a name="diff0016" /></td></tr>
    178       <tr><td class="lineno" valign="top"></td><td class="lblock">     6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . <span class="delete">51</span></td><td> </td><td class="rblock">     6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . <span class="insert">52</span></td><td class="lineno" valign="top"></td></tr>
    179       <tr><td class="lineno" valign="top"></td><td class="lblock">       6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . <span class="delete">52</span></td><td> </td><td class="rblock">       6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . <span class="insert">53</span></td><td class="lineno" valign="top"></td></tr>
    180       <tr><td class="lineno" valign="top"></td><td class="left">       6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53</td><td> </td><td class="right">       6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53</td><td class="lineno" valign="top"></td></tr>
    181       <tr><td><a name="diff0017" /></td></tr>
    182       <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">                                                                         </span></td><td> </td><td class="rblock"></td><td class="lineno" valign="top"></td></tr>
    183       <tr><td class="lineno" valign="top"></td><td class="left">     6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54</td><td> </td><td class="right">     6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54</td><td class="lineno" valign="top"></td></tr>
    184       <tr><td class="lineno" valign="top"></td><td class="left">     6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54</td><td> </td><td class="right">     6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54</td><td class="lineno" valign="top"></td></tr>
    185       <tr><td><a name="diff0018" /></td></tr>
    186       <tr><td class="lineno" valign="top"></td><td class="lblock">     6.6.  Tear<span class="delete">-down </span> . . . . . . . . . . . . . . . . . . . . . . . . 55</td><td> </td><td class="rblock">     6.6.  Tear<span class="insert">down .</span> . . . . . . . . . . . . . . . . . . . . . . . . 55</td><td class="lineno" valign="top"></td></tr>
    187       <tr><td class="lineno" valign="top"></td><td class="left">     6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56</td><td> </td><td class="right">     6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56</td><td class="lineno" valign="top"></td></tr>
    188       <tr><td class="lineno" valign="top"></td><td class="left">   7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58</td><td> </td><td class="right">   7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58</td><td class="lineno" valign="top"></td></tr>
    189       <tr><td><a name="diff0019" /></td></tr>
    190       <tr><td class="lineno" valign="top"></td><td class="lblock">   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . <span class="delete">59</span></td><td> </td><td class="rblock">   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . <span class="insert">60</span></td><td class="lineno" valign="top"></td></tr>
    191       <tr><td class="lineno" valign="top"></td><td class="lblock">     8.1.  Header Field Registration  . . . . . . . . . . . . . . . . <span class="delete">59</span></td><td> </td><td class="rblock">     8.1.  Header Field Registration  . . . . . . . . . . . . . . . . <span class="insert">60</span></td><td class="lineno" valign="top"></td></tr>
    192       <tr><td class="lineno" valign="top"></td><td class="left">     8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60</td><td> </td><td class="right">     8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60</td><td class="lineno" valign="top"></td></tr>
    193       <tr><td><a name="diff0020" /></td></tr>
    194       <tr><td class="lineno" valign="top"></td><td class="lblock">     8.3.  Internet Media Type Registration . . . . . . . . . . . . . 6<span class="delete">0</span></td><td> </td><td class="rblock">     8.3.  Internet Media Type Registration . . . . . . . . . . . . . 6<span class="insert">1</span></td><td class="lineno" valign="top"></td></tr>
    195       <tr><td class="lineno" valign="top"></td><td class="left">       8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61</td><td> </td><td class="right">       8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61</td><td class="lineno" valign="top"></td></tr>
    196       <tr><td class="lineno" valign="top"></td><td class="left">       8.3.2.  Internet Media Type application/http . . . . . . . . . 62</td><td> </td><td class="right">       8.3.2.  Internet Media Type application/http . . . . . . . . . 62</td><td class="lineno" valign="top"></td></tr>
    197       <tr><td class="lineno" valign="top"></td><td class="left">     8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63</td><td> </td><td class="right">     8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63</td><td class="lineno" valign="top"></td></tr>
    198       <tr><td class="lineno" valign="top"></td><td class="left">       8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63</td><td> </td><td class="right">       8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63</td><td class="lineno" valign="top"></td></tr>
    199       <tr><td class="lineno" valign="top"></td><td class="left">       8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64</td><td> </td><td class="right">       8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64</td><td class="lineno" valign="top"></td></tr>
    200       <tr><td class="lineno" valign="top"></td><td class="left">     8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64</td><td> </td><td class="right">     8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64</td><td class="lineno" valign="top"></td></tr>
    201       <tr><td><a name="diff0021" /></td></tr>
    202       <tr><td class="lineno" valign="top"></td><td class="lblock">     8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 6<span class="delete">4</span></td><td> </td><td class="rblock">     8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 6<span class="insert">5</span></td><td class="lineno" valign="top"></td></tr>
    203       <tr><td class="lineno" valign="top"></td><td class="left">       8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65</td><td> </td><td class="right">       8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65</td><td class="lineno" valign="top"></td></tr>
    204       <tr><td><a name="diff0022" /></td></tr>
    205       <tr><td class="lineno" valign="top"></td><td class="lblock">       8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 6<span class="delete">5</span></td><td> </td><td class="rblock">       8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 6<span class="insert">6</span></td><td class="lineno" valign="top"></td></tr>
    206       <tr><td class="lineno" valign="top"></td><td class="left">   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66</td><td> </td><td class="right">   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66</td><td class="lineno" valign="top"></td></tr>
    207       <tr><td class="lineno" valign="top"></td><td class="left">     9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66</td><td> </td><td class="right">     9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66</td><td class="lineno" valign="top"></td></tr>
    208       <tr><td class="lineno" valign="top"></td><td class="left">     9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67</td><td> </td><td class="right">     9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67</td><td class="lineno" valign="top"></td></tr>
    209       <tr><td><a name="diff0023" /></td></tr>
    210       <tr><td class="lineno" valign="top"></td><td class="lblock">     9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 6<span class="delete">7</span></td><td> </td><td class="rblock">     9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 6<span class="insert">8</span></td><td class="lineno" valign="top"></td></tr>
    211       <tr><td class="lineno" valign="top"></td><td class="left">     9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68</td><td> </td><td class="right">     9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68</td><td class="lineno" valign="top"></td></tr>
     112      <tr bgcolor="gray" ><td></td><th><a name="part-l2" /><small>skipping to change at</small><em> page 4, line 38</em></th><th> </th><th><a name="part-r2" /><small>skipping to change at</small><em> page 4, line 17</em></th><td></td></tr>
    212113      <tr><td class="lineno" valign="top"></td><td class="left">     9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69</td><td> </td><td class="right">     9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69</td><td class="lineno" valign="top"></td></tr>
    213114      <tr><td class="lineno" valign="top"></td><td class="left">     9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69</td><td> </td><td class="right">     9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69</td><td class="lineno" valign="top"></td></tr>
    214       <tr><td><a name="diff0024" /></td></tr>
    215       <tr><td class="lineno" valign="top"></td><td class="lblock">     9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . <span class="delete">69</span></td><td> </td><td class="rblock">     9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . <span class="insert">70</span></td><td class="lineno" valign="top"></td></tr>
     115      <tr><td class="lineno" valign="top"></td><td class="left">     9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69</td><td> </td><td class="right">     9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69</td><td class="lineno" valign="top"></td></tr>
    216116      <tr><td class="lineno" valign="top"></td><td class="left">     9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70</td><td> </td><td class="right">     9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70</td><td class="lineno" valign="top"></td></tr>
    217       <tr><td><a name="diff0025" /></td></tr>
    218       <tr><td class="lineno" valign="top"></td><td class="lblock">   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 7<span class="delete">0</span></td><td> </td><td class="rblock">   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 7<span class="insert">1</span></td><td class="lineno" valign="top"></td></tr>
     117      <tr><td class="lineno" valign="top"></td><td class="left">   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70</td><td> </td><td class="right">   10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70</td><td class="lineno" valign="top"></td></tr>
    219118      <tr><td class="lineno" valign="top"></td><td class="left">   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72</td><td> </td><td class="right">   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72</td><td class="lineno" valign="top"></td></tr>
    220119      <tr><td class="lineno" valign="top"></td><td class="left">     11.1. Normative References . . . . . . . . . . . . . . . . . . . 72</td><td> </td><td class="right">     11.1. Normative References . . . . . . . . . . . . . . . . . . . 72</td><td class="lineno" valign="top"></td></tr>
    221       <tr><td><a name="diff0026" /></td></tr>
    222       <tr><td class="lineno" valign="top"></td><td class="lblock">     11.2. Informative References . . . . . . . . . . . . . . . . . . <span class="delete">73</span></td><td> </td><td class="rblock">     11.2. Informative References . . . . . . . . . . . . . . . . . . <span class="insert">74</span></td><td class="lineno" valign="top"></td></tr>
    223       <tr><td class="lineno" valign="top"></td><td class="lblock">   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . <span class="delete">75</span></td><td> </td><td class="rblock">   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . <span class="insert">76</span></td><td class="lineno" valign="top"></td></tr>
     120      <tr><td class="lineno" valign="top"></td><td class="left">     11.2. Informative References . . . . . . . . . . . . . . . . . . 73</td><td> </td><td class="right">     11.2. Informative References . . . . . . . . . . . . . . . . . . 73</td><td class="lineno" valign="top"></td></tr>
     121      <tr><td class="lineno" valign="top"></td><td class="left">   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75</td><td> </td><td class="right">   Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75</td><td class="lineno" valign="top"></td></tr>
    224122      <tr><td class="lineno" valign="top"></td><td class="left">     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76</td><td> </td><td class="right">     A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76</td><td class="lineno" valign="top"></td></tr>
    225       <tr><td><a name="diff0027" /></td></tr>
    226       <tr><td class="lineno" valign="top"></td><td class="lblock">       A.1.1.  Multi<span class="delete">-homed Web Servers  . . . . . . . . . . . . . . . 76</span></td><td> </td><td class="rblock">       A.1.1.  Multi<span class="insert">homed Web Servers . . . . . . . . . . . . . . . . 77</span></td><td class="lineno" valign="top"></td></tr>
    227       <tr><td class="lineno" valign="top"></td><td class="left">       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77</td><td> </td><td class="right">       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 77</td><td class="lineno" valign="top"></td></tr>
    228       <tr><td><a name="diff0028" /></td></tr>
    229       <tr><td class="lineno" valign="top"></td><td class="lblock">       A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . <span class="delete">77</span></td><td> </td><td class="rblock">       A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . <span class="insert">78</span></td><td class="lineno" valign="top"></td></tr>
    230       <tr><td class="lineno" valign="top"></td><td class="lblock">     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . <span class="delete">77</span></td><td> </td><td class="rblock">     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . <span class="insert">78</span></td><td class="lineno" valign="top"></td></tr>
    231       <tr><td class="lineno" valign="top"></td><td class="left">   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80</td><td> </td><td class="right">   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 80</td><td class="lineno" valign="top"></td></tr>
     123      <tr><td><a name="diff0008" /></td></tr>
     124      <tr><td class="lineno" valign="top"></td><td class="lblock">       A.1.1.  <span class="delete">Multi-homed</span> Web Servers  . . . . . . . . . . . . . . . 76</td><td> </td><td class="rblock">       A.1.1.  <span class="insert">Multihomed</span> Web Servers . . . . . . . . . . . . . . . <span class="insert">.</span> 76</td><td class="lineno" valign="top"></td></tr>
     125      <tr><td class="lineno" valign="top"></td><td class="lblock">       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . <span class="delete">77</span></td><td> </td><td class="rblock">       A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . <span class="insert">76</span></td><td class="lineno" valign="top"></td></tr>
     126      <tr><td class="lineno" valign="top"></td><td class="left">       A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77</td><td> </td><td class="right">       A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77</td><td class="lineno" valign="top"></td></tr>
     127      <tr><td class="lineno" valign="top"></td><td class="left">     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77</td><td> </td><td class="right">     A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77</td><td class="lineno" valign="top"></td></tr>
     128      <tr><td><a name="diff0009" /></td></tr>
     129      <tr><td class="lineno" valign="top"></td><td class="lblock">   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . <span class="delete">80</span></td><td> </td><td class="rblock">   Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . <span class="insert">79</span></td><td class="lineno" valign="top"></td></tr>
    232130      <tr><td class="lineno" valign="top"></td><td class="left">   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82</td><td> </td><td class="right">   Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82</td><td class="lineno" valign="top"></td></tr>
    233131      <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
     
    240138      <tr><td class="lineno" valign="top"></td><td class="left">   first in a series of documents that collectively form the HTTP/1.1</td><td> </td><td class="right">   first in a series of documents that collectively form the HTTP/1.1</td><td class="lineno" valign="top"></td></tr>
    241139      <tr><td class="lineno" valign="top"></td><td class="left">   specification:</td><td> </td><td class="right">   specification:</td><td class="lineno" valign="top"></td></tr>
    242       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    243       <tr><td><a name="diff0029" /></td></tr>
    244       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">1.  "Message Syntax and Routing" (this document)</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7230: Message Syntax and Routing</span></td><td class="lineno" valign="top"></td></tr>
    245       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    246       <tr><td><a name="diff0030" /></td></tr>
    247       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">2.  "Semantics and Content" [RFC7231]</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7231: Semantics and Content</span></td><td class="lineno" valign="top"></td></tr>
    248       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    249       <tr><td><a name="diff0031" /></td></tr>
    250       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">3.  "Conditional Requests" [RFC7232]</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7232: Conditional Requests</span></td><td class="lineno" valign="top"></td></tr>
    251       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    252       <tr><td><a name="diff0032" /></td></tr>
    253       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">4.  "Range Requests" [RFC7233]</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7233: Range Requests</span></td><td class="lineno" valign="top"></td></tr>
    254       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    255       <tr><td><a name="diff0033" /></td></tr>
    256       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">5.  "Caching" [RFC7234]</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7234: Caching</span></td><td class="lineno" valign="top"></td></tr>
    257       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    258       <tr><td><a name="diff0034" /></td></tr>
    259       <tr><td class="lineno" valign="top"></td><td class="lblock">   <span class="delete">6.  "Authentication" [RFC7235]</span></td><td> </td><td class="rblock">   <span class="insert">   RFC 7235: Authentication</span></td><td class="lineno" valign="top"></td></tr>
    260       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    261       <tr><td><a name="diff0035" /></td></tr>
    262       <tr><td class="lineno" valign="top"></td><td class="lblock">   This HTTP/1.1 specification obsoletes <span class="delete">RFC 2616</span> and <span class="delete">RFC 2145</span> (on HTTP</td><td> </td><td class="rblock">   This HTTP/1.1 specification obsoletes <span class="insert">[RFC2616]</span> and <span class="insert">[RFC2145]</span> (on</td><td class="lineno" valign="top"></td></tr>
    263       <tr><td class="lineno" valign="top"></td><td class="lblock">   versioning).  This specification also updates the use of <span class="delete">CONNECT to</span></td><td> </td><td class="rblock">   HTTP versioning).  This specification also updates the use of</td><td class="lineno" valign="top"></td></tr>
    264       <tr><td class="lineno" valign="top"></td><td class="lblock"><span class="delete">   establish a tunnel,</span> previously defined in RFC 2817, and defines the</td><td> </td><td class="rblock">   <span class="insert">CONNECT,</span> previously defined in RFC 2817, <span class="insert">to establish a tunnel,</span> and</td><td class="lineno" valign="top"></td></tr>
    265       <tr><td class="lineno" valign="top"></td><td class="lblock">   "https" URI scheme that was described informally in RFC 2818.</td><td> </td><td class="rblock">   defines the "https" URI scheme that was described informally in RFC</td><td class="lineno" valign="top"></td></tr>
    266       <tr><td class="lineno" valign="top"></td><td class="lblock"></td><td> </td><td class="rblock">   2818.</td><td class="lineno" valign="top"></td></tr>
    267       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    268       <tr><td class="lineno" valign="top"></td><td class="left">   HTTP is a generic interface protocol for information systems.  It is</td><td> </td><td class="right">   HTTP is a generic interface protocol for information systems.  It is</td><td class="lineno" valign="top"></td></tr>
    269       <tr><td class="lineno" valign="top"></td><td class="left">   designed to hide the details of how a service is implemented by</td><td> </td><td class="right">   designed to hide the details of how a service is implemented by</td><td class="lineno" valign="top"></td></tr>
    270       <tr><td class="lineno" valign="top"></td><td class="left">   presenting a uniform interface to clients that is independent of the</td><td> </td><td class="right">   presenting a uniform interface to clients that is independent of the</td><td class="lineno" valign="top"></td></tr>
    271       <tr><td class="lineno" valign="top"></td><td class="left">   types of resources provided.  Likewise, servers do not need to be</td><td> </td><td class="right">   types of resources provided.  Likewise, servers do not need to be</td><td class="lineno" valign="top"></td></tr>
    272       <tr><td class="lineno" valign="top"></td><td class="left">   aware of each client's purpose: an HTTP request can be considered in</td><td> </td><td class="right">   aware of each client's purpose: an HTTP request can be considered in</td><td class="lineno" valign="top"></td></tr>
    273       <tr><td class="lineno" valign="top"></td><td class="left">   isolation rather than being associated with a specific type of client</td><td> </td><td class="right">   isolation rather than being associated with a specific type of client</td><td class="lineno" valign="top"></td></tr>
    274       <tr><td class="lineno" valign="top"></td><td class="left">   or a predetermined sequence of application steps.  The result is a</td><td> </td><td class="right">   or a predetermined sequence of application steps.  The result is a</td><td class="lineno" valign="top"></td></tr>
    275       <tr><td class="lineno" valign="top"></td><td class="left">   protocol that can be used effectively in many different contexts and</td><td> </td><td class="right">   protocol that can be used effectively in many different contexts and</td><td class="lineno" valign="top"></td></tr>
    276       <tr><td class="lineno" valign="top"></td><td class="left">   for which implementations can evolve independently over time.</td><td> </td><td class="right">   for which implementations can evolve independently over time.</td><td class="lineno" valign="top"></td></tr>
    277       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    278       <tr bgcolor="gray" ><td></td><th><a name="part-l3" /><small>skipping to change at</small><em> page 10, line 36</em></th><th> </th><th><a name="part-r3" /><small>skipping to change at</small><em> page 10, line 39</em></th><td></td></tr>
    279       <tr><td class="lineno" valign="top"></td><td class="left">   Gateways are often used to encapsulate legacy or untrusted</td><td> </td><td class="right">   Gateways are often used to encapsulate legacy or untrusted</td><td class="lineno" valign="top"></td></tr>
    280       <tr><td class="lineno" valign="top"></td><td class="left">   information services, to improve server performance through</td><td> </td><td class="right">   information services, to improve server performance through</td><td class="lineno" valign="top"></td></tr>
    281       <tr><td class="lineno" valign="top"></td><td class="left">   "accelerator" caching, and to enable partitioning or load balancing</td><td> </td><td class="right">   "accelerator" caching, and to enable partitioning or load balancing</td><td class="lineno" valign="top"></td></tr>
    282       <tr><td class="lineno" valign="top"></td><td class="left">   of HTTP services across multiple machines.</td><td> </td><td class="right">   of HTTP services across multiple machines.</td><td class="lineno" valign="top"></td></tr>
    283       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    284       <tr><td class="lineno" valign="top"></td><td class="left">   All HTTP requirements applicable to an origin server also apply to</td><td> </td><td class="right">   All HTTP requirements applicable to an origin server also apply to</td><td class="lineno" valign="top"></td></tr>
    285       <tr><td class="lineno" valign="top"></td><td class="left">   the outbound communication of a gateway.  A gateway communicates with</td><td> </td><td class="right">   the outbound communication of a gateway.  A gateway communicates with</td><td class="lineno" valign="top"></td></tr>
    286       <tr><td class="lineno" valign="top"></td><td class="left">   inbound servers using any protocol that it desires, including private</td><td> </td><td class="right">   inbound servers using any protocol that it desires, including private</td><td class="lineno" valign="top"></td></tr>
    287       <tr><td class="lineno" valign="top"></td><td class="left">   extensions to HTTP that are outside the scope of this specification.</td><td> </td><td class="right">   extensions to HTTP that are outside the scope of this specification.</td><td class="lineno" valign="top"></td></tr>
    288       <tr><td class="lineno" valign="top"></td><td class="left">   However, an HTTP-to-HTTP gateway that wishes to interoperate with</td><td> </td><td class="right">   However, an HTTP-to-HTTP gateway that wishes to interoperate with</td><td class="lineno" valign="top"></td></tr>
    289       <tr><td><a name="diff0036" /></td></tr>
    290       <tr><td class="lineno" valign="top"></td><td class="lblock">   third-party HTTP servers ought to conform to user<span class="delete"> </span>agent requirements</td><td> </td><td class="rblock">   third-party HTTP servers ought to conform to user<span class="insert">-</span>agent requirements</td><td class="lineno" valign="top"></td></tr>
    291       <tr><td class="lineno" valign="top"></td><td class="left">   on the gateway's inbound connection.</td><td> </td><td class="right">   on the gateway's inbound connection.</td><td class="lineno" valign="top"></td></tr>
    292       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    293       <tr><td class="lineno" valign="top"></td><td class="left">   A "tunnel" acts as a blind relay between two connections without</td><td> </td><td class="right">   A "tunnel" acts as a blind relay between two connections without</td><td class="lineno" valign="top"></td></tr>
    294       <tr><td class="lineno" valign="top"></td><td class="left">   changing the messages.  Once active, a tunnel is not considered a</td><td> </td><td class="right">   changing the messages.  Once active, a tunnel is not considered a</td><td class="lineno" valign="top"></td></tr>
    295       <tr><td class="lineno" valign="top"></td><td class="left">   party to the HTTP communication, though the tunnel might have been</td><td> </td><td class="right">   party to the HTTP communication, though the tunnel might have been</td><td class="lineno" valign="top"></td></tr>
    296       <tr><td class="lineno" valign="top"></td><td class="left">   initiated by an HTTP request.  A tunnel ceases to exist when both</td><td> </td><td class="right">   initiated by an HTTP request.  A tunnel ceases to exist when both</td><td class="lineno" valign="top"></td></tr>
    297       <tr><td class="lineno" valign="top"></td><td class="left">   ends of the relayed connection are closed.  Tunnels are used to</td><td> </td><td class="right">   ends of the relayed connection are closed.  Tunnels are used to</td><td class="lineno" valign="top"></td></tr>
    298       <tr><td class="lineno" valign="top"></td><td class="left">   extend a virtual connection through an intermediary, such as when</td><td> </td><td class="right">   extend a virtual connection through an intermediary, such as when</td><td class="lineno" valign="top"></td></tr>
    299       <tr><td class="lineno" valign="top"></td><td class="left">   Transport Layer Security (TLS, [RFC5246]) is used to establish</td><td> </td><td class="right">   Transport Layer Security (TLS, [RFC5246]) is used to establish</td><td class="lineno" valign="top"></td></tr>
    300       <tr><td class="lineno" valign="top"></td><td class="left">   confidential communication through a shared firewall proxy.</td><td> </td><td class="right">   confidential communication through a shared firewall proxy.</td><td class="lineno" valign="top"></td></tr>
    301       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    302       <tr bgcolor="gray" ><td></td><th><a name="part-l4" /><small>skipping to change at</small><em> page 13, line 49</em></th><th> </th><th><a name="part-r4" /><small>skipping to change at</small><em> page 14, line 4</em></th><td></td></tr>
    303       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    304       <tr><td class="lineno" valign="top"></td><td class="left">2.6.  Protocol Versioning</td><td> </td><td class="right">2.6.  Protocol Versioning</td><td class="lineno" valign="top"></td></tr>
    305       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    306       <tr><td class="lineno" valign="top"></td><td class="left">   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions</td><td> </td><td class="right">   HTTP uses a "&lt;major&gt;.&lt;minor&gt;" numbering scheme to indicate versions</td><td class="lineno" valign="top"></td></tr>
    307       <tr><td class="lineno" valign="top"></td><td class="left">   of the protocol.  This specification defines version "1.1".  The</td><td> </td><td class="right">   of the protocol.  This specification defines version "1.1".  The</td><td class="lineno" valign="top"></td></tr>
    308       <tr><td class="lineno" valign="top"></td><td class="left">   protocol version as a whole indicates the sender's conformance with</td><td> </td><td class="right">   protocol version as a whole indicates the sender's conformance with</td><td class="lineno" valign="top"></td></tr>
    309       <tr><td class="lineno" valign="top"></td><td class="left">   the set of requirements laid out in that version's corresponding</td><td> </td><td class="right">   the set of requirements laid out in that version's corresponding</td><td class="lineno" valign="top"></td></tr>
    310       <tr><td class="lineno" valign="top"></td><td class="left">   specification of HTTP.</td><td> </td><td class="right">   specification of HTTP.</td><td class="lineno" valign="top"></td></tr>
    311       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    312       <tr><td class="lineno" valign="top"></td><td class="left">   The version of an HTTP message is indicated by an HTTP-version field</td><td> </td><td class="right">   The version of an HTTP message is indicated by an HTTP-version field</td><td class="lineno" valign="top"></td></tr>
    313       <tr><td><a name="diff0037" /></td></tr>
    314       <tr><td class="lineno" valign="top"></td><td class="lblock">   in the first line of the message.  HTTP-version is case<span class="delete">-</span>sensitive.</td><td> </td><td class="rblock">   in the first line of the message.  HTTP-version is case<span class="insert"> </span>sensitive.</td><td class="lineno" valign="top"></td></tr>
    315       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    316       <tr><td class="lineno" valign="top"></td><td class="left">     HTTP-version  = HTTP-name "/" DIGIT "." DIGIT</td><td> </td><td class="right">     HTTP-version  = HTTP-name "/" DIGIT "." DIGIT</td><td class="lineno" valign="top"></td></tr>
    317       <tr><td><a name="diff0038" /></td></tr>
    318       <tr><td class="lineno" valign="top"></td><td class="lblock">     HTTP-name     = %x48.54.54.50 ; "HTTP", case<span class="delete">-</span>sensitive</td><td> </td><td class="rblock">     HTTP-name     = %x48.54.54.50 ; "HTTP", case<span class="insert"> </span>sensitive</td><td class="lineno" valign="top"></td></tr>
    319       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    320       <tr><td class="lineno" valign="top"></td><td class="left">   The HTTP version number consists of two decimal digits separated by a</td><td> </td><td class="right">   The HTTP version number consists of two decimal digits separated by a</td><td class="lineno" valign="top"></td></tr>
    321       <tr><td class="lineno" valign="top"></td><td class="left">   "." (period or decimal point).  The first digit ("major version")</td><td> </td><td class="right">   "." (period or decimal point).  The first digit ("major version")</td><td class="lineno" valign="top"></td></tr>
    322       <tr><td class="lineno" valign="top"></td><td class="left">   indicates the HTTP messaging syntax, whereas the second digit ("minor</td><td> </td><td class="right">   indicates the HTTP messaging syntax, whereas the second digit ("minor</td><td class="lineno" valign="top"></td></tr>
    323       <tr><td class="lineno" valign="top"></td><td class="left">   version") indicates the highest minor version within that major</td><td> </td><td class="right">   version") indicates the highest minor version within that major</td><td class="lineno" valign="top"></td></tr>
    324       <tr><td class="lineno" valign="top"></td><td class="left">   version to which the sender is conformant and able to understand for</td><td> </td><td class="right">   version to which the sender is conformant and able to understand for</td><td class="lineno" valign="top"></td></tr>
    325       <tr><td class="lineno" valign="top"></td><td class="left">   future communication.  The minor version advertises the sender's</td><td> </td><td class="right">   future communication.  The minor version advertises the sender's</td><td class="lineno" valign="top"></td></tr>
    326       <tr><td class="lineno" valign="top"></td><td class="left">   communication capabilities even when the sender is only using a</td><td> </td><td class="right">   communication capabilities even when the sender is only using a</td><td class="lineno" valign="top"></td></tr>
    327       <tr><td class="lineno" valign="top"></td><td class="left">   backwards-compatible subset of the protocol, thereby letting the</td><td> </td><td class="right">   backwards-compatible subset of the protocol, thereby letting the</td><td class="lineno" valign="top"></td></tr>
    328       <tr><td class="lineno" valign="top"></td><td class="left">   recipient know that more advanced features can be used in response</td><td> </td><td class="right">   recipient know that more advanced features can be used in response</td><td class="lineno" valign="top"></td></tr>
    329       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    330       <tr bgcolor="gray" ><td></td><th><a name="part-l5" /><small>skipping to change at</small><em> page 14, line 36</em></th><th> </th><th><a name="part-r5" /><small>skipping to change at</small><em> page 14, line 39</em></th><td></td></tr>
    331       <tr><td class="lineno" valign="top"></td><td class="left">   The interpretation of a header field does not change between minor</td><td> </td><td class="right">   The interpretation of a header field does not change between minor</td><td class="lineno" valign="top"></td></tr>
    332       <tr><td class="lineno" valign="top"></td><td class="left">   versions of the same major HTTP version, though the default behavior</td><td> </td><td class="right">   versions of the same major HTTP version, though the default behavior</td><td class="lineno" valign="top"></td></tr>
    333       <tr><td class="lineno" valign="top"></td><td class="left">   of a recipient in the absence of such a field can change.  Unless</td><td> </td><td class="right">   of a recipient in the absence of such a field can change.  Unless</td><td class="lineno" valign="top"></td></tr>
    334       <tr><td class="lineno" valign="top"></td><td class="left">   specified otherwise, header fields defined in HTTP/1.1 are defined</td><td> </td><td class="right">   specified otherwise, header fields defined in HTTP/1.1 are defined</td><td class="lineno" valign="top"></td></tr>
    335       <tr><td class="lineno" valign="top"></td><td class="left">   for all versions of HTTP/1.x.  In particular, the Host and Connection</td><td> </td><td class="right">   for all versions of HTTP/1.x.  In particular, the Host and Connection</td><td class="lineno" valign="top"></td></tr>
    336       <tr><td class="lineno" valign="top"></td><td class="left">   header fields ought to be implemented by all HTTP/1.x implementations</td><td> </td><td class="right">   header fields ought to be implemented by all HTTP/1.x implementations</td><td class="lineno" valign="top"></td></tr>
    337       <tr><td class="lineno" valign="top"></td><td class="left">   whether or not they advertise conformance with HTTP/1.1.</td><td> </td><td class="right">   whether or not they advertise conformance with HTTP/1.1.</td><td class="lineno" valign="top"></td></tr>
    338       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    339       <tr><td class="lineno" valign="top"></td><td class="left">   New header fields can be introduced without changing the protocol</td><td> </td><td class="right">   New header fields can be introduced without changing the protocol</td><td class="lineno" valign="top"></td></tr>
    340       <tr><td class="lineno" valign="top"></td><td class="left">   version if their defined semantics allow them to be safely ignored by</td><td> </td><td class="right">   version if their defined semantics allow them to be safely ignored by</td><td class="lineno" valign="top"></td></tr>
    341       <tr><td><a name="diff0039" /></td></tr>
    342       <tr><td class="lineno" valign="top"></td><td class="lblock">   recipients that do not recognize them.  Header<span class="delete"> </span>field extensibility is</td><td> </td><td class="rblock">   recipients that do not recognize them.  Header<span class="insert">-</span>field extensibility is</td><td class="lineno" valign="top"></td></tr>
    343       <tr><td class="lineno" valign="top"></td><td class="left">   discussed in Section 3.2.1.</td><td> </td><td class="right">   discussed in Section 3.2.1.</td><td class="lineno" valign="top"></td></tr>
    344       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    345       <tr><td class="lineno" valign="top"></td><td class="left">   Intermediaries that process HTTP messages (i.e., all intermediaries</td><td> </td><td class="right">   Intermediaries that process HTTP messages (i.e., all intermediaries</td><td class="lineno" valign="top"></td></tr>
    346       <tr><td class="lineno" valign="top"></td><td class="left">   other than those acting as tunnels) MUST send their own HTTP-version</td><td> </td><td class="right">   other than those acting as tunnels) MUST send their own HTTP-version</td><td class="lineno" valign="top"></td></tr>
    347       <tr><td class="lineno" valign="top"></td><td class="left">   in forwarded messages.  In other words, they are not allowed to</td><td> </td><td class="right">   in forwarded messages.  In other words, they are not allowed to</td><td class="lineno" valign="top"></td></tr>
    348       <tr><td class="lineno" valign="top"></td><td class="left">   blindly forward the first line of an HTTP message without ensuring</td><td> </td><td class="right">   blindly forward the first line of an HTTP message without ensuring</td><td class="lineno" valign="top"></td></tr>
    349       <tr><td class="lineno" valign="top"></td><td class="left">   that the protocol version in that message matches a version to which</td><td> </td><td class="right">   that the protocol version in that message matches a version to which</td><td class="lineno" valign="top"></td></tr>
    350       <tr><td class="lineno" valign="top"></td><td class="left">   that intermediary is conformant for both the receiving and sending of</td><td> </td><td class="right">   that intermediary is conformant for both the receiving and sending of</td><td class="lineno" valign="top"></td></tr>
    351       <tr><td class="lineno" valign="top"></td><td class="left">   messages.  Forwarding an HTTP message without rewriting the HTTP-</td><td> </td><td class="right">   messages.  Forwarding an HTTP message without rewriting the HTTP-</td><td class="lineno" valign="top"></td></tr>
    352       <tr><td class="lineno" valign="top"></td><td class="left">   version might result in communication errors when downstream</td><td> </td><td class="right">   version might result in communication errors when downstream</td><td class="lineno" valign="top"></td></tr>
    353       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    354       <tr bgcolor="gray" ><td></td><th><a name="part-l6" /><small>skipping to change at</small><em> page 15, line 48</em></th><th> </th><th><a name="part-r6" /><small>skipping to change at</small><em> page 15, line 51</em></th><td></td></tr>
    355       <tr><td class="lineno" valign="top"></td><td class="left">   introduced between [RFC2068] and [RFC2616], and this revision has</td><td> </td><td class="right">   introduced between [RFC2068] and [RFC2616], and this revision has</td><td class="lineno" valign="top"></td></tr>
    356       <tr><td class="lineno" valign="top"></td><td class="left">   specifically avoided any such changes to the protocol.</td><td> </td><td class="right">   specifically avoided any such changes to the protocol.</td><td class="lineno" valign="top"></td></tr>
    357       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    358       <tr><td class="lineno" valign="top"></td><td class="left">   When an HTTP message is received with a major version number that the</td><td> </td><td class="right">   When an HTTP message is received with a major version number that the</td><td class="lineno" valign="top"></td></tr>
    359       <tr><td class="lineno" valign="top"></td><td class="left">   recipient implements, but a higher minor version number than what the</td><td> </td><td class="right">   recipient implements, but a higher minor version number than what the</td><td class="lineno" valign="top"></td></tr>
    360       <tr><td class="lineno" valign="top"></td><td class="left">   recipient implements, the recipient SHOULD process the message as if</td><td> </td><td class="right">   recipient implements, the recipient SHOULD process the message as if</td><td class="lineno" valign="top"></td></tr>
    361       <tr><td class="lineno" valign="top"></td><td class="left">   it were in the highest minor version within that major version to</td><td> </td><td class="right">   it were in the highest minor version within that major version to</td><td class="lineno" valign="top"></td></tr>
    362       <tr><td class="lineno" valign="top"></td><td class="left">   which the recipient is conformant.  A recipient can assume that a</td><td> </td><td class="right">   which the recipient is conformant.  A recipient can assume that a</td><td class="lineno" valign="top"></td></tr>
    363       <tr><td class="lineno" valign="top"></td><td class="left">   message with a higher minor version, when sent to a recipient that</td><td> </td><td class="right">   message with a higher minor version, when sent to a recipient that</td><td class="lineno" valign="top"></td></tr>
    364       <tr><td class="lineno" valign="top"></td><td class="left">   has not yet indicated support for that higher version, is</td><td> </td><td class="right">   has not yet indicated support for that higher version, is</td><td class="lineno" valign="top"></td></tr>
    365       <tr><td><a name="diff0040" /></td></tr>
    366       <tr><td class="lineno" valign="top"></td><td class="lblock">   sufficiently backwards<span class="delete">-</span>compatible to be safely processed by any</td><td> </td><td class="rblock">   sufficiently backwards<span class="insert"> </span>compatible to be safely processed by any</td><td class="lineno" valign="top"></td></tr>
    367       <tr><td class="lineno" valign="top"></td><td class="left">   implementation of the same major version.</td><td> </td><td class="right">   implementation of the same major version.</td><td class="lineno" valign="top"></td></tr>
    368       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    369       <tr><td class="lineno" valign="top"></td><td class="left">2.7.  Uniform Resource Identifiers</td><td> </td><td class="right">2.7.  Uniform Resource Identifiers</td><td class="lineno" valign="top"></td></tr>
    370       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    371       <tr><td class="lineno" valign="top"></td><td class="left">   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout</td><td> </td><td class="right">   Uniform Resource Identifiers (URIs) [RFC3986] are used throughout</td><td class="lineno" valign="top"></td></tr>
    372       <tr><td class="lineno" valign="top"></td><td class="left">   HTTP as the means for identifying resources (Section 2 of [RFC7231]).</td><td> </td><td class="right">   HTTP as the means for identifying resources (Section 2 of [RFC7231]).</td><td class="lineno" valign="top"></td></tr>
    373       <tr><td class="lineno" valign="top"></td><td class="left">   URI references are used to target requests, indicate redirects, and</td><td> </td><td class="right">   URI references are used to target requests, indicate redirects, and</td><td class="lineno" valign="top"></td></tr>
    374       <tr><td class="lineno" valign="top"></td><td class="left">   define relationships.</td><td> </td><td class="right">   define relationships.</td><td class="lineno" valign="top"></td></tr>
    375       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    376       <tr><td class="lineno" valign="top"></td><td class="left">   The definitions of "URI-reference", "absolute-URI", "relative-part",</td><td> </td><td class="right">   The definitions of "URI-reference", "absolute-URI", "relative-part",</td><td class="lineno" valign="top"></td></tr>
    377       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    378       <tr bgcolor="gray" ><td></td><th><a name="part-l7" /><small>skipping to change at</small><em> page 16, line 50</em></th><th> </th><th><a name="part-r7" /><small>skipping to change at</small><em> page 16, line 50</em></th><td></td></tr>
    379       <tr><td class="lineno" valign="top"></td><td class="left">   of reference (URI-reference), only a URI in absolute form (absolute-</td><td> </td><td class="right">   of reference (URI-reference), only a URI in absolute form (absolute-</td><td class="lineno" valign="top"></td></tr>
    380       <tr><td class="lineno" valign="top"></td><td class="left">   URI), only the path and optional query components, or some</td><td> </td><td class="right">   URI), only the path and optional query components, or some</td><td class="lineno" valign="top"></td></tr>
    381       <tr><td class="lineno" valign="top"></td><td class="left">   combination of the above.  Unless otherwise indicated, URI references</td><td> </td><td class="right">   combination of the above.  Unless otherwise indicated, URI references</td><td class="lineno" valign="top"></td></tr>
    382       <tr><td class="lineno" valign="top"></td><td class="left">   are parsed relative to the effective request URI (Section 5.5).</td><td> </td><td class="right">   are parsed relative to the effective request URI (Section 5.5).</td><td class="lineno" valign="top"></td></tr>
    383       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    384       <tr><td class="lineno" valign="top"></td><td class="left">2.7.1.  http URI Scheme</td><td> </td><td class="right">2.7.1.  http URI Scheme</td><td class="lineno" valign="top"></td></tr>
    385       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    386       <tr><td class="lineno" valign="top"></td><td class="left">   The "http" URI scheme is hereby defined for the purpose of minting</td><td> </td><td class="right">   The "http" URI scheme is hereby defined for the purpose of minting</td><td class="lineno" valign="top"></td></tr>
    387       <tr><td class="lineno" valign="top"></td><td class="left">   identifiers according to their association with the hierarchical</td><td> </td><td class="right">   identifiers according to their association with the hierarchical</td><td class="lineno" valign="top"></td></tr>
    388       <tr><td class="lineno" valign="top"></td><td class="left">   namespace governed by a potential HTTP origin server listening for</td><td> </td><td class="right">   namespace governed by a potential HTTP origin server listening for</td><td class="lineno" valign="top"></td></tr>
    389       <tr><td><a name="diff0041" /></td></tr>
    390       <tr><td class="lineno" valign="top"></td><td class="lblock">   TCP ([RFC<span class="delete">0</span>793]) connections on a given port.</td><td> </td><td class="rblock">   TCP ([RFC793]) connections on a given port.</td><td class="lineno" valign="top"></td></tr>
    391       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    392       <tr><td class="lineno" valign="top"></td><td class="left">     http-URI = "http:" "//" authority path-abempty [ "?" query ]</td><td> </td><td class="right">     http-URI = "http:" "//" authority path-abempty [ "?" query ]</td><td class="lineno" valign="top"></td></tr>
    393       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    394       <tr><td class="lineno" valign="top"></td><td class="left">                [ "#" fragment ]</td><td> </td><td class="right">                [ "#" fragment ]</td><td class="lineno" valign="top"></td></tr>
    395       <tr><td class="lineno" valign="top"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno" valign="top"></td></tr>
    396       <tr><td class="lineno" valign="top"></td><td class="left">   The origin server for an "http" URI is identified by the authority</td><td> </td><td class="right">   The origin server for an "http" URI is identified by the authority</td><td class="lineno" valign="top"></td></tr>
    397       <tr><td class="lineno" valign="top"></td><td class="left">   component, which includes a host identifier and optional TCP port</td><td> </td><td class="right">   component, which includes a host identifier and optional TCP port</td><td class="lineno" valign="top"></td></tr>
    398       <tr><td class="lineno" valign="top"></td><td class="left">   ([RFC3986], Section 3.2.2).  The hierarchical path component and</td><td> </td><td class="right">   ([RFC3986], Section 3.2.2).  The hierarchical path component and</td><td class="lineno" valign="top"></td></tr>
    399       <tr><td class="lineno" valign="top"></td><td class="left">   optional query component serve as an identifier for a potential</td><td> </td><td class="right">   optional query component serve as an identifier for a potential</td><td class="lineno" valign="top"></td></tr>
    400       <tr><td class="lineno" valign="top"></td><td class="left">   target resource within that origin server's name space.  The optional</td><td> </td><td class="right">   target resource within that origin server's name space.  The optional</td><td class="lineno" valign="top"></td></tr>
    401       <tr><td class="lineno"></td><td class="left"></td><td> </td><td class="right"></td><td class="lineno"></td></tr>
    402       <tr bgcolor="gray" ><td></td><th><a name="part-l8" /><small>skipping to change at</small><em> page 19, line 18</em></th><t