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

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

switch diffs to plain text versions of RFCs-to-be (#553)
  • Property svn:eol-style set to native
File size: 48.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.2., paragraph 10:
469OLD:
470
471    Aside from the cases defined above, in the absence of Transfer-
472    Encoding, an origin server SHOULD send a Content-Length header field
473    when the payload body size is known prior to sending the complete
474    header section.  This will allow downstream recipients to measure
475    transfer progress, know when a received message is complete, and
476    potentially reuse the connection for additional requests.
477
478NEW:
479
480    Aside from the cases defined above, in the absence of
481    Transfer-Encoding, an origin server SHOULD send a Content-Length
482    header field when the payload body size is known prior to sending the
483    complete header section.  This will allow downstream recipients to
484    measure transfer progress, know when a received message is complete,
485    and potentially reuse the connection for additional requests.
486
487
488Section 3.3.2., paragraph 13:
489OLD:
490
491       Note: HTTP's use of Content-Length for message framing differs
492       significantly from the same field's use in MIME, where it is an
493       optional field used only within the "message/external-body" media-
494       type.
495
496NEW:
497
498       Note: HTTP's use of Content-Length for message framing differs
499       significantly from the same field's use in MIME, where it is an
500       optional field used only within the "message/external-body"
501       media-type.
502
503
504Section 7., paragraph 1:
505OLD:
506
507    Since there is no way to distinguish a successfully completed, close-
508    delimited message from a partially received message interrupted by
509    network failure, a server SHOULD generate encoding or length-
510    delimited messages whenever possible.  The close-delimiting feature
511    exists primarily for backwards compatibility with HTTP/1.0.
512
513NEW:
514
515    Since there is no way to distinguish a successfully completed,
516    close-delimited message from a partially received message interrupted
517    by network failure, a server SHOULD generate encoding or
518    length-delimited messages whenever possible.  The close-delimiting
519    feature exists primarily for backwards compatibility with HTTP/1.0.
520
521
522Section 4., paragraph 5:
523OLD:
524
525    All transfer-coding names are case-insensitive and ought to be
526    registered within the HTTP Transfer Coding registry, as defined in
527    Section 8.4.  They are used in the TE (Section 4.3) and Transfer-
528    Encoding (Section 3.3.1) header fields.
529
530NEW:
531
532    All transfer-coding names are case-insensitive and ought to be
533    registered within the HTTP Transfer Coding registry, as defined in
534    Section 8.4.  They are used in the TE (Section 4.3) and
535    Transfer-Encoding (Section 3.3.1) header fields.
536
537
538Section 4.1.1., paragraph 1:
539OLD:
540
541    The chunked encoding allows each chunk to include zero or more chunk
542    extensions, immediately following the chunk-size, for the sake of
543    supplying per-chunk metadata (such as a signature or hash), mid-
544    message control information, or randomization of message body size.
545
546NEW:
547
548    The chunked encoding allows each chunk to include zero or more chunk
549    extensions, immediately following the chunk-size, for the sake of
550    supplying per-chunk metadata (such as a signature or hash),
551    mid-message control information, or randomization of message body
552    size.
553
554
555Section 5.1., paragraph 1:
556OLD:
557
558    HTTP is used in a wide variety of applications, ranging from general-
559    purpose computers to home appliances.  In some cases, communication
560    options are hard-coded in a client's configuration.  However, most
561    HTTP clients rely on the same resource identification mechanism and
562    configuration techniques as general-purpose Web browsers.
563
564NEW:
565
566    HTTP is used in a wide variety of applications, ranging from
567    general-purpose computers to home appliances.  In some cases,
568    communication options are hard-coded in a client's configuration.
569    However, most HTTP clients rely on the same resource identification
570    mechanism and configuration techniques as general-purpose Web
571    browsers.
572
573
574Section 5.4., paragraph 8:
575OLD:
576
577    When a proxy receives a request with an absolute-form of request-
578    target, the proxy MUST ignore the received Host header field (if any)
579    and instead replace it with the host information of the request-
580    target.  A proxy that forwards such a request MUST generate a new
581    Host field-value based on the received request-target rather than
582    forward the received Host field-value.
583
584NEW:
585
586    When a proxy receives a request with an absolute-form of
587    request-target, the proxy MUST ignore the received Host header field
588    (if any) and instead replace it with the host information of the
589    request-target.  A proxy that forwards such a request MUST generate a
590    new Host field-value based on the received request-target rather than
591    forward the received Host field-value.
592
593
594Section 5.6., paragraph 2:
595OLD:
596
597    A client that has more than one outstanding request on a connection
598    MUST maintain a list of outstanding requests in the order sent and
599    MUST associate each received response message on that connection to
600    the highest ordered request that has not yet received a final (non-
601    1xx) response.
602
603NEW:
604
605    A client that has more than one outstanding request on a connection
606    MUST maintain a list of outstanding requests in the order sent and
607    MUST associate each received response message on that connection to
608    the highest ordered request that has not yet received a final
609    (non-1xx) response.
610
611
612Section 6.3.1., paragraph 2:
613OLD:
614
615    When an inbound connection is closed prematurely, a client MAY open a
616    new connection and automatically retransmit an aborted sequence of
617    requests if all of those requests have idempotent methods (Section
618    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry non-
619    idempotent requests.
620
621NEW:
622
623    When an inbound connection is closed prematurely, a client MAY open a
624    new connection and automatically retransmit an aborted sequence of
625    requests if all of those requests have idempotent methods (Section
626    4.2.2 of [RFC7231]).  A proxy MUST NOT automatically retry
627    non-idempotent requests.
628
629
630Section 6.4., paragraph 3:
631OLD:
632
633    Multiple connections are typically used to avoid the "head-of-line
634    blocking" problem, wherein a request that takes significant server-
635    side processing and/or has a large payload blocks subsequent requests
636    on the same connection.  However, each connection consumes server
637    resources.  Furthermore, using multiple connections can cause
638    undesirable side effects in congested networks.
639
640NEW:
641
642    Multiple connections are typically used to avoid the "head-of-line
643    blocking" problem, wherein a request that takes significant
644    server-side processing and/or has a large payload blocks subsequent
645    requests on the same connection.  However, each connection consumes
646    server resources.  Furthermore, using multiple connections can cause
647    undesirable side effects in congested networks.
648
649
650Section 7., paragraph 2:
651OLD:
652
653    A construct "#" is defined, similar to "*", for defining comma-
654    delimited lists of elements.  The full form is "<n>#<m>element"
655    indicating at least <n> and at most <m> elements, each separated by a
656    single comma (",") and optional whitespace (OWS).
657
658NEW:
659
660    A construct "#" is defined, similar to "*", for defining
661    comma-delimited lists of elements.  The full form is "<n>#<m>element"
662    indicating at least <n> and at most <m> elements, each separated by a
663    single comma (",") and optional whitespace (OWS).
664
665
666Section 8.3.1., paragraph 17:
667OLD:
668
669       File extension(s):  N/A
670       Macintosh file type code(s):  N/A
671
672NEW:
673
674       File extension(s):  N/A
675 
676       Macintosh file type code(s):  N/A
677
678
679Section 8.3.2., paragraph 12:
680OLD:
681
682    Applications that use this media type:  N/A
683    Fragment identifier considerations:  N/A
684
685NEW:
686
687    Applications that use this media type:  N/A
688 
689    Fragment identifier considerations:  N/A
690
691
692Section 9.1., paragraph 1:
693OLD:
694
695    HTTP relies on the notion of an authoritative response: a response
696    that has been determined by (or at the direction of) the authority
697    identified within the target URI to be the most appropriate response
698    for that request given the state of the target resource at the time
699    of response message origination.  Providing a response from a non-
700    authoritative source, such as a shared cache, is often useful to
701    improve performance and availability, but only to the extent that the
702    source can be trusted or the distrusted response can be safely used.
703
704NEW:
705
706    HTTP relies on the notion of an authoritative response: a response
707    that has been determined by (or at the direction of) the authority
708    identified within the target URI to be the most appropriate response
709    for that request given the state of the target resource at the time
710    of response message origination.  Providing a response from a
711    non-authoritative source, such as a shared cache, is often useful to
712    improve performance and availability, but only to the extent that the
713    source can be trusted or the distrusted response can be safely used.
714
715
716Section 9.6., paragraph 1:
717OLD:
718
719    HTTP does not define a specific mechanism for ensuring message
720    integrity, instead relying on the error-detection ability of
721    underlying transport protocols and the use of length or chunk-
722    delimited framing to detect completeness.  Additional integrity
723    mechanisms, such as hash functions or digital signatures applied to
724    the content, can be selectively added to messages via extensible
725    metadata header fields.  Historically, the lack of a single integrity
726    mechanism has been justified by the informal nature of most HTTP
727    communication.  However, the prevalence of HTTP as an information
728    access mechanism has resulted in its increasing use within
729    environments where verification of message integrity is crucial.
730
731NEW:
732
733    HTTP does not define a specific mechanism for ensuring message
734    integrity, instead relying on the error-detection ability of
735    underlying transport protocols and the use of length or
736    chunk-delimited framing to detect completeness.  Additional integrity
737    mechanisms, such as hash functions or digital signatures applied to
738    the content, can be selectively added to messages via extensible
739    metadata header fields.  Historically, the lack of a single integrity
740    mechanism has been justified by the informal nature of most HTTP
741    communication.  However, the prevalence of HTTP as an information
742    access mechanism has resulted in its increasing use within
743    environments where verification of message integrity is crucial.
744
745
746Section 9.8., paragraph 3:
747OLD:
748
749    To minimize the risk of theft or accidental publication, log
750    information ought to be purged of personally identifiable
751    information, including user identifiers, IP addresses, and user-
752    provided query parameters, as soon as that information is no longer
753    necessary to support operational needs for security, auditing, or
754    fraud control.
755
756NEW:
757
758    To minimize the risk of theft or accidental publication, log
759    information ought to be purged of personally identifiable
760    information, including user identifiers, IP addresses, and
761    user-provided query parameters, as soon as that information is no
762    longer necessary to support operational needs for security, auditing,
763    or fraud control.
764
765
766Section 19.7.1, paragraph 21:
767OLD:
768
769    The meaning of the "deflate" content coding has been clarified.
770    (Section 4.2.2)
771    The segment + query components of RFC 3986 have been used to define
772    the request-target, instead of abs_path from RFC 1808.  The asterisk-
773    form of the request-target is only allowed with the OPTIONS method.
774    (Section 5.3)
775
776NEW:
777
778    The meaning of the "deflate" content coding has been clarified.
779    (Section 4.2.2)
780 
781    The segment + query components of RFC 3986 have been used to define
782    the request-target, instead of abs_path from RFC 1808.  The asterisk-
783    form of the request-target is only allowed with the OPTIONS method.
784    (Section 5.3)
785
786
787Section 19.7.1, paragraph 28:
788OLD:
789
790    Registration of Transfer Codings now requires IETF Review
791    (Section 8.4)
792 
793    This specification now defines the Upgrade Token Registry, previously
794    defined in Section 7.2 of [RFC2817].  (Section 8.6)
795
796NEW:
797
798    Registration of Transfer Codings now requires IETF Review
799    (Section 8.4)
800    This specification now defines the Upgrade Token Registry, previously
801    defined in Section 7.2 of [RFC2817].  (Section 8.6)
802
803
804Appendix B., paragraph 10:
805OLD:
806
807    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
808    absolute-form = absolute-URI
809    absolute-path = 1*( "/" segment )
810    asterisk-form = "*"
811    authority = <authority, see [RFC3986], Section 3.2>
812    authority-form = authority
813 
814    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
815    chunk-data = 1*OCTET
816    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
817    chunk-ext-name = token
818    chunk-ext-val = token / quoted-string
819    chunk-size = 1*HEXDIG
820    chunked-body = *chunk last-chunk trailer-part CRLF
821    comment = "(" *( ctext / quoted-pair / comment ) ")"
822    connection-option = token
823    ctext = HTAB / SP / %x21-27 ; '!'-'''
824     / %x2A-5B ; '*'-'['
825     / %x5D-7E ; ']'-'~'
826     / obs-text
827
828NEW:
829
830    absolute-URI = <absolute-URI, see [RFC3986], Section 4.3>
831    absolute-form = absolute-URI
832    absolute-path = 1*( "/" segment )
833    asterisk-form = "*"
834    authority = <authority, see [RFC3986], Section 3.2>
835    authority-form = authority
836    chunk = chunk-size [ chunk-ext ] CRLF chunk-data CRLF
837    chunk-data = 1*OCTET
838    chunk-ext = *( ";" chunk-ext-name [ "=" chunk-ext-val ] )
839    chunk-ext-name = token
840    chunk-ext-val = token / quoted-string
841    chunk-size = 1*HEXDIG
842    chunked-body = *chunk last-chunk trailer-part CRLF
843    comment = "(" *( ctext / quoted-pair / comment ) ")"
844    connection-option = token
845    ctext = HTAB / SP / %x21-27 ; '!'-'''
846     / %x2A-5B ; '*'-'['
847     / %x5D-7E ; ']'-'~'
848     / obs-text
849
850
851Appendix B., paragraph 19:
852OLD:
853
854    scheme = <scheme, see [RFC3986], Section 3.1>
855    segment = <segment, see [RFC3986], Section 3.3>
856    start-line = request-line / status-line
857    status-code = 3DIGIT
858    status-line = HTTP-version SP status-code SP reason-phrase CRLF
859    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
860    t-ranking = OWS ";" OWS "q=" rank
861    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
862     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
863    token = 1*tchar
864    trailer-part = *( header-field CRLF )
865    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
866     transfer-extension
867    transfer-extension = token *( OWS ";" OWS transfer-parameter )
868    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
869
870NEW:
871
872    scheme = <scheme, see [RFC3986], Section 3.1>
873    segment = <segment, see [RFC3986], Section 3.3>
874    start-line = request-line / status-line
875    status-code = 3DIGIT
876    status-line = HTTP-version SP status-code SP reason-phrase CRLF
877 
878    t-codings = "trailers" / ( transfer-coding [ t-ranking ] )
879    t-ranking = OWS ";" OWS "q=" rank
880    tchar = "!" / "#" / "$" / "%" / "&" / "'" / "*" / "+" / "-" / "." /
881     "^" / "_" / "`" / "|" / "~" / DIGIT / ALPHA
882    token = 1*tchar
883    trailer-part = *( header-field CRLF )
884    transfer-coding = "chunked" / "compress" / "deflate" / "gzip" /
885     transfer-extension
886    transfer-extension = token *( OWS ";" OWS transfer-parameter )
887    transfer-parameter = token BWS "=" BWS ( token / quoted-string )
888
889
890Appendix B., paragraph 22:
891OLD:
892
893    A
894       absolute-form (of request-target)  41
895       accelerator  10
896       application/http Media Type  62
897       asterisk-form (of request-target)  42
898       authoritative response  66
899       authority-form (of request-target)  42
900
901NEW:
902
903    A
904       absolute-form (of request-target)  42
905       accelerator  10
906       application/http Media Type  63
907       asterisk-form (of request-target)  43
908       authoritative response  67
909       authority-form (of request-target)  42-43
910
911
912Appendix B., paragraph 24:
913OLD:
914
915    C
916       cache  11
917       cacheable  11
918       captive portal  11
919       chunked (Coding Format)  28, 31, 35
920       client  7
921       close  50, 55
922       compress (Coding Format)  38
923       connection  7
924       Connection header field  50, 55
925       Content-Length header field  29
926
927NEW:
928
929    C
930       cache  11
931       cacheable  12
932       captive portal  11
933       chunked (Coding Format)  28, 32, 36
934       client  7
935       close  51, 56
936       compress (Coding Format)  38
937       connection  7
938       Connection header field  51, 56
939       Content-Length header field  30
940
941
942Appendix B., paragraph 25:
943OLD:
944
945    D
946       deflate (Coding Format)  38
947       Delimiters  26
948       downstream  9
949
950NEW:
951
952    D
953       deflate (Coding Format)  38
954       Delimiters  27
955       downstream  10
956
957
958Appendix B., paragraph 26:
959OLD:
960
961    E
962       effective request URI  44
963
964NEW:
965
966    E
967       effective request URI  45
968
969
970Appendix B., paragraph 27:
971OLD:
972
973    G
974       gateway  10
975       Grammar
976          absolute-form  41
977          absolute-path  16
978          absolute-URI  16
979          ALPHA  6
980          asterisk-form  41-42
981          authority  16
982          authority-form  41-42
983          BWS  24
984          chunk  35
985          chunk-data  35
986          chunk-ext  35-36
987          chunk-ext-name  36
988          chunk-ext-val  36
989          chunk-size  35
990          chunked-body  35-36
991          comment  27
992          Connection  50
993          connection-option  50
994          Content-Length  29
995          CR  6
996          CRLF  6
997          ctext  27
998          CTL  6
999          DIGIT  6
1000          DQUOTE  6
1001          field-content  22
1002          field-name  22, 39
1003          field-value  22
1004          field-vchar  22
1005          fragment  16
1006          header-field  22, 36
1007          HEXDIG  6
1008          Host  43
1009          HTAB  6
1010          HTTP-message  19
1011          HTTP-name  13
1012          http-URI  16
1013          HTTP-version  13
1014          https-URI  18
1015          last-chunk  35
1016          LF  6
1017          message-body  27
1018          method  21
1019          obs-fold  22
1020          obs-text  27
1021          OCTET  6
1022          origin-form  41
1023          OWS  24
1024          partial-URI  16
1025          port  16
1026          protocol-name  47
1027          protocol-version  47
1028          pseudonym  47
1029          qdtext  27
1030          query  16
1031          quoted-pair  27
1032          quoted-string  27
1033          rank  38
1034          reason-phrase  22
1035          received-by  47
1036          received-protocol  47
1037          request-line  21
1038          request-target  41
1039          RWS  24
1040          scheme  16
1041          segment  16
1042          SP  6
1043          start-line  20
1044          status-code  22
1045          status-line  22
1046          t-codings  38
1047          t-ranking  38
1048          tchar  26
1049          TE  38
1050          token  26
1051          Trailer  39
1052          trailer-part  35-36
1053          transfer-coding  35
1054          Transfer-Encoding  28
1055          transfer-extension  35
1056          transfer-parameter  35
1057          Upgrade  56
1058          uri-host  16
1059          URI-reference  16
1060          VCHAR  6
1061          Via  47
1062       gzip (Coding Format)  38
1063
1064NEW:
1065
1066    G
1067       gateway  10
1068       Grammar
1069          absolute-form  42
1070          absolute-path  16
1071          absolute-URI  16
1072          ALPHA  6
1073          asterisk-form  41, 43
1074          authority  16
1075          authority-form  42-43
1076          BWS  25
1077          chunk  36
1078          chunk-data  36
1079          chunk-ext  36
1080          chunk-ext-name  36
1081          chunk-ext-val  36
1082          chunk-size  36
1083          chunked-body  36
1084          comment  27
1085          Connection  51
1086          connection-option  51
1087          Content-Length  30
1088          CR  6
1089          CRLF  6
1090          ctext  27
1091          CTL  6
1092          DIGIT  6
1093          DQUOTE  6
1094          field-content  23
1095          field-name  23, 40
1096          field-value  23
1097          field-vchar  23
1098          fragment  16
1099          header-field  23, 37
1100          HEXDIG  6
1101          Host  44
1102          HTAB  6
1103          HTTP-message  19
1104          HTTP-name  14
1105          http-URI  17
1106          HTTP-version  14
1107          https-URI  18
1108          last-chunk  36
1109          LF  6
1110          message-body  28
1111          method  21
1112          obs-fold  23
1113          obs-text  27
1114          OCTET  6
1115          origin-form  42
1116          OWS  25
1117          partial-URI  16
1118          port  16
1119          protocol-name  47
1120          protocol-version  47
1121          pseudonym  47
1122          qdtext  27
1123          query  16
1124          quoted-pair  27
1125          quoted-string  27
1126          rank  39
1127          reason-phrase  22
1128          received-by  47
1129          received-protocol  47
1130          request-line  21
1131          request-target  41
1132          RWS  25
1133          scheme  16
1134          segment  16
1135          SP  6
1136          start-line  21
1137          status-code  22
1138          status-line  22
1139          t-codings  39
1140          t-ranking  39
1141          tchar  27
1142          TE  39
1143          token  27
1144          Trailer  40
1145          trailer-part  37
1146          transfer-coding  35
1147          Transfer-Encoding  28
1148          transfer-extension  35
1149          transfer-parameter  35
1150          Upgrade  57
1151          uri-host  16
1152          URI-reference  16
1153          VCHAR  6
1154          Via  47
1155       gzip (Coding Format)  39
1156
1157
1158Appendix B., paragraph 28:
1159OLD:
1160
1161    H
1162       header field  19
1163       header section  19
1164       headers  19
1165       Host header field  43
1166       http URI scheme  16
1167       https URI scheme  18
1168 
1169    I
1170       inbound  9
1171       interception proxy  11
1172       intermediary  9
1173
1174NEW:
1175
1176    H
1177       header field  19
1178       header section  19
1179       headers  19
1180       Host header field  44
1181       http URI scheme  17
1182       https URI scheme  17
1183    I
1184       inbound  9
1185       interception proxy  11
1186       intermediary  9
1187
1188
1189Appendix B., paragraph 29:
1190OLD:
1191
1192    M
1193       Media Type
1194          application/http  62
1195          message/http  61
1196       message  7
1197       message/http Media Type  61
1198       method  21
1199
1200NEW:
1201
1202    M
1203       Media Type
1204          application/http  63
1205          message/http  62
1206       message  7
1207       message/http Media Type  62
1208       method  21
1209
1210
1211Appendix B., paragraph 30:
1212OLD:
1213
1214    N
1215       non-transforming proxy  48
1216
1217NEW:
1218
1219    N
1220       non-transforming proxy  49
1221
1222
1223Appendix B., paragraph 31:
1224OLD:
1225
1226    O
1227       origin server  7
1228       origin-form (of request-target)  41
1229       outbound  9
1230
1231NEW:
1232
1233    O
1234       origin server  7
1235       origin-form (of request-target)  42
1236       outbound  10
1237
1238
1239Appendix B., paragraph 32:
1240OLD:
1241
1242    P
1243       phishing  66
1244       proxy  10
1245
1246NEW:
1247
1248    P
1249       phishing  67
1250       proxy  10
1251
1252
1253Appendix B., paragraph 35:
1254OLD:
1255
1256    T
1257       target resource  40
1258       target URI  40
1259       TE header field  38
1260       Trailer header field  39
1261       Transfer-Encoding header field  28
1262       transforming proxy  48
1263       transparent proxy  11
1264       tunnel  10
1265
1266NEW:
1267
1268    T
1269       target resource  40
1270       target URI  40
1271       TE header field  39
1272       Trailer header field  40
1273       Transfer-Encoding header field  28
1274       transforming proxy  49
1275       transparent proxy  11
1276       tunnel  10
1277
1278
1279Appendix B., paragraph 36:
1280OLD:
1281
1282    U
1283       Upgrade header field  56
1284       upstream  9
1285       URI scheme
1286          http  16
1287          https  18
1288       user agent  7
1289
1290NEW:
1291
1292    U
1293       Upgrade header field  57
1294       upstream  9
1295       URI scheme
1296          http  17
1297          https  17
1298       user agent  7
1299
1300
1301Appendix B., paragraph 37:
1302OLD:
1303
1304    V
1305       Via header field  46
1306
1307NEW:
1308
1309    V
1310       Via header field  47
1311
Note: See TracBrowser for help on using the repository browser.