source: draft-ietf-httpbis/latest/auth48/rfc7230.abdiff.txt @ 2718

Last change on this file since 2718 was 2718, checked in by julian.reschke@…, 9 years ago

update AUTH48 versions (#553)
  • Property svn:eol-style set to native
File size: 50.1 KB
Line 
1
2INTRODUCTION, paragraph 5:
3OLD:
4
5 Editorial Note (To be removed by RFC Editor)
6 
7    Discussion of this draft takes place on the HTTPBIS working group
8    mailing list (ietf-http-wg@w3.org), which is archived at
9    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
10 
11    The current issues list is at
12    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
13    documents (including fancy diffs) can be found at
14    <http://tools.ietf.org/wg/httpbis/>.
15 
16    _This is a temporary document for the purpose of tracking the
17    editorial changes made during the AUTH48 (RFC publication) phase._
18 
19 Status of This Memo
20
21NEW:
22
23 Status of This Memo
24
25
26INTRODUCTION, paragraph 14:
27OLD:
28
29    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
30      1.1.  Requirements Notation  . . . . . . . . . . . . . . . . . .  6
31      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  6
32    2.  Architecture . . . . . . . . . . . . . . . . . . . . . . . . .  6
33      2.1.  Client/Server Messaging  . . . . . . . . . . . . . . . . .  7
34      2.2.  Implementation Diversity . . . . . . . . . . . . . . . . .  8
35      2.3.  Intermediaries . . . . . . . . . . . . . . . . . . . . . .  9
36      2.4.  Caches . . . . . . . . . . . . . . . . . . . . . . . . . . 11
37      2.5.  Conformance and Error Handling . . . . . . . . . . . . . . 12
38      2.6.  Protocol Versioning  . . . . . . . . . . . . . . . . . . . 13
39      2.7.  Uniform Resource Identifiers . . . . . . . . . . . . . . . 16
40        2.7.1.  http URI Scheme  . . . . . . . . . . . . . . . . . . . 16
41        2.7.2.  https URI Scheme . . . . . . . . . . . . . . . . . . . 18
42        2.7.3.  http and https URI Normalization and Comparison  . . . 19
43    3.  Message Format . . . . . . . . . . . . . . . . . . . . . . . . 19
44      3.1.  Start Line . . . . . . . . . . . . . . . . . . . . . . . . 20
45        3.1.1.  Request Line . . . . . . . . . . . . . . . . . . . . . 21
46        3.1.2.  Status Line  . . . . . . . . . . . . . . . . . . . . . 22
47      3.2.  Header Fields  . . . . . . . . . . . . . . . . . . . . . . 22
48        3.2.1.  Field Extensibility  . . . . . . . . . . . . . . . . . 23
49        3.2.2.  Field Order  . . . . . . . . . . . . . . . . . . . . . 23
50        3.2.3.  Whitespace . . . . . . . . . . . . . . . . . . . . . . 24
51        3.2.4.  Field Parsing  . . . . . . . . . . . . . . . . . . . . 24
52        3.2.5.  Field Limits . . . . . . . . . . . . . . . . . . . . . 26
53        3.2.6.  Field Value Components . . . . . . . . . . . . . . . . 26
54      3.3.  Message Body . . . . . . . . . . . . . . . . . . . . . . . 27
55        3.3.1.  Transfer-Encoding  . . . . . . . . . . . . . . . . . . 28
56        3.3.2.  Content-Length . . . . . . . . . . . . . . . . . . . . 29
57        3.3.3.  Message Body Length  . . . . . . . . . . . . . . . . . 31
58      3.4.  Handling Incomplete Messages . . . . . . . . . . . . . . . 33
59      3.5.  Message Parsing Robustness . . . . . . . . . . . . . . . . 34
60    4.  Transfer Codings . . . . . . . . . . . . . . . . . . . . . . . 34
61      4.1.  Chunked Transfer Coding  . . . . . . . . . . . . . . . . . 35
62        4.1.1.  Chunk Extensions . . . . . . . . . . . . . . . . . . . 36
63        4.1.2.  Chunked Trailer Part . . . . . . . . . . . . . . . . . 36
64        4.1.3.  Decoding Chunked . . . . . . . . . . . . . . . . . . . 37
65      4.2.  Compression Codings  . . . . . . . . . . . . . . . . . . . 37
66        4.2.1.  Compress Coding  . . . . . . . . . . . . . . . . . . . 38
67        4.2.2.  Deflate Coding . . . . . . . . . . . . . . . . . . . . 38
68        4.2.3.  Gzip Coding  . . . . . . . . . . . . . . . . . . . . . 38
69      4.3.  TE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
70      4.4.  Trailer  . . . . . . . . . . . . . . . . . . . . . . . . . 39
71    5.  Message Routing  . . . . . . . . . . . . . . . . . . . . . . . 39
72      5.1.  Identifying a Target Resource  . . . . . . . . . . . . . . 40
73      5.2.  Connecting Inbound . . . . . . . . . . . . . . . . . . . . 40
74      5.3.  Request Target . . . . . . . . . . . . . . . . . . . . . . 41
75        5.3.1.  origin-form  . . . . . . . . . . . . . . . . . . . . . 41
76        5.3.2.  absolute-form  . . . . . . . . . . . . . . . . . . . . 41
77        5.3.3.  authority-form . . . . . . . . . . . . . . . . . . . . 42
78        5.3.4.  asterisk-form  . . . . . . . . . . . . . . . . . . . . 42
79      5.4.  Host . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
80      5.5.  Effective Request URI  . . . . . . . . . . . . . . . . . . 44
81      5.6.  Associating a Response to a Request  . . . . . . . . . . . 46
82      5.7.  Message Forwarding . . . . . . . . . . . . . . . . . . . . 46
83        5.7.1.  Via  . . . . . . . . . . . . . . . . . . . . . . . . . 46
84        5.7.2.  Transformations  . . . . . . . . . . . . . . . . . . . 48
85    6.  Connection Management  . . . . . . . . . . . . . . . . . . . . 49
86      6.1.  Connection . . . . . . . . . . . . . . . . . . . . . . . . 50
87      6.2.  Establishment  . . . . . . . . . . . . . . . . . . . . . . 51
88      6.3.  Persistence  . . . . . . . . . . . . . . . . . . . . . . . 51
89        6.3.1.  Retrying Requests  . . . . . . . . . . . . . . . . . . 52
90        6.3.2.  Pipelining . . . . . . . . . . . . . . . . . . . . . . 53
91      6.4.  Concurrency  . . . . . . . . . . . . . . . . . . . . . . . 54
92      6.5.  Failures and Timeouts  . . . . . . . . . . . . . . . . . . 54
93      6.6.  Tear-down  . . . . . . . . . . . . . . . . . . . . . . . . 55
94      6.7.  Upgrade  . . . . . . . . . . . . . . . . . . . . . . . . . 56
95    7.  ABNF List Extension: #rule . . . . . . . . . . . . . . . . . . 58
96    8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 59
97      8.1.  Header Field Registration  . . . . . . . . . . . . . . . . 59
98      8.2.  URI Scheme Registration  . . . . . . . . . . . . . . . . . 60
99      8.3.  Internet Media Type Registration . . . . . . . . . . . . . 60
100        8.3.1.  Internet Media Type message/http . . . . . . . . . . . 61
101        8.3.2.  Internet Media Type application/http . . . . . . . . . 62
102      8.4.  Transfer Coding Registry . . . . . . . . . . . . . . . . . 63
103        8.4.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 63
104        8.4.2.  Registration . . . . . . . . . . . . . . . . . . . . . 64
105      8.5.  Content Coding Registration  . . . . . . . . . . . . . . . 64
106      8.6.  Upgrade Token Registry . . . . . . . . . . . . . . . . . . 64
107        8.6.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 65
108        8.6.2.  Upgrade Token Registration . . . . . . . . . . . . . . 65
109    9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 66
110      9.1.  Establishing Authority . . . . . . . . . . . . . . . . . . 66
111      9.2.  Risks of Intermediaries  . . . . . . . . . . . . . . . . . 67
112      9.3.  Attacks via Protocol Element Length  . . . . . . . . . . . 67
113      9.4.  Response Splitting . . . . . . . . . . . . . . . . . . . . 68
114      9.5.  Request Smuggling  . . . . . . . . . . . . . . . . . . . . 69
115      9.6.  Message Integrity  . . . . . . . . . . . . . . . . . . . . 69
116      9.7.  Message Confidentiality  . . . . . . . . . . . . . . . . . 69
117      9.8.  Privacy of Server Log Information  . . . . . . . . . . . . 70
118    10. Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 70
119    11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 72
120      11.1. Normative References . . . . . . . . . . . . . . . . . . . 72
121      11.2. Informative References . . . . . . . . . . . . . . . . . . 73
122    Appendix A.  HTTP Version History  . . . . . . . . . . . . . . . . 75
123      A.1.  Changes from HTTP/1.0  . . . . . . . . . . . . . . . . . . 76
124        A.1.1.  Multihomed Web Servers . . . . . . . . . . . . . . . . 76
125        A.1.2.  Keep-Alive Connections . . . . . . . . . . . . . . . . 76
126        A.1.3.  Introduction of Transfer-Encoding  . . . . . . . . . . 77
127      A.2.  Changes from RFC 2616  . . . . . . . . . . . . . . . . . . 77
128    Appendix B.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 79
129    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
130
131NEW:
132
133    1. Introduction ....................................................5
134       1.1. Requirements Notation ......................................6
135       1.2. Syntax Notation ............................................6
136    2. Architecture ....................................................6
137       2.1. Client/Server Messaging ....................................7
138       2.2. Implementation Diversity ...................................8
139       2.3. Intermediaries .............................................9
140       2.4. Caches ....................................................11
141       2.5. Conformance and Error Handling ............................12
142       2.6. Protocol Versioning .......................................13
143       2.7. Uniform Resource Identifiers ..............................16
144            2.7.1. http URI Scheme ....................................17
145            2.7.2. https URI Scheme ...................................18
146            2.7.3. http and https URI Normalization and Comparison ....19
147    3. Message Format .................................................19
148       3.1. Start Line ................................................20
149            3.1.1. Request Line .......................................21
150            3.1.2. Status Line ........................................22
151       3.2. Header Fields .............................................22
152            3.2.1. Field Extensibility ................................23
153            3.2.2. Field Order ........................................23
154            3.2.3. Whitespace .........................................24
155            3.2.4. Field Parsing ......................................25
156            3.2.5. Field Limits .......................................26
157            3.2.6. Field Value Components .............................27
158       3.3. Message Body ..............................................28
159            3.3.1. Transfer-Encoding ..................................28
160            3.3.2. Content-Length .....................................30
161            3.3.3. Message Body Length ................................32
162       3.4. Handling Incomplete Messages ..............................34
163       3.5. Message Parsing Robustness ................................34
164    4. Transfer Codings ...............................................35
165       4.1. Chunked Transfer Coding ...................................36
166            4.1.1. Chunk Extensions ...................................36
167            4.1.2. Chunked Trailer Part ...............................37
168            4.1.3. Decoding Chunked ...................................38
169       4.2. Compression Codings .......................................38
170            4.2.1. Compress Coding ....................................38
171            4.2.2. Deflate Coding .....................................38
172            4.2.3. Gzip Coding ........................................39
173       4.3. TE ........................................................39
174       4.4. Trailer ...................................................40
175    5. Message Routing ................................................40
176       5.1. Identifying a Target Resource .............................40
177       5.2. Connecting Inbound ........................................41
178       5.3. Request Target ............................................41
179            5.3.1. origin-form ........................................42
180            5.3.2. absolute-form ......................................42
181            5.3.3. authority-form .....................................43
182            5.3.4. asterisk-form ......................................43
183       5.4. Host ......................................................44
184       5.5. Effective Request URI .....................................45
185       5.6. Associating a Response to a Request .......................46
186       5.7. Message Forwarding ........................................47
187            5.7.1. Via ................................................47
188            5.7.2. Transformations ....................................49
189    6. Connection Management ..........................................50
190       6.1. Connection ................................................51
191       6.2. Establishment .............................................52
192       6.3. Persistence ...............................................52
193            6.3.1. Retrying Requests ..................................53
194            6.3.2. Pipelining .........................................54
195       6.4. Concurrency ...............................................55
196       6.5. Failures and Timeouts .....................................55
197       6.6. Tear-down .................................................56
198       6.7. Upgrade ...................................................57
199    7. ABNF List Extension: #rule .....................................59
200    8. IANA Considerations ............................................61
201       8.1. Header Field Registration .................................61
202       8.2. URI Scheme Registration ...................................62
203       8.3. Internet Media Type Registration ..........................62
204            8.3.1. Internet Media Type message/http ...................62
205            8.3.2. Internet Media Type application/http ...............63
206       8.4. Transfer Coding Registry ..................................64
207            8.4.1. Procedure ..........................................65
208            8.4.2. Registration .......................................65
209       8.5. Content Coding Registration ...............................66
210       8.6. Upgrade Token Registry ....................................66
211            8.6.1. Procedure ..........................................66
212            8.6.2. Upgrade Token Registration .........................67
213    9. Security Considerations ........................................67
214       9.1. Establishing Authority ....................................67
215       9.2. Risks of Intermediaries ...................................68
216       9.3. Attacks via Protocol Element Length .......................69
217       9.4. Response Splitting ........................................69
218       9.5. Request Smuggling .........................................70
219       9.6. Message Integrity .........................................70
220       9.7. Message Confidentiality ...................................71
221       9.8. Privacy of Server Log Information .........................71
222    10. Acknowledgments ...............................................72
223    11. References ....................................................74
224       11.1. Normative References .....................................74
225       11.2. Informative References ...................................75
226    Appendix A. HTTP Version History ..................................78
227       A.1. Changes from HTTP/1.0  ....................................78
228            A.1.1.  Multihomed Web Servers ............................78
229            A.1.2.  Keep-Alive Connections ............................79
230            A.1.3.  Introduction of Transfer-Encoding .................79
231       A.2.  Changes from RFC 2616 ....................................80
232    Appendix B. Collected ABNF ........................................82
233    Index .............................................................85
234
235
236Section 2.1., paragraph 4:
237OLD:
238
239    Most HTTP communication consists of a retrieval request (GET) for a
240    representation of some resource identified by a URI.  In the simplest
241    case, this might be accomplished via a single bidirectional
242    connection (===) between the user agent (UA) and the origin server
243    (O).
244
245NEW:
246
247    Most HTTP communication consists of a retrieval request (GET) for a
248    representation of some resource identified by a URI.  In the simplest
249    case, this might be accomplished via a single bidirectional
250    connection (===) between the user agent (UA) and the origin
251    server (O).
252
253
254Section 2.5., paragraph 5:
255OLD:
256
257    When a received protocol element is parsed, the recipient MUST be
258    able to parse any value of reasonable length that is applicable to
259    the recipient's role and that matches the grammar defined by the
260    corresponding ABNF rules.  Note, however, that some received protocol
261    elements might not be parsed.  For example, an intermediary
262    forwarding a message might parse a header-field into generic field-
263    name and field-value components, but then forward the header field
264    without further parsing inside the field-value.
265
266NEW:
267
268    When a received protocol element is parsed, the recipient MUST be
269    able to parse any value of reasonable length that is applicable to
270    the recipient's role and that matches the grammar defined by the
271    corresponding ABNF rules.  Note, however, that some received protocol
272    elements might not be parsed.  For example, an intermediary
273    forwarding a message might parse a header-field into generic
274    field-name and field-value components, but then forward the header
275    field without further parsing inside the field-value.
276
277
278Section 2.5., paragraph 8:
279OLD:
280
281    A recipient MUST interpret a received protocol element according to
282    the semantics defined for it by this specification, including
283    extensions to this specification, unless the recipient has determined
284    (through experience or configuration) that the sender incorrectly
285    implements what is implied by those semantics.  For example, an
286    origin server might disregard the contents of a received Accept-
287    Encoding header field if inspection of the User-Agent header field
288    indicates a specific implementation version that is known to fail on
289    receipt of certain content codings.
290
291NEW:
292
293    A recipient MUST interpret a received protocol element according to
294    the semantics defined for it by this specification, including
295    extensions to this specification, unless the recipient has determined
296    (through experience or configuration) that the sender incorrectly
297    implements what is implied by those semantics.  For example, an
298    origin server might disregard the contents of a received
299    Accept-Encoding header field if inspection of the User-Agent header
300    field indicates a specific implementation version that is known to
301    fail on receipt of certain content codings.
302
303
304Section 2.6., paragraph 8:
305OLD:
306
307    Intermediaries that process HTTP messages (i.e., all intermediaries
308    other than those acting as tunnels) MUST send their own HTTP-version
309    in forwarded messages.  In other words, they are not allowed to
310    blindly forward the first line of an HTTP message without ensuring
311    that the protocol version in that message matches a version to which
312    that intermediary is conformant for both the receiving and sending of
313    messages.  Forwarding an HTTP message without rewriting the HTTP-
314    version might result in communication errors when downstream
315    recipients use the message sender's version to determine what
316    features are safe to use for later communication with that sender.
317
318NEW:
319
320    Intermediaries that process HTTP messages (i.e., all intermediaries
321    other than those acting as tunnels) MUST send their own HTTP-version
322    in forwarded messages.  In other words, they are not allowed to
323    blindly forward the first line of an HTTP message without ensuring
324    that the protocol version in that message matches a version to which
325    that intermediary is conformant for both the receiving and sending of
326    messages.  Forwarding an HTTP message without rewriting the
327    HTTP-version might result in communication errors when downstream
328    recipients use the message sender's version to determine what
329    features are safe to use for later communication with that sender.
330
331
332Section 2.7., paragraph 5:
333OLD:
334
335    Each protocol element in HTTP that allows a URI reference will
336    indicate in its ABNF production whether the element allows any form
337    of reference (URI-reference), only a URI in absolute form (absolute-
338    URI), only the path and optional query components, or some
339    combination of the above.  Unless otherwise indicated, URI references
340    are parsed relative to the effective request URI (Section 5.5).
341
342NEW:
343
344    Each protocol element in HTTP that allows a URI reference will
345    indicate in its ABNF production whether the element allows any form
346    of reference (URI-reference), only a URI in absolute form
347    (absolute-URI), only the path and optional query components, or some
348    combination of the above.  Unless otherwise indicated, URI references
349    are parsed relative to the effective request URI (Section 5.5).
350
351
352Section 2.7.1., paragraph 2:
353OLD:
354
355      http-URI = "http:" "//" authority path-abempty [ "?" query ]
356 
357                 [ "#" fragment ]
358
359NEW:
360
361      http-URI = "http:" "//" authority path-abempty [ "?" query ]
362                 [ "#" fragment ]
363
364
365Section 2.7.3., paragraph 2:
366OLD:
367
368    If the port is equal to the default port for a scheme, the normal
369    form is to omit the port subcomponent.  When not being used in
370    absolute form as the request target of an OPTIONS request, an empty
371    path component is equivalent to an absolute path of "/", so the
372    normal form is to provide a path of "/" instead.  The scheme and host
373    are case-insensitive and normally provided in lowercase; all other
374    components are compared in a case-sensitive manner.  Characters other
375    than those in the "reserved" set are equivalent to their percent-
376    encoded octets: the normal form is to not encode them (see Sections
377    2.1 and 2.2 of [RFC3986]).
378
379NEW:
380
381    If the port is equal to the default port for a scheme, the normal
382    form is to omit the port subcomponent.  When not being used in
383    absolute form as the request target of an OPTIONS request, an empty
384    path component is equivalent to an absolute path of "/", so the
385    normal form is to provide a path of "/" instead.  The scheme and host
386    are case-insensitive and normally provided in lowercase; all other
387    components are compared in a case-sensitive manner.  Characters other
388    than those in the "reserved" set are equivalent to their
389    percent-encoded octets: the normal form is to not encode them (see
390    Sections 2.1 and 2.2 of [RFC3986]).
391
392
393Section 400, paragraph 1:
394OLD:
395
396    HTTP does not place a predefined limit on the length of a request-
397    line, as described in Section 2.5.  A server that receives a method
398    longer than any that it implements SHOULD respond with a 501 (Not
399    Implemented) status code.  A server that receives a request-target
400    longer than any URI it wishes to parse MUST respond with a 414 (URI
401    Too Long) status code (see Section 6.5.12 of [RFC7231]).
402
403NEW:
404
405    HTTP does not place a predefined limit on the length of a
406    request-line, as described in Section 2.5.  A server that receives a
407    method longer than any that it implements SHOULD respond with a 501
408    (Not Implemented) status code.  A server that receives a
409    request-target longer than any URI it wishes to parse MUST respond
410    with a 414 (URI Too Long) status code (see Section 6.5.12 of
411    [RFC7231]).
412
413
414Section 3.2.4., paragraph 3:
415OLD:
416
417    A field value might be preceded and/or followed by optional
418    whitespace (OWS); a single SP preceding the field-value is preferred
419    for consistent readability by humans.  The field value does not
420    include any leading or trailing whitespace: OWS occurring before the
421    first non-whitespace octet of the field value or after the last non-
422    whitespace octet of the field value ought to be excluded by parsers
423    when extracting the field value from a header field.
424
425NEW:
426
427    A field value might be preceded and/or followed by optional
428    whitespace (OWS); a single SP preceding the field-value is preferred
429    for consistent readability by humans.  The field value does not
430    include any leading or trailing whitespace: OWS occurring before the
431    first non-whitespace octet of the field value or after the last
432    non-whitespace octet of the field value ought to be excluded by
433    parsers when extracting the field value from a header field.
434
435
436Section 3.2.4., paragraph 7:
437OLD:
438
439    A user agent that receives an obs-fold in a response message that is
440    not within a message/http container MUST replace each received obs-
441    fold with one or more SP octets prior to interpreting the field
442    value.
443
444NEW:
445
446    A user agent that receives an obs-fold in a response message that is
447    not within a message/http container MUST replace each received
448    obs-fold with one or more SP octets prior to interpreting the field
449    value.
450
451
452Section 3.3., paragraph 4:
453OLD:
454
455    The presence of a message body in a request is signaled by a Content-
456    Length or Transfer-Encoding header field.  Request message framing is
457    independent of method semantics, even if the method does not define
458    any use for a message body.
459
460NEW:
461
462    The presence of a message body in a request is signaled by a
463    Content-Length or Transfer-Encoding header field.  Request message
464    framing is independent of method semantics, even if the method does
465    not define any use for a message body.
466
467
468Section 3.3.1., paragraph 8:
469OLD:
470
471    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]), Transfer-
472    Encoding is a property of the message, not of the representation, and
473    any recipient along the request/response chain MAY decode the
474    received transfer coding(s) or apply additional transfer coding(s) to
475    the message body, assuming that corresponding changes are made to the
476    Transfer-Encoding field-value.  Additional information about the
477    encoding parameters can be provided by other header fields not
478    defined by this specification.
479
480NEW:
481
482    Unlike Content-Encoding (Section 3.1.2.1 of [RFC7231]),
483    Transfer-Encoding is a property of the message, not of the
484    representation, and any recipient along the request/response chain
485    MAY decode the received transfer coding(s) or apply additional
486    transfer coding(s) to the message body, assuming that corresponding
487    changes are made to the Transfer-Encoding field-value.  Additional
488    information about the encoding parameters can be provided by other
489    header fields not defined by this specification.
490
491
492Section 3.3.2., paragraph 10:
493OLD:
494
495    Aside from the cases defined above, in the absence of Transfer-
496    Encoding, an origin server SHOULD send a Content-Length header field
497    when the payload body size is known prior to sending the complete
498    header section.  This will allow downstream recipients to measure
499    transfer progress, know when a received message is complete, and
500    potentially reuse the connection for additional requests.
501
502NEW:
503
504    Aside from the cases defined above, in the absence of
505    Transfer-Encoding, an origin server SHOULD send a Content-Length
506    header field when the payload body size is known prior to sending the
507    complete header section.  This will allow downstream recipients to
508    measure transfer progress, know when a received message is complete,
509    and potentially reuse the connection for additional requests.
510
511
512Section 3.3.2., paragraph 13:
513OLD:
514
515       Note: HTTP's use of Content-Length for message framing differs
516       significantly from the same field's use in MIME, where it is an
517       optional field used only within the "message/external-body" media-
518       type.
519
520NEW:
521
522       Note: HTTP's use of Content-Length for message framing differs
523       significantly from the same field's use in MIME, where it is an
524       optional field used only within the "message/external-body"
525       media-type.
526
527
528Section 7., paragraph 1:
529OLD:
530
531    Since there is no way to distinguish a successfully completed, close-
532    delimited message from a partially received message interrupted by
533    network failure, a server SHOULD generate encoding or length-
534    delimited messages whenever possible.  The close-delimiting feature
535    exists primarily for backwards compatibility with HTTP/1.0.
536
537NEW:
538
539    Since there is no way to distinguish a successfully completed,
540    close-delimited message from a partially received message interrupted
541    by network failure, a server SHOULD generate encoding or
542    length-delimited messages whenever possible.  The close-delimiting
543    feature exists primarily for backwards compatibility with HTTP/1.0.
544
545
546Section 4., paragraph 5:
547OLD:
548
549    All transfer-coding names are case-insensitive and ought to be
550    registered within the HTTP Transfer Coding registry, as defined in
551    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
552    Encoding (Section 3.3.1) header fields.
553
554NEW:
555
556    All transfer-coding names are case-insensitive and ought to be
557    registered within the HTTP Transfer Coding registry, as defined in
558    Section 8.4.  They are used in the TE (Section 4.3) and
559    Transfer-Encoding (Section 3.3.1) header fields.
560
561
562Section 4.1.1., paragraph 1:
563OLD:
564
565    The chunked encoding allows each chunk to include zero or more chunk
566    extensions, immediately following the chunk-size, for the sake of
567    supplying per-chunk metadata (such as a signature or hash), mid-
568    message control information, or randomization of message body size.
569
570NEW:
571
572    The chunked encoding allows each chunk to include zero or more chunk
573    extensions, immediately following the chunk-size, for the sake of
574    supplying per-chunk metadata (such as a signature or hash),
575    mid-message control information, or randomization of message body
576    size.
577
578
579Section 5.1., paragraph 1:
580OLD:
581
582    HTTP is used in a wide variety of applications, ranging from general-
583    purpose computers to home appliances.  In some cases, communication
584    options are hard-coded in a client's configuration.  However, most
585    HTTP clients rely on the same resource identification mechanism and
586    configuration techniques as general-purpose Web browsers.
587
588NEW:
589
590    HTTP is used in a wide variety of applications, ranging from
591    general-purpose computers to home appliances.  In some cases,
592    communication options are hard-coded in a client's configuration.
593    However, most HTTP clients rely on the same resource identification
594    mechanism and configuration techniques as general-purpose Web
595    browsers.
596
597
598Section 5.4., paragraph 8:
599OLD:
600
601    When a proxy receives a request with an absolute-form of request-
602    target, the proxy MUST ignore the received Host header field (if any)
603    and instead replace it with the host information of the request-
604    target.  A proxy that forwards such a request MUST generate a new
605    Host field-value based on the received request-target rather than
606    forward the received Host field-value.
607
608NEW:
609
610    When a proxy receives a request with an absolute-form of
611    request-target, the proxy MUST ignore the received Host header field
612    (if any) and instead replace it with the host information of the
613    request-target.  A proxy that forwards such a request MUST generate a
614    new Host field-value based on the received request-target rather than
615    forward the received Host field-value.
616
617
618Section 5.6., paragraph 2:
619OLD:
620
621    A client that has more than one outstanding request on a connection
622    MUST maintain a list of outstanding requests in the order sent and
623    MUST associate each received response message on that connection to
624    the highest ordered request that has not yet received a final (non-
625    1xx) response.
626
627NEW:
628
629    A client that has more than one outstanding request on a connection
630    MUST maintain a list of outstanding requests in the order sent and
631    MUST associate each received response message on that connection to
632    the highest ordered request that has not yet received a final
633    (non-1xx) response.
634
635
636Section 6.3.1., paragraph 2:
637OLD:
638
639    When an inbound connection is closed prematurely, a client MAY open a
640    new connection and automatically retransmit an aborted sequence of
641    requests if all of those requests have idempotent methods (Section
642    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry non-
643    idempotent requests.
644
645NEW:
646
647    When an inbound connection is closed prematurely, a client MAY open a
648    new connection and automatically retransmit an aborted sequence of
649    requests if all of those requests have idempotent methods (Section
650    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry
651    non-idempotent requests.
652
653
654Section 6.4., paragraph 3:
655OLD:
656
657    Multiple connections are typically used to avoid the "head-of-line
658    blocking" problem, wherein a request that takes significant server-
659    side processing and/or has a large payload blocks subsequent requests
660    on the same connection.  However, each connection consumes server
661    resources.  Furthermore, using multiple connections can cause
662    undesirable side effects in congested networks.
663
664NEW:
665
666    Multiple connections are typically used to avoid the "head-of-line
667    blocking" problem, wherein a request that takes significant
668    server-side processing and/or has a large payload blocks subsequent
669    requests on the same connection.  However, each connection consumes
670    server resources.  Furthermore, using multiple connections can cause
671    undesirable side effects in congested networks.
672
673
674Section 7., paragraph 2:
675OLD:
676
677    A construct "#" is defined, similar to "*", for defining comma-
678    delimited lists of elements.  The full form is "<n>#<m>element"
679    indicating at least <n> and at most <m> elements, each separated by a
680    single comma (",") and optional whitespace (OWS).
681
682NEW:
683
684    A construct "#" is defined, similar to "*", for defining
685    comma-delimited lists of elements.  The full form is "<n>#<m>element"
686    indicating at least <n> and at most <m> elements, each separated by a
687    single comma (",") and optional whitespace (OWS).
688
689
690Section 8.3.1., paragraph 17:
691OLD:
692
693       File extension(s):  N/A
694       Macintosh file type code(s):  N/A
695
696NEW:
697
698       File extension(s):  N/A
699 
700       Macintosh file type code(s):  N/A
701
702
703Section 8.3.2., paragraph 12:
704OLD:
705
706    Applications that use this media type:  N/A
707    Fragment identifier considerations:  N/A
708
709NEW:
710
711    Applications that use this media type:  N/A
712 
713    Fragment identifier considerations:  N/A
714
715
716Section 9.1., paragraph 1:
717OLD:
718
719    HTTP relies on the notion of an authoritative response: a response
720    that has been determined by (or at the direction of) the authority
721    identified within the target URI to be the most appropriate response
722    for that request given the state of the target resource at the time
723    of response message origination.  Providing a response from a non-
724    authoritative source, such as a shared cache, is often useful to
725    improve performance and availability, but only to the extent that the
726    source can be trusted or the distrusted response can be safely used.
727
728NEW:
729
730    HTTP relies on the notion of an authoritative response: a response
731    that has been determined by (or at the direction of) the authority
732    identified within the target URI to be the most appropriate response
733    for that request given the state of the target resource at the time
734    of response message origination.  Providing a response from a
735    non-authoritative source, such as a shared cache, is often useful to
736    improve performance and availability, but only to the extent that the
737    source can be trusted or the distrusted response can be safely used.
738
739
740Section 9.6., paragraph 1:
741OLD:
742
743    HTTP does not define a specific mechanism for ensuring message
744    integrity, instead relying on the error-detection ability of
745    underlying transport protocols and the use of length or chunk-
746    delimited framing to detect completeness.  Additional integrity
747    mechanisms, such as hash functions or digital signatures applied to
748    the content, can be selectively added to messages via extensible
749    metadata header fields.  Historically, the lack of a single integrity
750    mechanism has been justified by the informal nature of most HTTP
751    communication.  However, the prevalence of HTTP as an information
752    access mechanism has resulted in its increasing use within
753    environments where verification of message integrity is crucial.
754
755NEW:
756
757    HTTP does not define a specific mechanism for ensuring message
758    integrity, instead relying on the error-detection ability of
759    underlying transport protocols and the use of length or
760    chunk-delimited framing to detect completeness.  Additional integrity
761    mechanisms, such as hash functions or digital signatures applied to
762    the content, can be selectively added to messages via extensible
763    metadata header fields.  Historically, the lack of a single integrity
764    mechanism has been justified by the informal nature of most HTTP
765    communication.  However, the prevalence of HTTP as an information
766    access mechanism has resulted in its increasing use within
767    environments where verification of message integrity is crucial.
768
769
770Section 9.8., paragraph 3:
771OLD:
772
773    To minimize the risk of theft or accidental publication, log
774    information ought to be purged of personally identifiable
775    information, including user identifiers, IP addresses, and user-
776    provided query parameters, as soon as that information is no longer
777    necessary to support operational needs for security, auditing, or
778    fraud control.
779
780NEW:
781
782    To minimize the risk of theft or accidental publication, log
783    information ought to be purged of personally identifiable
784    information, including user identifiers, IP addresses, and
785    user-provided query parameters, as soon as that information is no
786    longer necessary to support operational needs for security, auditing,
787    or fraud control.
788
789
790Section 19.7.1, paragraph 4:
791OLD:
792
793    Clients are also encouraged to consider the use of Connection: keep-
794    alive in requests carefully; while they can enable persistent
795    connections with HTTP/1.0 servers, clients using them will need to
796    monitor the connection for "hung" requests (which indicate that the
797    client ought stop sending the header field), and this mechanism ought
798    not be used by clients at all when a proxy is being used.
799
800NEW:
801
802    Clients are also encouraged to consider the use of Connection:
803    keep-alive in requests carefully; while they can enable persistent
804    connections with HTTP/1.0 servers, clients using them will need to
805    monitor the connection for "hung" requests (which indicate that the
806    client ought stop sending the header field), and this mechanism ought
807    not be used by clients at all when a proxy is being used.
808
809
810Section 19.7.1, paragraph 21:
811OLD:
812
813    The meaning of the "deflate" content coding has been clarified.
814    (Section 4.2.2)
815    The segment + query components of RFC 3986 have been used to define
816    the request-target, instead of abs_path from RFC 1808.  The asterisk-
817    form of the request-target is only allowed with the OPTIONS method.
818    (Section 5.3)
819
820NEW:
821
822    The meaning of the "deflate" content coding has been clarified.
823    (Section 4.2.2)
824 
825    The segment + query components of RFC 3986 have been used to define
826    the request-target, instead of abs_path from RFC 1808.  The
827    asterisk-form of the request-target is only allowed with the OPTIONS
828    method.  (Section 5.3)
829
830
831Section 19.7.1, paragraph 28:
832OLD:
833
834    Registration of Transfer Codings now requires IETF Review
835    (Section 8.4)
836 
837    This specification now defines the Upgrade Token Registry, previously
838    defined in Section 7.2 of [RFC2817].  (Section 8.6)
839
840NEW:
841
842    Registration of Transfer Codings now requires IETF Review
843    (Section 8.4)
844    This specification now defines the Upgrade Token Registry, previously
845    defined in Section 7.2 of [RFC2817].  (Section 8.6)
846
847
848Appendix B., paragraph 10:
849OLD:
850
851    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
852    absolute-form = absolute-URI
853    absolute-path = 1*( "/" segment )
854    asterisk-form = "*"
855    authority = <authority, see [RFC3986], Section 3.2>
856    authority-form = authority
857 
858    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
859    chunk-data = 1*OCTET
860    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
861    chunk-ext-name = token
862    chunk-ext-val = token / quoted-string
863    chunk-size = 1*HEXDIG
864    chunked-body = *chunk last-chunk trailer-part CRLF
865    comment = "(" *( ctext / quoted-pair / comment ) ")"
866    connection-option = token
867    ctext = HTAB / SP / %x21-27 ; '!'-'''
868     / %x2A-5B ; '*'-'['
869     / %x5D-7E ; ']'-'~'
870     / obs-text
871
872NEW:
873
874    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
875    absolute-form = absolute-URI
876    absolute-path = 1*( "/" segment )
877    asterisk-form = "*"
878    authority = <authority, see [RFC3986], Section 3.2>
879    authority-form = authority
880    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
881    chunk-data = 1*OCTET
882    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
883    chunk-ext-name = token
884    chunk-ext-val = token / quoted-string
885    chunk-size = 1*HEXDIG
886    chunked-body = *chunk last-chunk trailer-part CRLF
887    comment = "(" *( ctext / quoted-pair / comment ) ")"
888    connection-option = token
889    ctext = HTAB / SP / %x21-27 ; '!'-'''
890     / %x2A-5B ; '*'-'['
891     / %x5D-7E ; ']'-'~'
892     / obs-text
893
894
895Appendix B., paragraph 19:
896OLD:
897
898    scheme = <scheme, see [RFC3986], Section 3.1>
899    segment = <segment, see [RFC3986], Section 3.3>
900    start-line = request-line / status-line
901    status-code = 3DIGIT
902    status-line = HTTP-version SP status-code SP reason-phrase CRLF
903    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
904    t-ranking = OWS ";" OWS "q=" rank
905    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
906     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
907    token = 1*tchar
908    trailer-part = *( header-field CRLF )
909    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
910     transfer-extension
911    transfer-extension = token *( OWS ";" OWS transfer-parameter )
912    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
913
914NEW:
915
916    scheme = <scheme, see [RFC3986], Section 3.1>
917    segment = <segment, see [RFC3986], Section 3.3>
918    start-line = request-line / status-line
919    status-code = 3DIGIT
920    status-line = HTTP-version SP status-code SP reason-phrase CRLF
921 
922    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
923    t-ranking = OWS ";" OWS "q=" rank
924    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
925     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
926    token = 1*tchar
927    trailer-part = *( header-field CRLF )
928    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
929     transfer-extension
930    transfer-extension = token *( OWS ";" OWS transfer-parameter )
931    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
932
933
934Appendix B., paragraph 22:
935OLD:
936
937    A
938       absolute-form (of request-target)  41
939       accelerator  10
940       application/http Media Type  62
941       asterisk-form (of request-target)  42
942       authoritative response  66
943       authority-form (of request-target)  42
944
945NEW:
946
947    A
948       absolute-form (of request-target)  42
949       accelerator  10
950       application/http Media Type  63
951       asterisk-form (of request-target)  43
952       authoritative response  67
953       authority-form (of request-target)  42-43
954
955
956Appendix B., paragraph 24:
957OLD:
958
959    C
960       cache  11
961       cacheable  11
962       captive portal  11
963       chunked (Coding Format)  28, 31, 35
964       client  7
965       close  50, 55
966       compress (Coding Format)  38
967       connection  7
968       Connection header field  50, 55
969       Content-Length header field  29
970
971NEW:
972
973    C
974       cache  11
975       cacheable  12
976       captive portal  11
977       chunked (Coding Format)  28, 32, 36
978       client  7
979       close  51, 56
980       compress (Coding Format)  38
981       connection  7
982       Connection header field  51, 56
983       Content-Length header field  30
984
985
986Appendix B., paragraph 25:
987OLD:
988
989    D
990       deflate (Coding Format)  38
991       Delimiters  26
992       downstream  9
993
994NEW:
995
996    D
997       deflate (Coding Format)  38
998       Delimiters  27
999       downstream  10
1000
1001
1002Appendix B., paragraph 26:
1003OLD:
1004
1005    E
1006       effective request URI  44
1007
1008NEW:
1009
1010    E
1011       effective request URI  45
1012
1013
1014Appendix B., paragraph 27:
1015OLD:
1016
1017    G
1018       gateway  10
1019       Grammar
1020          absolute-form  41
1021          absolute-path  16
1022          absolute-URI  16
1023          ALPHA  6
1024          asterisk-form  41-42
1025          authority  16
1026          authority-form  41-42
1027          BWS  24
1028          chunk  35
1029          chunk-data  35
1030          chunk-ext  35-36
1031          chunk-ext-name  36
1032          chunk-ext-val  36
1033          chunk-size  35
1034          chunked-body  35-36
1035          comment  27
1036          Connection  50
1037          connection-option  50
1038          Content-Length  29
1039          CR  6
1040          CRLF  6
1041          ctext  27
1042          CTL  6
1043          DIGIT  6
1044          DQUOTE  6
1045          field-content  22
1046          field-name  22, 39
1047          field-value  22
1048          field-vchar  22
1049          fragment  16
1050          header-field  22, 36
1051          HEXDIG  6
1052          Host  43
1053          HTAB  6
1054          HTTP-message  19
1055          HTTP-name  13
1056          http-URI  16
1057          HTTP-version  13
1058          https-URI  18
1059          last-chunk  35
1060          LF  6
1061          message-body  27
1062          method  21
1063          obs-fold  22
1064          obs-text  27
1065          OCTET  6
1066          origin-form  41
1067          OWS  24
1068          partial-URI  16
1069          port  16
1070          protocol-name  47
1071          protocol-version  47
1072          pseudonym  47
1073          qdtext  27
1074          query  16
1075          quoted-pair  27
1076          quoted-string  27
1077          rank  38
1078          reason-phrase  22
1079          received-by  47
1080          received-protocol  47
1081          request-line  21
1082          request-target  41
1083          RWS  24
1084          scheme  16
1085          segment  16
1086          SP  6
1087          start-line  20
1088          status-code  22
1089          status-line  22
1090          t-codings  38
1091          t-ranking  38
1092          tchar  26
1093          TE  38
1094          token  26
1095          Trailer  39
1096          trailer-part  35-36
1097          transfer-coding  35
1098          Transfer-Encoding  28
1099          transfer-extension  35
1100          transfer-parameter  35
1101          Upgrade  56
1102          uri-host  16
1103          URI-reference  16
1104          VCHAR  6
1105          Via  47
1106       gzip (Coding Format)  38
1107
1108NEW:
1109
1110    G
1111       gateway  10
1112       Grammar
1113          absolute-form  42
1114          absolute-path  16
1115          absolute-URI  16
1116          ALPHA  6
1117          asterisk-form  41, 43
1118          authority  16
1119          authority-form  42-43
1120          BWS  25
1121          chunk  36
1122          chunk-data  36
1123          chunk-ext  36
1124          chunk-ext-name  36
1125          chunk-ext-val  36
1126          chunk-size  36
1127          chunked-body  36
1128          comment  27
1129          Connection  51
1130          connection-option  51
1131          Content-Length  30
1132          CR  6
1133          CRLF  6
1134          ctext  27
1135          CTL  6
1136          DIGIT  6
1137          DQUOTE  6
1138          field-content  23
1139          field-name  23, 40
1140          field-value  23
1141          field-vchar  23
1142          fragment  16
1143          header-field  23, 37
1144          HEXDIG  6
1145          Host  44
1146          HTAB  6
1147          HTTP-message  19
1148          HTTP-name  14
1149          http-URI  17
1150          HTTP-version  14
1151          https-URI  18
1152          last-chunk  36
1153          LF  6
1154          message-body  28
1155          method  21
1156          obs-fold  23
1157          obs-text  27
1158          OCTET  6
1159          origin-form  42
1160          OWS  25
1161          partial-URI  16
1162          port  16
1163          protocol-name  47
1164          protocol-version  47
1165          pseudonym  47
1166          qdtext  27
1167          query  16
1168          quoted-pair  27
1169          quoted-string  27
1170          rank  39
1171          reason-phrase  22
1172          received-by  47
1173          received-protocol  47
1174          request-line  21
1175          request-target  41
1176          RWS  25
1177          scheme  16
1178          segment  16
1179          SP  6
1180          start-line  21
1181          status-code  22
1182          status-line  22
1183          t-codings  39
1184          t-ranking  39
1185          tchar  27
1186          TE  39
1187          token  27
1188          Trailer  40
1189          trailer-part  37
1190          transfer-coding  35
1191          Transfer-Encoding  28
1192          transfer-extension  35
1193          transfer-parameter  35
1194          Upgrade  57
1195          uri-host  16
1196          URI-reference  16
1197          VCHAR  6
1198          Via  47
1199       gzip (Coding Format)  39
1200
1201
1202Appendix B., paragraph 28:
1203OLD:
1204
1205    H
1206       header field  19
1207       header section  19
1208       headers  19
1209       Host header field  43
1210       http URI scheme  16
1211       https URI scheme  18
1212 
1213    I
1214       inbound  9
1215       interception proxy  11
1216       intermediary  9
1217
1218NEW:
1219
1220    H
1221       header field  19
1222       header section  19
1223       headers  19
1224       Host header field  44
1225       http URI scheme  17
1226       https URI scheme  17
1227    I
1228       inbound  9
1229       interception proxy  11
1230       intermediary  9
1231
1232
1233Appendix B., paragraph 29:
1234OLD:
1235
1236    M
1237       Media Type
1238          application/http  62
1239          message/http  61
1240       message  7
1241       message/http Media Type  61
1242       method  21
1243
1244NEW:
1245
1246    M
1247       Media Type
1248          application/http  63
1249          message/http  62
1250       message  7
1251       message/http Media Type  62
1252       method  21
1253
1254
1255Appendix B., paragraph 30:
1256OLD:
1257
1258    N
1259       non-transforming proxy  48
1260
1261NEW:
1262
1263    N
1264       non-transforming proxy  49
1265
1266
1267Appendix B., paragraph 31:
1268OLD:
1269
1270    O
1271       origin server  7
1272       origin-form (of request-target)  41
1273       outbound  9
1274
1275NEW:
1276
1277    O
1278       origin server  7
1279       origin-form (of request-target)  42
1280       outbound  10
1281
1282
1283Appendix B., paragraph 32:
1284OLD:
1285
1286    P
1287       phishing  66
1288       proxy  10
1289
1290NEW:
1291
1292    P
1293       phishing  67
1294       proxy  10
1295
1296
1297Appendix B., paragraph 35:
1298OLD:
1299
1300    T
1301       target resource  40
1302       target URI  40
1303       TE header field  38
1304       Trailer header field  39
1305       Transfer-Encoding header field  28
1306       transforming proxy  48
1307       transparent proxy  11
1308       tunnel  10
1309
1310NEW:
1311
1312    T
1313       target resource  40
1314       target URI  40
1315       TE header field  39
1316       Trailer header field  40
1317       Transfer-Encoding header field  28
1318       transforming proxy  49
1319       transparent proxy  11
1320       tunnel  10
1321
1322
1323Appendix B., paragraph 36:
1324OLD:
1325
1326    U
1327       Upgrade header field  56
1328       upstream  9
1329       URI scheme
1330          http  16
1331          https  18
1332       user agent  7
1333
1334NEW:
1335
1336    U
1337       Upgrade header field  57
1338       upstream  9
1339       URI scheme
1340          http  17
1341          https  17
1342       user agent  7
1343
1344
1345Appendix B., paragraph 37:
1346OLD:
1347
1348    V
1349       Via header field  46
1350
1351NEW:
1352
1353    V
1354       Via header field  47
1355
Note: See TracBrowser for help on using the repository browser.