source: draft-ietf-httpbis/latest/auth48/rfc7234.abdiff.txt

Last change on this file was 2724, checked in by julian.reschke@…, 6 years ago

revert changes for auth48 boilerplate checks (#553)

File size: 32.0 KB
Line 
1
2INTRODUCTION, paragraph 1:
3OLD:
4
5 HTTPbis Working Group                                   R. Fielding, Ed.
6 Internet-Draft                                                     Adobe
7 Obsoletes: 2616 (if approved)                         M. Nottingham, Ed.
8 Intended status: Standards Track                                  Akamai
9 Expires: December 8, 2014                                J. Reschke, Ed.
10                                                               greenbytes
11                                                             June 6, 2014
12
13NEW:
14
15 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
16 Request for Comments: 7234                                         Adobe
17 Obsoletes: 2616                                       M. Nottingham, Ed.
18 Category: Standards Track                                         Akamai
19 ISSN: 2070-1721                                          J. Reschke, Ed.
20                                                               greenbytes
21                                                                June 2014
22
23
24INTRODUCTION, paragraph 2:
25OLD:
26
27             Hypertext Transfer Protocol (HTTP/1.1): Caching
28                    draft-ietf-httpbis-p6-cache-latest
29
30NEW:
31
32             Hypertext Transfer Protocol (HTTP/1.1): Caching
33
34
35INTRODUCTION, paragraph 5:
36OLD:
37
38 Editorial Note (To be removed by RFC Editor)
39 
40    Discussion of this draft takes place on the HTTPBIS working group
41    mailing list (ietf-http-wg@w3.org), which is archived at
42    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
43 
44    The current issues list is at
45    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
46    documents (including fancy diffs) can be found at
47    <http://tools.ietf.org/wg/httpbis/>.
48 
49    _This is a temporary document for the purpose of tracking the
50    editorial changes made during the AUTH48 (RFC publication) phase._
51 
52 Status of This Memo
53
54NEW:
55
56 Status of This Memo
57
58
59INTRODUCTION, paragraph 6:
60OLD:
61
62    This Internet-Draft is submitted in full conformance with the
63    provisions of BCP 78 and BCP 79.
64
65NEW:
66
67    This is an Internet Standards Track document.
68
69
70INTRODUCTION, paragraph 7:
71OLD:
72
73    Internet-Drafts are working documents of the Internet Engineering
74    Task Force (IETF).  Note that other groups may also distribute
75    working documents as Internet-Drafts.  The list of current Internet-
76    Drafts is at http://datatracker.ietf.org/drafts/current/.
77
78NEW:
79
80    This document is a product of the Internet Engineering Task Force
81    (IETF).  It represents the consensus of the IETF community.  It has
82    received public review and has been approved for publication by the
83    Internet Engineering Steering Group (IESG).  Further information on
84    Internet Standards is available in Section 2 of RFC 5741.
85
86
87INTRODUCTION, paragraph 8:
88OLD:
89
90    Internet-Drafts are draft documents valid for a maximum of six months
91    and may be updated, replaced, or obsoleted by other documents at any
92    time.  It is inappropriate to use Internet-Drafts as reference
93    material or to cite them other than as "work in progress."
94    This Internet-Draft will expire on December 8, 2014.
95
96NEW:
97
98    Information about the current status of this document, any errata,
99    and how to provide feedback on it may be obtained at
100    http://www.rfc-editor.org/info/rfc7234.
101
102
103INTRODUCTION, paragraph 14:
104OLD:
105
106    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
107      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
108      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
109        1.2.1.  Delta Seconds  . . . . . . . . . . . . . . . . . . . .  5
110    2.  Overview of Cache Operation  . . . . . . . . . . . . . . . . .  5
111    3.  Storing Responses in Caches  . . . . . . . . . . . . . . . . .  6
112      3.1.  Storing Incomplete Responses . . . . . . . . . . . . . . .  7
113      3.2.  Storing Responses to Authenticated Requests  . . . . . . .  7
114      3.3.  Combining Partial Content  . . . . . . . . . . . . . . . .  8
115    4.  Constructing Responses from Caches . . . . . . . . . . . . . .  8
116      4.1.  Calculating Secondary Keys with Vary . . . . . . . . . . .  9
117      4.2.  Freshness  . . . . . . . . . . . . . . . . . . . . . . . . 10
118        4.2.1.  Calculating Freshness Lifetime . . . . . . . . . . . . 12
119        4.2.2.  Calculating Heuristic Freshness  . . . . . . . . . . . 12
120        4.2.3.  Calculating Age  . . . . . . . . . . . . . . . . . . . 13
121        4.2.4.  Serving Stale Responses  . . . . . . . . . . . . . . . 15
122      4.3.  Validation . . . . . . . . . . . . . . . . . . . . . . . . 15
123        4.3.1.  Sending a Validation Request . . . . . . . . . . . . . 15
124        4.3.2.  Handling a Received Validation Request . . . . . . . . 16
125        4.3.3.  Handling a Validation Response . . . . . . . . . . . . 17
126        4.3.4.  Freshening Stored Responses upon Validation  . . . . . 18
127        4.3.5.  Freshening Responses via HEAD  . . . . . . . . . . . . 19
128      4.4.  Invalidation . . . . . . . . . . . . . . . . . . . . . . . 19
129    5.  Header Field Definitions . . . . . . . . . . . . . . . . . . . 20
130      5.1.  Age  . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
131      5.2.  Cache-Control  . . . . . . . . . . . . . . . . . . . . . . 21
132        5.2.1.  Request Cache-Control Directives . . . . . . . . . . . 21
133        5.2.2.  Response Cache-Control Directives  . . . . . . . . . . 23
134        5.2.3.  Cache Control Extensions . . . . . . . . . . . . . . . 26
135      5.3.  Expires  . . . . . . . . . . . . . . . . . . . . . . . . . 27
136      5.4.  Pragma . . . . . . . . . . . . . . . . . . . . . . . . . . 28
137      5.5.  Warning  . . . . . . . . . . . . . . . . . . . . . . . . . 29
138        5.5.1.  Warning: 110 - "Response is Stale" . . . . . . . . . . 30
139        5.5.2.  Warning: 111 - "Revalidation Failed" . . . . . . . . . 31
140        5.5.3.  Warning: 112 - "Disconnected Operation"  . . . . . . . 31
141        5.5.4.  Warning: 113 - "Heuristic Expiration"  . . . . . . . . 31
142        5.5.5.  Warning: 199 - "Miscellaneous Warning" . . . . . . . . 31
143        5.5.6.  Warning: 214 - "Transformation Applied"  . . . . . . . 31
144        5.5.7.  Warning: 299 - "Miscellaneous Persistent Warning"  . . 31
145    6.  History Lists  . . . . . . . . . . . . . . . . . . . . . . . . 31
146    7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
147      7.1.  Cache Directive Registry . . . . . . . . . . . . . . . . . 32
148        7.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 32
149        7.1.2.  Considerations for New Cache Control Directives  . . . 32
150        7.1.3.  Registrations  . . . . . . . . . . . . . . . . . . . . 32
151      7.2.  Warn Code Registry . . . . . . . . . . . . . . . . . . . . 33
152        7.2.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 33
153        7.2.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 33
154      7.3.  Header Field Registration  . . . . . . . . . . . . . . . . 34
155    8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 34
156    9.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 35
157    10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
158      10.1. Normative References . . . . . . . . . . . . . . . . . . . 35
159      10.2. Informative References . . . . . . . . . . . . . . . . . . 36
160    Appendix A.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 36
161    Appendix B.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 38
162    Appendix C.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 38
163    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
164
165NEW:
166
167    1. Introduction ....................................................4
168       1.1. Conformance and Error Handling .............................4
169       1.2. Syntax Notation ............................................4
170            1.2.1. Delta Seconds .......................................5
171    2. Overview of Cache Operation .....................................5
172    3. Storing Responses in Caches .....................................6
173       3.1. Storing Incomplete Responses ...............................7
174       3.2. Storing Responses to Authenticated Requests ................7
175       3.3. Combining Partial Content ..................................8
176    4. Constructing Responses from Caches ..............................8
177       4.1. Calculating Secondary Keys with Vary .......................9
178       4.2. Freshness .................................................11
179            4.2.1. Calculating Freshness Lifetime .....................12
180            4.2.2. Calculating Heuristic Freshness ....................13
181            4.2.3. Calculating Age ....................................13
182            4.2.4. Serving Stale Responses ............................15
183       4.3. Validation ................................................16
184            4.3.1. Sending a Validation Request .......................16
185            4.3.2. Handling a Received Validation Request .............16
186            4.3.3. Handling a Validation Response .....................18
187            4.3.4. Freshening Stored Responses upon Validation ........18
188            4.3.5. Freshening Responses via HEAD ......................19
189       4.4. Invalidation ..............................................20
190    5. Header Field Definitions .......................................21
191       5.1. Age .......................................................21
192       5.2. Cache-Control .............................................21
193            5.2.1. Request Cache-Control Directives ...................22
194            5.2.2. Response Cache-Control Directives ..................24
195            5.2.3. Cache Control Extensions ...........................27
196       5.3. Expires ...................................................28
197       5.4. Pragma ....................................................29
198       5.5. Warning ...................................................29
199            5.5.1. Warning: 110 - "Response is Stale" .................31
200            5.5.2. Warning: 111 - "Revalidation Failed" ...............31
201            5.5.3. Warning: 112 - "Disconnected Operation" ............31
202            5.5.4. Warning: 113 - "Heuristic Expiration" ..............31
203            5.5.5. Warning: 199 - "Miscellaneous Warning" .............32
204            5.5.6. Warning: 214 - "Transformation Applied" ............32
205            5.5.7. Warning: 299 - "Miscellaneous Persistent Warning" ..32
206    6. History Lists ..................................................32
207    7. IANA Considerations ............................................32
208       7.1. Cache Directive Registry ..................................32
209            7.1.1. Procedure ..........................................32
210            7.1.2. Considerations for New Cache Control Directives ....33
211            7.1.3. Registrations ......................................33
212       7.2. Warn Code Registry ........................................34
213            7.2.1. Procedure ..........................................34
214            7.2.2. Registrations ......................................34
215       7.3. Header Field Registration .................................34
216    8. Security Considerations ........................................35
217    9. Acknowledgments ................................................36
218    10. References ....................................................36
219       10.1. Normative References .....................................36
220       10.2. Informative References ...................................37
221    Appendix A. Changes from RFC 2616 .................................38
222    Appendix B. Imported ABNF .........................................39
223    Appendix C. Collected ABNF ........................................39
224    Index .............................................................41
225
226
227Section 1.2.1., paragraph 3:
228OLD:
229
230    A recipient parsing a delta-seconds value and converting it to binary
231    form ought to use an arithmetic type of at least 31 bits of non-
232    negative integer range.  If a cache receives a delta-seconds value
233    greater than the greatest integer it can represent, or if any of its
234    subsequent calculations overflows, the cache MUST consider the value
235    to be either 2147483648 (2^31) or the greatest positive integer it
236    can conveniently represent.
237
238NEW:
239
240    A recipient parsing a delta-seconds value and converting it to binary
241    form ought to use an arithmetic type of at least 31 bits of
242    non-negative integer range.  If a cache receives a delta-seconds
243    value greater than the greatest integer it can represent, or if any
244    of its subsequent calculations overflows, the cache MUST consider the
245    value to be either 2147483648 (2^31) or the greatest positive integer
246    it can conveniently represent.
247
248
249Section 3.3., paragraph 3:
250OLD:
251
252    o  delete any Warning header fields in the stored response with warn-
253       code 1xx (see Section 5.5);
254
255NEW:
256
257    o  delete any Warning header fields in the stored response with
258       warn-code 1xx (see Section 5.5);
259
260
261Section 3.3., paragraph 4:
262OLD:
263
264    o  retain any Warning header fields in the stored response with warn-
265       code 2xx; and,
266
267NEW:
268
269    o  retain any Warning header fields in the stored response with
270       warn-code 2xx; and,
271
272
273Section 4.2., paragraph 13:
274OLD:
275
276    o  Although all date formats are specified to be case-sensitive, a
277       cache recipient SHOULD match day, week, and time-zone names case-
278       insensitively.
279
280NEW:
281
282    o  Although all date formats are specified to be case-sensitive, a
283       cache recipient SHOULD match day, week, and time-zone names
284       case-insensitively.
285
286
287Section 4.2.4., paragraph 3:
288OLD:
289
290    A cache MUST NOT send stale responses unless it is disconnected
291    (i.e., it cannot contact the origin server or otherwise find a
292    forward path) or doing so is explicitly allowed (e.g., by the max-
293    stale request directive; see Section 5.2.1).
294
295NEW:
296
297    A cache MUST NOT send stale responses unless it is disconnected
298    (i.e., it cannot contact the origin server or otherwise find a
299    forward path) or doing so is explicitly allowed (e.g., by the
300    max-stale request directive; see Section 5.2.1).
301
302
303Section 4.3.1., paragraph 2:
304OLD:
305
306    One such validator is the timestamp given in a Last-Modified header
307    field (Section 2.2 of [RFC7232]), which can be used in an If-
308    Modified-Since header field for response validation, or in an If-
309    Unmodified-Since or If-Range header field for representation
310    selection (i.e., the client is referring specifically to a previously
311    obtained representation with that timestamp).
312
313NEW:
314
315    One such validator is the timestamp given in a Last-Modified header
316    field (Section 2.2 of [RFC7232]), which can be used in an
317    If-Modified-Since header field for response validation, or in an
318    If-Unmodified-Since or If-Range header field for representation
319    selection (i.e., the client is referring specifically to a previously
320    obtained representation with that timestamp).
321
322
323Section 4.3.2., paragraph 3:
324OLD:
325
326    The proper evaluation of conditional requests by a cache depends on
327    the received precondition header fields and their precedence, as
328    defined in Section 6 of [RFC7232].  The If-Match and If-Unmodified-
329    Since conditional header fields are not applicable to a cache.
330
331NEW:
332
333    The proper evaluation of conditional requests by a cache depends on
334    the received precondition header fields and their precedence, as
335    defined in Section 6 of [RFC7232].  The If-Match and
336    If-Unmodified-Since conditional header fields are not applicable to a
337    cache.
338
339
340Section 4.3.2., paragraph 6:
341OLD:
342
343    If an If-None-Match header field is not present, a request containing
344    an If-Modified-Since header field (Section 3.3 of [RFC7232])
345    indicates that the client wants to validate one or more of its own
346    stored responses by modification date.  A cache recipient SHOULD
347    generate a 304 (Not Modified) response (using the metadata of the
348    selected stored response) if one of the following cases is true: 1)
349    the selected stored response has a Last-Modified field-value that is
350    earlier than or equal to the conditional timestamp; 2) no Last-
351    Modified field is present in the selected stored response, but it has
352    a Date field-value that is earlier than or equal to the conditional
353    timestamp; or, 3) neither Last-Modified nor Date is present in the
354    selected stored response, but the cache recorded it as having been
355    received at a time earlier than or equal to the conditional
356    timestamp.
357
358NEW:
359
360    If an If-None-Match header field is not present, a request containing
361    an If-Modified-Since header field (Section 3.3 of [RFC7232])
362    indicates that the client wants to validate one or more of its own
363    stored responses by modification date.  A cache recipient SHOULD
364    generate a 304 (Not Modified) response (using the metadata of the
365    selected stored response) if one of the following cases is true: 1)
366    the selected stored response has a Last-Modified field-value that is
367    earlier than or equal to the conditional timestamp; 2) no
368    Last-Modified field is present in the selected stored response, but
369    it has a Date field-value that is earlier than or equal to the
370    conditional timestamp; or, 3) neither Last-Modified nor Date is
371    present in the selected stored response, but the cache recorded it as
372    having been received at a time earlier than or equal to the
373    conditional timestamp.
374
375
376Section 4.3.4., paragraph 7:
377OLD:
378
379    o  delete any Warning header fields in the stored response with warn-
380       code 1xx (see Section 5.5);
381
382NEW:
383
384    o  delete any Warning header fields in the stored response with
385       warn-code 1xx (see Section 5.5);
386
387
388Section 4.3.4., paragraph 8:
389OLD:
390
391    o  retain any Warning header fields in the stored response with warn-
392       code 2xx; and,
393
394NEW:
395
396    o  retain any Warning header fields in the stored response with
397       warn-code 2xx; and,
398
399
400Section 4.3.5., paragraph 3:
401OLD:
402
403    For each of the stored responses that could have been selected, if
404    the stored response and HEAD response have matching values for any
405    received validator fields (ETag and Last-Modified) and, if the HEAD
406    response has a Content-Length header field, the value of Content-
407    Length matches that of the stored response, the cache SHOULD update
408    the stored response as described below; otherwise, the cache SHOULD
409    consider the stored response to be stale.
410
411NEW:
412
413    For each of the stored responses that could have been selected, if
414    the stored response and HEAD response have matching values for any
415    received validator fields (ETag and Last-Modified) and, if the HEAD
416    response has a Content-Length header field, the value of
417    Content-Length matches that of the stored response, the cache SHOULD
418    update the stored response as described below; otherwise, the cache
419    SHOULD consider the stored response to be stale.
420
421
422Section 4.3.5., paragraph 5:
423OLD:
424
425    o  delete any Warning header fields in the stored response with warn-
426       code 1xx (see Section 5.5);
427
428NEW:
429
430    o  delete any Warning header fields in the stored response with
431       warn-code 1xx (see Section 5.5);
432
433
434Section 4.3.5., paragraph 6:
435OLD:
436
437    o  retain any Warning header fields in the stored response with warn-
438       code 2xx; and,
439
440NEW:
441
442    o  retain any Warning header fields in the stored response with
443       warn-code 2xx; and,
444
445
446Section 5.2., paragraph 5:
447OLD:
448
449    Cache directives are identified by a token, to be compared case-
450    insensitively, and have an optional argument, that can use both token
451    and quoted-string syntax.  For the directives defined below that
452    define arguments, recipients ought to accept both forms, even if one
453    is documented to be preferred.  For any directive not defined by this
454    specification, a recipient MUST accept both forms.
455
456NEW:
457
458    Cache directives are identified by a token, to be compared
459    case-insensitively, and have an optional argument, that can use both
460    token and quoted-string syntax.  For the directives defined below
461    that define arguments, recipients ought to accept both forms, even if
462    one is documented to be preferred.  For any directive not defined by
463    this specification, a recipient MUST accept both forms.
464
465
466Section 5.2.1.5., paragraph 1:
467OLD:
468
469    The "no-store" request directive indicates that a cache MUST NOT
470    store any part of either this request or any response to it.  This
471    directive applies to both private and shared caches.  "MUST NOT
472    store" in this context means that the cache MUST NOT intentionally
473    store the information in non-volatile storage, and MUST make a best-
474    effort attempt to remove the information from volatile storage as
475    promptly as possible after forwarding it.
476
477NEW:
478
479    The "no-store" request directive indicates that a cache MUST NOT
480    store any part of either this request or any response to it.  This
481    directive applies to both private and shared caches.  "MUST NOT
482    store" in this context means that the cache MUST NOT intentionally
483    store the information in non-volatile storage, and MUST make a
484    best-effort attempt to remove the information from volatile storage
485    as promptly as possible after forwarding it.
486
487
488Section 5.2.2.2., paragraph 7:
489OLD:
490
491    Note: Although it has been back-ported to many implementations, some
492    HTTP/1.0 caches will not recognize or obey this directive.  Also, no-
493    cache response directives with field-names are often handled by
494    caches as if an unqualified no-cache directive was received; i.e.,
495    the special handling for the qualified form is not widely
496    implemented.
497
498NEW:
499
500    Note: Although it has been back-ported to many implementations, some
501    HTTP/1.0 caches will not recognize or obey this directive.  Also,
502    no-cache response directives with field-names are often handled by
503    caches as if an unqualified no-cache directive was received; i.e.,
504    the special handling for the qualified form is not widely
505    implemented.
506
507
508Section 5.2.2.3., paragraph 1:
509OLD:
510
511    The "no-store" response directive indicates that a cache MUST NOT
512    store any part of either the immediate request or response.  This
513    directive applies to both private and shared caches.  "MUST NOT
514    store" in this context means that the cache MUST NOT intentionally
515    store the information in non-volatile storage, and MUST make a best-
516    effort attempt to remove the information from volatile storage as
517    promptly as possible after forwarding it.
518
519NEW:
520
521    The "no-store" response directive indicates that a cache MUST NOT
522    store any part of either the immediate request or response.  This
523    directive applies to both private and shared caches.  "MUST NOT
524    store" in this context means that the cache MUST NOT intentionally
525    store the information in non-volatile storage, and MUST make a
526    best-effort attempt to remove the information from volatile storage
527    as promptly as possible after forwarding it.
528
529
530Section 5.5., paragraph 15:
531OLD:
532
533    If a recipient that uses, evaluates, or displays Warning header
534    fields receives a warn-date that is different from the Date value in
535    the same message, the recipient MUST exclude the warning-value
536    containing that warn-date before storing, forwarding, or using the
537    message.  This allows recipients to exclude warning-values that were
538    improperly retained after a cache validation.  If all of the warning-
539    values are excluded, the recipient MUST exclude the Warning header
540    field as well.
541
542NEW:
543
544    If a recipient that uses, evaluates, or displays Warning header
545    fields receives a warn-date that is different from the Date value in
546    the same message, the recipient MUST exclude the warning-value
547    containing that warn-date before storing, forwarding, or using the
548    message.  This allows recipients to exclude warning-values that were
549    improperly retained after a cache validation.  If all of the
550    warning-values are excluded, the recipient MUST exclude the Warning
551    header field as well.
552
553
554Section 5.5.6., paragraph 1:
555OLD:
556
557    This Warning code MUST be added by a proxy if it applies any
558    transformation to the representation, such as changing the content-
559    coding, media-type, or modifying the representation data, unless this
560    Warning code already appears in the response.
561
562NEW:
563
564    This Warning code MUST be added by a proxy if it applies any
565    transformation to the representation, such as changing the
566    content-coding, media-type, or modifying the representation data,
567    unless this Warning code already appears in the response.
568
569
570Section 7.1.1., paragraph 2:
571OLD:
572
573    o  Cache Directive Name
574 
575    o  Pointer to specification text
576
577NEW:
578
579    o  Cache Directive Name
580    o  Pointer to specification text
581
582
583Section 10.1., paragraph 4:
584OLD:
585
586    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
587               Protocol (HTTP/1.1): Semantics and Content",
588               draft-ietf-httpbis-p2-semantics-latest (work in progress),
589               June 2014.
590
591NEW:
592
593    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
594               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
595               June 2014.
596
597
598Section 10.1., paragraph 5:
599OLD:
600
601    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
602               Protocol (HTTP/1.1): Conditional Requests",
603               draft-ietf-httpbis-p4-conditional-latest (work in
604               progress), June 2014.
605
606NEW:
607
608    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
609               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
610               June 2014.
611
612
613Section 10.1., paragraph 6:
614OLD:
615
616    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
617               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
618               draft-ietf-httpbis-p5-range-latest (work in progress),
619               June 2014.
620
621NEW:
622
623    [RFC7233]  Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,
624               "Hypertext Transfer Protocol (HTTP/1.1): Range Requests",
625               RFC 7233, June 2014.
626
627
628Section 10.1., paragraph 7:
629OLD:
630
631    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
632               Protocol (HTTP/1.1): Authentication",
633               draft-ietf-httpbis-p7-auth-latest (work in progress),
634               June 2014.
635
636NEW:
637
638    [RFC7235]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
639               Protocol (HTTP/1.1): Authentication", RFC 7235, June 2014.
640
641
642Appendix A., paragraph 2:
643OLD:
644
645    The conditions under which an authenticated response can be cached
646    have been clarified.  (Section 3.2)
647    New status codes can now define that caches are allowed to use
648    heuristic freshness with them.  Caches are now allowed to calculate
649    heuristic freshness for URIs with query components.  (Section 4.2.2)
650
651NEW:
652
653    The conditions under which an authenticated response can be cached
654    have been clarified.  (Section 3.2)
655 
656    New status codes can now define that caches are allowed to use
657    heuristic freshness with them.  Caches are now allowed to calculate
658    heuristic freshness for URIs with query components.  (Section 4.2.2)
659
660
661Appendix A., paragraph 11:
662OLD:
663
664    The "no-cache" response directive's meaning has been clarified.
665    (Section 5.2.2.2)
666 
667    The one-year limit on Expires header field values has been removed;
668    instead, the reasoning for using a sensible value is given.
669    (Section 5.3)
670
671NEW:
672
673    The "no-cache" response directive's meaning has been clarified.
674    (Section 5.2.2.2)
675    The one-year limit on Expires header field values has been removed;
676    instead, the reasoning for using a sensible value is given.
677    (Section 5.3)
678
679
680Appendix A., paragraph 12:
681OLD:
682
683    The Pragma header field is now only defined for backwards
684    compatibility; future pragmas are deprecated.  (Section 5.4)
685    Some requirements regarding production and processing of the Warning
686    header fields have been relaxed, as it is not widely implemented.
687    Furthermore, the Warning header field no longer uses RFC 2047
688    encoding, nor does it allow multiple languages, as these aspects were
689    not implemented.  (Section 5.5)
690
691NEW:
692
693    The Pragma header field is now only defined for backwards
694    compatibility; future pragmas are deprecated.  (Section 5.4)
695 
696    Some requirements regarding production and processing of the Warning
697    header fields have been relaxed, as it is not widely implemented.
698    Furthermore, the Warning header field no longer uses RFC 2047
699    encoding, nor does it allow multiple languages, as these aspects were
700    not implemented.  (Section 5.5)
701
702
703Section 1.2, paragraph 18:
704OLD:
705
706    1
707       110 (warn-code)  30
708       111 (warn-code)  31
709       112 (warn-code)  31
710       113 (warn-code)  31
711       199 (warn-code)  31
712
713NEW:
714
715    1
716       110 (warn-code)  31
717       111 (warn-code)  31
718       112 (warn-code)  31
719       113 (warn-code)  31
720       199 (warn-code)  32
721
722
723Section 1.2, paragraph 19:
724OLD:
725
726    2
727       214 (warn-code)  31
728       299 (warn-code)  31
729
730NEW:
731
732    2
733       214 (warn-code)  32
734       299 (warn-code)  32
735
736
737Section 1.2, paragraph 20:
738OLD:
739
740    A
741       age  10
742       Age header field  20
743
744NEW:
745
746    A
747       age  11
748       Age header field  21
749
750
751Section 1.2, paragraph 23:
752OLD:
753
754    E
755       Expires header field  27
756       explicit expiration time  10
757
758NEW:
759
760    E
761       Expires header field  28
762       explicit expiration time  11
763
764
765Section 1.2, paragraph 24:
766OLD:
767
768    F
769       fresh  10
770       freshness lifetime  10
771
772NEW:
773
774    F
775       fresh  11
776       freshness lifetime  11
777
778
779Section 1.2, paragraph 25:
780OLD:
781
782    G
783       Grammar
784          Age  20
785          Cache-Control  21
786          cache-directive  21
787          delta-seconds  5
788          Expires  27
789          extension-pragma  28
790          Pragma  28
791          pragma-directive  28
792          warn-agent  29
793          warn-code  29
794          warn-date  29
795          warn-text  29
796          Warning  29
797          warning-value  29
798
799NEW:
800
801    G
802       Grammar
803          Age  21
804          Cache-Control  22
805          cache-directive  22
806          delta-seconds  5
807          Expires  28
808          extension-pragma  29
809          Pragma  29
810          pragma-directive  29
811          warn-agent  29
812          warn-code  29
813          warn-date  29
814          warn-text  29
815          Warning  29
816          warning-value  29
817
818
819Section 1.2, paragraph 26:
820OLD:
821
822    H
823       Heuristic Expiration (warn-text)  31
824       heuristic expiration time  10
825 
826    M
827       max-age (cache directive)  21, 26
828       max-stale (cache directive)  22
829       min-fresh (cache directive)  22
830       Miscellaneous Persistent Warning (warn-text)  31
831       Miscellaneous Warning (warn-text)  31
832       must-revalidate (cache directive)  23
833
834NEW:
835
836    H
837       Heuristic Expiration (warn-text)  31
838       heuristic expiration time  11
839    M
840       max-age (cache directive)  22, 26
841       max-stale (cache directive)  22
842       min-fresh (cache directive)  22
843       Miscellaneous Persistent Warning (warn-text)  32
844       Miscellaneous Warning (warn-text)  32
845       must-revalidate (cache directive)  24
846
847
848Section 1.2, paragraph 27:
849OLD:
850
851    N
852       no-cache (cache directive)  22, 24
853       no-store (cache directive)  22, 24
854       no-transform (cache directive)  23, 25
855
856NEW:
857
858    N
859       no-cache (cache directive)  23, 25
860       no-store (cache directive)  23, 24
861       no-transform (cache directive)  23, 25
862
863
864Section 1.2, paragraph 29:
865OLD:
866
867    P
868       Pragma header field  28
869       private (cache directive)  25
870       private cache  4
871       proxy-revalidate (cache directive)  26
872       public (cache directive)  25
873
874NEW:
875
876    P
877       Pragma header field  29
878       private (cache directive)  25
879       private cache  4
880       proxy-revalidate (cache directive)  26
881       public (cache directive)  25
882
883
884Section 1.2, paragraph 31:
885OLD:
886
887    S
888       s-maxage (cache directive)  26
889       shared cache  4
890       stale  10
891       strong validator  18
892
893NEW:
894
895    S
896       s-maxage (cache directive)  27
897       shared cache  4
898       stale  11
899       strong validator  18
900
901
902Section 1.2, paragraph 32:
903OLD:
904
905    T
906       Transformation Applied (warn-text)  31
907
908NEW:
909
910    T
911       Transformation Applied (warn-text)  32
912
913
914Section 1.2, paragraph 33:
915OLD:
916
917    V
918       validator  15
919
920NEW:
921
922    V
923       validator  16
924
Note: See TracBrowser for help on using the repository browser.