diff --git a/draft-ietf-httpbis-cache-latest.html b/draft-ietf-httpbis-cache-latest.html index ee5df5e2d..53fca0ebc 100644 --- a/draft-ietf-httpbis-cache-latest.html +++ b/draft-ietf-httpbis-cache-latest.html @@ -641,7 +641,7 @@ content: "Fielding, et al."; } @bottom-center { - content: "Expires May 16, 2021"; + content: "Expires May 23, 2021"; } @bottom-right { content: "[Page " counter(page) "]"; @@ -668,7 +668,7 @@ - + @@ -683,7 +683,7 @@ - + @@ -709,7 +709,7 @@ Fastly - Expires: May 16, 2021 + Expires: May 23, 2021 J. Reschke, Editor @@ -718,7 +718,7 @@ - November 12, 2020 + November 19, 2020 @@ -772,7 +772,7 @@

Status of This Memo

Internet-Drafts as reference material or to cite them other than as “work in progress”.

-

This Internet-Draft will expire on May 16, 2021.

+

This Internet-Draft will expire on May 23, 2021.

@@ -873,7 +873,7 @@

Table of Contents

  • 5.5.   Warning
    • -
  • 6.   Relationship to Applications
    • +
  • 6.   Relationship to Applications and Other Caches
  • 7.   Security Considerations
    • @@ -2335,7 +2361,7 @@

    5.5.  -

    6. Relationship to Applications

    +

    6. Relationship to Applications and Other Caches

    Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons that can be used to @@ -2347,14 +2373,17 @@

    6. 

    The requirements in this specification do not necessarily apply to how applications - use data after it is retrieved from a HTTP cache. That is, a history mechanism can - display a previous representation even if it has expired, and an application can use - cached data in other ways beyond its freshness lifetime.

    + use data after it is retrieved from a HTTP cache. For example, a history mechanism + can display a previous representation even if it has expired, and an application can + use cached data in other ways beyond its freshness lifetime.

    -

    This does not prohibit the application from taking HTTP caching into account; for - example, a history mechanism might tell the user that a view is stale, or it might - honor cache directives (e.g., Cache-Control: no-store).

    +

    This specification does not prohibit the application from taking HTTP caching into + account; for example, a history mechanism might tell the user that a view is stale, + or it might honor cache directives (e.g., Cache-Control: no-store). In particular, + when an application caches data and does not make this apparent to or easily controllable + by the user, it is strongly encouraged to honour basic control mechanisms like Cache-Control: + no-store, as they indicate the resource's intent regarding caching.

    @@ -2566,31 +2595,39 @@

    Appendix A. 

    Appendix B. Changes from RFC 7234

    -

    Handling invalid and multiple Age header field values has been clarified. (Section 5.1)

    +

    Handling of duplicate and conflicting cache directives has been clarified. (Section 4.2.1)

    -

    Handling of duplicate and conflicting cache directives has been clarified. (Section 4.2.1)

    +

    Cache invalidation of the URIs in the Location and Content-Location header fields + is no longer required, but still allowed. (Section 4.4)

    +

    Cache invalidation of the URIs in the Location and Content-Location header fields + is disallowed when the origin is different; previously, it was the host. (Section 4.4)

    +
    +
    +

    Handling invalid and multiple Age header field values has been clarified. (Section 5.1)

    +
    +

    Some cache directives defined by this specification now have stronger prohibitions against generating the quoted form of their values, since this has been found to create interoperability problems. Consumers of extension cache directives are no longer required to accept both token and quoted-string forms, but they still need to parse them properly - for unknown extensions. (Section 5.2)

    + for unknown extensions. (Section 5.2)

    -
    +

    The "public" and "private" cache directives were clarified, so that they do not make - responses reusable under any condition. (Section 5.2.2)

    + responses reusable under any condition. (Section 5.2.2)

    -
    +

    The "must-understand" cache directive was introduced; caches are no longer required - to understand the semantics of new response status codes unless it is present. (Section 5.2.2.2)

    + to understand the semantics of new response status codes unless it is present. (Section 5.2.2.2)

    -
    +

    The Warning response header was obsoleted. Much of the information supported by Warning could be gleaned by examining the response, and the remaining warn-codes — although potentially useful — were entirely advisory. In practice, Warning was not added by - caches or intermediaries. (Section 5.5)

    + caches or intermediaries. (Section 5.5)

    @@ -2647,7 +2684,7 @@

    C.4. Section 3, explain that only final responses are cacheable (<https://github.com/httpwg/http-core/issues/29>)
  • In Section 5.2.2, clarify what responses various directives apply to (<https://github.com/httpwg/http-core/issues/52>)
  • In Section 4.3.1, clarify the source of validators in conditional requests (<https://github.com/httpwg/http-core/issues/110>)
    • -
  • Revise Section 6 to apply to more than just History Lists (<https://github.com/httpwg/http-core/issues/126>)
    • +
  • Revise Section 6 to apply to more than just History Lists (<https://github.com/httpwg/http-core/issues/126>)
  • In Section 5.5, deprecated "Warning" header field (<https://github.com/httpwg/http-core/issues/139>)
  • In Section 3.3, remove a spurious note (<https://github.com/httpwg/http-core/issues/141>)
    • @@ -2752,13 +2789,17 @@

    C.14. Section 4.2.4, remove 'no-store', as it won't be in cache in the first place (<https://github.com/httpwg/http-core/issues/447>)
  • In Section 3.1, make it clear that only response headers need be stored (<https://github.com/httpwg/http-core/issues/457>)
    • -
  • In Section 4.3.3, mention retry of failed validation requests (<https://github.com/httpwg/http-core/issues/462>)
  • In Section 4.2.1 clarify how to handle invalid and conflicting directives (<https://github.com/httpwg/http-core/issues/460>)
    • +
  • In Section 4.3.3, mention retry of failed validation requests (<https://github.com/httpwg/http-core/issues/462>)
  • In Section 4.3.3, clarify requirement on storing a full response to a conditional request (<https://github.com/httpwg/http-core/issues/463>)
  • In Section 5.1, clarify error handling (<https://github.com/httpwg/http-core/issues/471>)
  • In Section 4.2, remove spurious "UTC" (<https://github.com/httpwg/http-core/issues/472>)
  • In Section 4.2, correct the date-related rule names to consider case-insensitive (<https://github.com/httpwg/http-core/issues/473>)
    • +
  • In Section 6, strengthen recommendation for application caches to pay attention to cache directives + (<https://github.com/httpwg/http-core/issues/474>)
  • In Section 4, mention collapsed requests (<https://github.com/httpwg/http-core/issues/475>)
    • +
  • In Section 4.4, relax requirements on Content-Location and Location invalidation (<https://github.com/httpwg/http-core/issues/478>)
    • +
  • In Section 4.3.4, refine the exceptions to update on a 304 (<https://github.com/httpwg/http-core/issues/488>)

    • @@ -2874,9 +2915,8 @@

    Index

  • R
    • @@ -1149,22 +1178,20 @@ A cache &MUST; invalidate the target URI - () and the URI(s) in the - Location and Content-Location response header - fields (if present) when a non-error status code is received in response to - an unsafe request method. + () when a non-error status code is received in response to + an unsafe request method (including methods whose safety is unknown). - However, a cache &MUST-NOT; invalidate a URI from a Location - or Content-Location response header field if the host part of - that URI differs from the host part in the target URI + A cache &MAY; invalidate other URIs when a non-error status code is received + in response to an unsafe request method (including methods whose safety is unknown). + In particular, the URI(s) in the + Location and Content-Location response header + fields (if present) are candidates for invalidation; other URIs might be discovered + through mechanisms not specified in this document. + However, a cache &MUST-NOT; trigger an invalidation under these conditions + if the origin () of the URI to be invalidated differs from that of the target URI (). This helps prevent denial-of-service attacks. - - A cache &MUST; invalidate the target URI - () when it receives a non-error response - to a request with a method whose safety is unknown. - Invalidate means that the cache will either remove all stored responses whose target URI matches the given URI, or will mark them @@ -1922,7 +1949,7 @@
    -
    +
    Applications using HTTP often specify additional forms of caching. For example, Web browsers often have history mechanisms such as "Back" buttons @@ -1935,16 +1962,19 @@ The requirements in this specification do not necessarily apply to how - applications use data after it is retrieved from a HTTP cache. That is, a + applications use data after it is retrieved from a HTTP cache. For example, a history mechanism can display a previous representation even if it has expired, and an application can use cached data in other ways beyond its freshness lifetime. - This does not prohibit the application from taking HTTP caching into + This specification does not prohibit the application from taking HTTP caching into account; for example, a history mechanism might tell the user that a view is stale, or it might honor cache directives (e.g., Cache-Control: - no-store). + no-store). In particular, when an application caches data and does not make this + apparent to or easily controllable by the user, it is strongly encouraged to + honour basic control mechanisms like Cache-Control: no-store, as they + indicate the resource's intent regarding caching.
    @@ -2150,6 +2180,7 @@ + @@ -2368,14 +2399,24 @@
    - - Handling invalid and multiple Age header field values has been clarified. - () - Handling of duplicate and conflicting cache directives has been clarified. () + + Cache invalidation of the URIs in the Location and Content-Location + header fields is no longer required, but still allowed. + () + + + Cache invalidation of the URIs in the Location and Content-Location header fields is disallowed + when the origin is different; previously, it was the host. + () + + + Handling invalid and multiple Age header field values has been clarified. + () + Some cache directives defined by this specification now have stronger prohibitions against generating the quoted form of their values, since @@ -2527,13 +2568,16 @@
    • In , remove 'no-store', as it won't be in cache in the first place ()
    • In , make it clear that only response headers need be stored ()
      • -
    • In , mention retry of failed validation requests ()
    • In clarify how to handle invalid and conflicting directives ()
      • +
    • In , mention retry of failed validation requests ()
    • In , clarify requirement on storing a full response to a conditional request ()
    • In , clarify error handling ()
    • In , remove spurious "UTC" ()
    • In , correct the date-related rule names to consider case-insensitive ()
      • +
    • In , strengthen recommendation for application caches to pay attention to cache directives ()
    • In , mention collapsed requests ()
      • +
    • In , relax requirements on Content-Location and Location invalidation ()
      • +
    • In , refine the exceptions to update on a 304 ()
    diff --git a/draft-ietf-httpbis-messaging-latest.html b/draft-ietf-httpbis-messaging-latest.html index 28d951d68..6615c3834 100644 --- a/draft-ietf-httpbis-messaging-latest.html +++ b/draft-ietf-httpbis-messaging-latest.html @@ -638,7 +638,7 @@ content: "Fielding, et al."; } @bottom-center { - content: "Expires May 16, 2021"; + content: "Expires May 23, 2021"; } @bottom-right { content: "[Page " counter(page) "]"; @@ -685,7 +685,7 @@ - + @@ -711,7 +711,7 @@ Fastly - Expires: May 16, 2021 + Expires: May 23, 2021 J. Reschke, Editor @@ -720,7 +720,7 @@ - November 12, 2020 + November 19, 2020 @@ -774,7 +774,7 @@

    Status of This Memo

    Internet-Drafts as reference material or to cite them other than as “work in progress”.

    -

    This Internet-Draft will expire on May 16, 2021.

    +

    This Internet-Draft will expire on May 23, 2021.

    diff --git a/draft-ietf-httpbis-semantics-latest.html b/draft-ietf-httpbis-semantics-latest.html index 7670f09d3..684ec30bf 100644 --- a/draft-ietf-httpbis-semantics-latest.html +++ b/draft-ietf-httpbis-semantics-latest.html @@ -638,7 +638,7 @@ content: "Fielding, et al."; } @bottom-center { - content: "Expires May 16, 2021"; + content: "Expires May 23, 2021"; } @bottom-right { content: "[Page " counter(page) "]"; @@ -689,7 +689,7 @@ - + @@ -719,20 +719,20 @@ M. Nottingham, Editor - Intended status: Standards Track + Updates: 3864 (if approved) Fastly - Expires: May 16, 2021 + Intended status: Standards Track J. Reschke, Editor - + Expires: May 23, 2021 greenbytes - November 12, 2020 + November 19, 2020 @@ -788,7 +788,7 @@

    Status of This Memo

    Internet-Drafts as reference material or to cite them other than as “work in progress”.

    -

    This Internet-Draft will expire on May 16, 2021.

    +

    This Internet-Draft will expire on May 23, 2021.

    @@ -7581,9 +7581,15 @@

    13.2. 

    +

    The above does not imply that a server will send all requested ranges. In some cases, + it may only be possible (or efficient) to send a portion of the requested ranges first, + while expecting the client to re-request the remaining portions later if they are + still desired (see Section 14.3.7).

    +
    +

    If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or unsatisfiable, the - server SHOULD send a 416 (Range Not Satisfiable) response.

    + server SHOULD send a 416 (Range Not Satisfiable) response.

    @@ -7880,17 +7886,20 @@

    14.2. 

    The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. - 1xx responses are terminated by the end of the header section. Since HTTP/1.0 did - not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.

    + Since HTTP/1.0 did not define any 1xx status codes, a server MUST NOT send a 1xx response to an HTTP/1.0 client.

    -

    A client MUST be able to parse one or more 1xx responses received prior to a final response, even - if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

    +

    A 1xx response is terminated by the end of the header section because it cannot contain + a message body or trailers.

    +

    A client MUST be able to parse one or more 1xx responses received prior to a final response, even + if the client does not expect one. A user agent MAY ignore unexpected 1xx responses.

    +
    +

    A proxy MUST forward 1xx responses unless the proxy itself requested the generation of the 1xx response. For example, if a proxy adds an "Expect: 100-continue" header field when - it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).

    + it forwards a request, then it need not forward the corresponding 100 (Continue) response(s).

    14.2.1. 100 Continue

    @@ -8068,22 +8077,34 @@

    14.3.7. selected representation.

    -

    When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the subsections - below, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.

    +

    A server that supports range requests (Section 13) will usually attempt to satisfy all of the requested ranges, since sending less + data will likely result in another client request for the remainder. However, a server + might want to send only a subset of the data requested for reasons of its own, such + as temporary unavailability, cache efficiency, load balancing, etc. Since a 206 response + is self-descriptive, the client can still understand a response that only partially + satisfies its range request.

    +

    A client MUST inspect a 206 response's Content-Type and Content-Range field(s) to determine what parts are enclosed and whether additional requests are + needed.

    +
    +
    +

    When a 206 response is generated, the server MUST generate the following header fields, in addition to those required in the subsections + below, if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and Vary.

    +
    +

    A Content-Length header field present in a 206 response indicates the number of octets in the body of this message, which is usually not the complete length of the selected representation. - Each Content-Range header field includes information about the selected representation's complete length.

    + Each Content-Range header field includes information about the selected representation's complete length.

    -
    +

    If a 206 is generated in response to a request with an If-Range header field, the sender SHOULD NOT generate other representation header fields beyond those required, because the client is understood to already have a prior response containing those header fields. Otherwise, - the sender MUST generate all of the representation header fields that would have been sent in a 200 (OK) response to the same request.

    + the sender MUST generate all of the representation header fields that would have been sent in a 200 (OK) response to the same request.

    -
    +

    A 206 response is heuristically cacheable; i.e., unless otherwise indicated by explicit - cache controls (see Section 4.2.2 of [Caching]).

    + cache controls (see Section 4.2.2 of [Caching]).

    14.3.7.1. Single Part
    @@ -9974,7 +9995,7 @@

    17.3. 206 Partial Content - 14.3.7 + 14.3.7 300 @@ -10177,14 +10198,19 @@

    17.3. 

    17.4. Field Name Registration

    -

    Please create a new registry as outlined in Section 15.3.1.

    +

    This specification updates the HTTP related aspects of the existing registration procedures + for message header fields defined in [RFC3864]. It defines both a new registration procedure and moves HTTP field definitions into + a separate registry.

    +
    +
    +

    Please create a new registry as outlined in Section 15.3.1.

    -
    +

    After creating the registry, all entries in the Permanent and Provisional Message Header Registries with the protocol 'http' are to be moved to it, with the following - changes applied:

    + changes applied:

    -
    +
    1. The 'Applicable Protocol' field is to be omitted.
    2. Entries with a status of 'standard', 'experimental', 'reserved', or 'informational' @@ -10195,13 +10221,13 @@

      17.4.  + -
      +

      After that is complete, please update the new registry with the field names listed - in the following table.

      + in the following table.

      @@ -10476,13 +10502,13 @@

      17.4.  + -
      +

      Finally, please update the "Content-MD5" entry in the new registry to have a status - of 'obsoleted' with references to Section 14.15 of [RFC2616] (for the definition of the header field) and Appendix B of [RFC7231] (which removed the field definition from the updated specification).

      + of 'obsoleted' with references to Section 14.15 of [RFC2616] (for the definition of the header field) and Appendix B of [RFC7231] (which removed the field definition from the updated specification).

      @@ -10665,6 +10691,8 @@

      18.2. Informative Refe
      Freed, N. and J. Postel, “IANA Charset Registration Procedures”, BCP 19, RFC 2978, DOI 10.17487/RFC2978, October 2000, <https://www.rfc-editor.org/info/rfc2978>.
      [RFC3040]
      Cooper, I., Melve, I., and G. Tomlinson, “Internet Web Replication and Caching Taxonomy”, RFC 3040, DOI 10.17487/RFC3040, January 2001, <https://www.rfc-editor.org/info/rfc3040>.
      +
      [RFC3864]
      +
      Klyne, G., Nottingham, M., and J. Mogul, “Registration Procedures for Message Header Fields”, BCP 90, RFC 3864, DOI 10.17487/RFC3864, September 2004, <https://www.rfc-editor.org/info/rfc3864>.
      [RFC4033]
      Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, “DNS Security Introduction and Requirements”, RFC 4033, DOI 10.17487/RFC4033, March 2005, <https://www.rfc-editor.org/info/rfc4033>.
      [RFC4559]
      @@ -11197,7 +11225,7 @@

      C.3. https://github.com/httpwg/http-core/issues/94>, <https://www.rfc-editor.org/errata/eid4050>)
    3. Added a missing word in Section 14.4 (<https://github.com/httpwg/http-core/issues/98>, <https://www.rfc-editor.org/errata/eid4452>)
    4. In Section 5.7.1, fixed an example that had trailing whitespace where it shouldn't (<https://github.com/httpwg/http-core/issues/104>, <https://www.rfc-editor.org/errata/eid4169>)
      5. -
    5. In Section 14.3.7, remove words that were potentially misleading with respect to the relation to the +
    6. In Section 14.3.7, remove words that were potentially misleading with respect to the relation to the requested ranges (<https://github.com/httpwg/http-core/issues/102>, <https://www.rfc-editor.org/errata/eid4358>)

      7. @@ -11385,7 +11413,7 @@

      C.12. Section 7.4, defined error handling for multiple members (<https://github.com/httpwg/http-core/issues/39>)
    7. In Section 1, revise the introduction and introduce HTTP/2 and HTTP/3 (<https://github.com/httpwg/http-core/issues/64>)
    8. In Section 7.7, added a definition for Content-Length that encompasses its various roles in describing message payload or selected representation - length; in Section 14.3.7, noted that Content-Length counts only the message body (not the selected representation) and that the complete + length; in Section 14.3.7, noted that Content-Length counts only the message body (not the selected representation) and that the complete length is in each Content-Range (<https://github.com/httpwg/http-core/issues/118>)
    9. Noted that "WWW-Authenticate" with more than one value on a line is sometimes not interoperable [Messaging] (<https://github.com/httpwg/http-core/issues/136>)
      10. @@ -11423,11 +11451,17 @@

      C.13. C.14. Since draft-ietf-httpbis-semantics-12 📄

      @@ -11441,16 +11475,21 @@

      Acknowledgments

      Larry Masinter, Paul J. Leach, Eric Rescorla, and Yves Lafon.

      -

      See Section 10 of [RFC7230] for further acknowledgements from prior revisions.

      -
      -

      In addition, this document has reincorporated the HTTP Authentication Framework, previously defined in RFC 7235 and RFC 2617. We thank John Franks, Phillip M. Hallam-Baker, Jeffery L. Hostetler, Scott D. Lawrence, Paul J. Leach, Ari Luotonen, and Lawrence C. Stewart for their work on that specification. - See Section 6 of [RFC2617] for further acknowledgements.

      + See Section 6 of [RFC2617] for further acknowledgements.

      +
      +
      +

      Since 2014, the following contributors have helped improve the HTTP specification + by reporting bugs, asking smart questions, drafting or reviewing text, and evaluating + open issues:

      -

      [newacks: New acks to be added here.]

      +

      Alan Egerton, Alex Rousskov, Amichai Rothman, Amos Jeffries, Anders Kaseorg, Andreas Gebhardt, Anne van Kesteren, Armin Abfalterer, Aron Duby, Asanka Herath, Asbjørn Ulsberg, Attila Gulyas, Austin Wright, Barry Pollard, Ben Burkert, Björn Höhrmann, Brad Fitzpatrick, Chris Pacejo, Colin Bendell, Cory Benfield, Cory Nelson, Daisuke Miyakawa, Daniel Stenberg, Danil Suits, David Benjamin, David Matson, David Schinazi, Дилян Палаузов (Dilyan Palauzov), Eric Anderson, Eric Rescorla, Erwin Pe, Etan Kissling, Evert Pot, Evgeny Vrublevsky, Florian Best, Igor Lubashev, James Callahan, Jeffrey Yasskin, Kalin Gyokov, Kannan Goundan, Kazuho Oku, Ken Murchison, Lucas Pardue, Martin Dürst, Martin Thomson, Martynas Jusevičius, Matt Menke, Matthias Pigulla, Michael Osipov, Mike Bishop, Mike Pennisi, Mike West, Nicholas Hurley, Nikita Piskunov, Patrick McManus, Piotr Sikora, Poul-Henning Kamp, Rick van Rein, Roberto Polli, Semyon Kholodnov, Simon Pieters, Simon Schüppel, Todd Greer, Tommy Pauly, Vasiliy Faronov, Vladimir Lashchev, Wenbo Zhu, William A. Rowe Jr., Willy Tarreau, Xingwei Liu, and Yishuai Li.

      +
      +
      +

      See Section 10 of [RFC7230] for further acknowledgements from prior revisions.

      @@ -11462,7 +11501,7 @@

      Index

    10. 100 Continue (status code)  14.2.1, 17.3
    11. 100-continue (expect value)  9.1.1
    12. 101 Switching Protocols (status code)  14.2.2, 17.3
      13. -
    13. 1xx Informational (status code class)  14.2
      14. +
    14. 1xx Informational (status code class)  14.2, C.14
    15. 2
      16. @@ -12041,6 +12080,7 @@

      Index

    16. RFC3040  3.7, 18.2
      17. +
    17. RFC3864  17.4, 18.2, C.14
    18. RFC3986  3.1, 4, 4.1, 4.1, 4.1, 4.1, 4.1, 4.1, 4.1, 4.1, 4.1, 4.2.1, 4.2.2, 4.2.3, 4.2.3, 4.2.3, 4.2.3, 4.2.4, 4.2.5, 4.2.5, 6.1.1, 7.8, 8.3.6, 9.1.3, 9.1.3, 9.2.3, 9.2.3, 10.2, 18.1, A, A, A, A, A, A, A, A, A, B.2, C.4
      • Section 2.1  4.2.3
      • Section 2.2  4.2.3
        • @@ -12164,7 +12204,7 @@

        Index

      • Status Codes Classes  
          -
        • 1xx Informational  14.2
          • +
        • 1xx Informational  14.2, C.14
        • 2xx Successful  14.3
        • 3xx Redirection  6.6, 14.4, B.3, C.3, C.12
        • 4xx Client Error  14.5
          • diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 39bf7d104..1aaed832d 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -34,6 +34,7 @@ + + The above does not imply that a server will send all requested ranges. + In some cases, it may only be possible (or efficient) to send a portion of + the requested ranges first, while expecting the client to re-request the + remaining portions later if they are still desired + (see ). + If all of the preconditions are true, the server supports the Range header field for the target resource, and the specified range(s) are invalid or @@ -8193,10 +8201,13 @@ Content-Range: exampleunit 11.2-14.3/25 The 1xx (Informational) class of status code indicates an interim response for communicating connection status or request progress prior to completing the requested action and sending a final response. - 1xx responses are terminated by the end of the header section. Since HTTP/1.0 did not define any 1xx status codes, a server &MUST-NOT; send a 1xx response to an HTTP/1.0 client. + + A 1xx response is terminated by the end of the header section + because it cannot contain a message body or trailers. + A client &MUST; be able to parse one or more 1xx responses received prior to a final response, even if the client does not expect one. @@ -8451,11 +8462,28 @@ Content-Range: exampleunit 11.2-14.3/25 The 206 (Partial Content) status code indicates that the server is successfully fulfilling a range request for the target resource - by transferring one or more parts of the selected representation. + by transferring one or more parts of the + selected representation. + + + A server that supports range requests () will + usually attempt to satisfy all of the requested ranges, since sending + less data will likely result in another client request for the remainder. + However, a server might want to send only a subset of the data requested + for reasons of its own, such as temporary unavailability, cache efficiency, + load balancing, etc. Since a 206 response is self-descriptive, the client + can still understand a response that only partially satisfies its range + request. + + + A client &MUST; inspect a 206 response's Content-Type and + Content-Range field(s) to determine what parts are enclosed + and whether additional requests are needed. When a 206 response is generated, the server &MUST; generate the following - header fields, in addition to those required in the subsections below, if the field would + header fields, in addition to those required in the subsections below, + if the field would have been sent in a 200 (OK) response to the same request: Date, Cache-Control, ETag, Expires, Content-Location, and @@ -11138,6 +11166,12 @@ Content-Type: text/plain
      19. + + This specification updates the HTTP related aspects of the existing + registration procedures for message header fields defined in . + It defines both a new registration procedure and moves HTTP field + definitions into a separate registry. + Please create a new registry as outlined in . @@ -11147,7 +11181,6 @@ Content-Type: text/plain Message Header Registries with the protocol 'http' are to be moved to it, with the following changes applied: -
      1. The 'Applicable Protocol' field is to be omitted.
      2. Entries with a status of 'standard', 'experimental', 'reserved', or @@ -12621,6 +12654,18 @@ Content-Type: text/plain + + + Registration Procedures for Message Header Fields + + + + + + + + + Internet Message Format @@ -13461,11 +13506,15 @@ transfer-coding = <transfer-coding, see
          +
        • In , added acks for the work since 2014 ()
          • +
        • In , specifically require that a client check the 206 response header fields to determine what ranges are enclosed, since it cannot assume they exactly match those requested ()
        • In , explain why new fields need to be backwards-compatible ()
        • In , constrain field combination to be within a section ()
        • In , mention that caching relaxes date sensitivity ()
        • In , moved "*" field registration into main table ()
        • In , reference ()
          • +
        • In , align language about bodies and trailers with 204 and 304 ()
          • +
        • In , note that this document updates ()
      @@ -13484,10 +13533,6 @@ transfer-coding = <transfer-coding, see - - See for further - acknowledgements from prior revisions. - In addition, this document has reincorporated the HTTP Authentication Framework, previously defined in @@ -13500,7 +13545,86 @@ transfer-coding = <transfer-coding, see - New acks to be added here. + Since 2014, the following contributors have helped improve the HTTP + specification by reporting bugs, asking smart questions, drafting or + reviewing text, and evaluating open issues: + + + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , + , and + . + + + See for further + acknowledgements from prior revisions. diff --git a/httpbis-errata-status.html b/httpbis-errata-status.html index 2aa53b3d3..a69bf7839 100644 --- a/httpbis-errata-status.html +++ b/httpbis-errata-status.html @@ -459,7 +459,7 @@ content: ""; } @top-right { - content: "September 2020"; + content: "November 2020"; } @top-center { content: "RFC723* Errata Status"; @@ -489,7 +489,7 @@ - + @@ -503,7 +503,7 @@ - +
      September 4, 2020November 17, 2020
      @@ -760,7 +760,7 @@

      1. 5620 [RFC7233], Section 4.2 2019-02-01 - Reported + Held for Document Update Armin Abfalterer #196 (see [Semantics], Appendix C.7) @@ -800,7 +800,7 @@

      1.  -
      +

      Figure 1: Errata by Category and Status

    @@ -809,23 +809,23 @@

    1. 2. References

    [Cache]
    -
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Caching”, Internet-Draft draft-ietf-httpbis-cache-latest (work in progress), September 2020.
    +
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Caching”, Internet-Draft draft-ietf-httpbis-cache-latest (work in progress), November 2020.
    [Messaging]
    -
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1 Messaging”, Internet-Draft draft-ietf-httpbis-messaging-latest (work in progress), September 2020.
    +
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP/1.1 Messaging”, Internet-Draft draft-ietf-httpbis-messaging-latest (work in progress), November 2020.
    [RFC7230]
    -
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
    +
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing”, RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
    [RFC7231]
    -
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
    +
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content”, RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
    [RFC7232]
    -
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
    +
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests”, RFC 7232, DOI 10.17487/RFC7232, June 2014, <https://www.rfc-editor.org/info/rfc7232>.
    [RFC7233]
    -
    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP): Range Requests”, RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
    +
    Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP): Range Requests”, RFC 7233, DOI 10.17487/RFC7233, June 2014, <https://www.rfc-editor.org/info/rfc7233>.
    [RFC7234]
    -
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
    +
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP): Caching”, RFC 7234, DOI 10.17487/RFC7234, June 2014, <https://www.rfc-editor.org/info/rfc7234>.
    [RFC7235]
    -
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
    +
    Fielding, R., Ed. and J. Reschke, Ed., “Hypertext Transfer Protocol (HTTP/1.1): Authentication”, RFC 7235, DOI 10.17487/RFC7235, June 2014, <https://www.rfc-editor.org/info/rfc7235>.
    [Semantics]
    -
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, Internet-Draft draft-ietf-httpbis-semantics-latest (work in progress), September 2020.
    +
    Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, Ed., “HTTP Semantics”, Internet-Draft draft-ietf-httpbis-semantics-latest (work in progress), November 2020.

    diff --git a/httpbis-errata-status.xml b/httpbis-errata-status.xml index 35848eac6..ffe17b277 100644 --- a/httpbis-errata-status.xml +++ b/httpbis-errata-status.xml @@ -394,7 +394,7 @@ 2019-02-01 - Reported + Held for Document Update Armin Abfalterer #196 (see ) @@ -456,7 +456,7 @@
    + src="https://chart.apis.google.com/chart?cht=p3&chco=00FF00|00A000|FF0000|A00000|0000FF|0000A0&chdl=Verified%20open|Verified%20closed|Held%20open|Held%20closed|Reported%20open|Reported%20closed&chd=t%3A0,14,0,12,1,5&chs=640x400"/>

    @@ -605,4 +605,4 @@ - + \ No newline at end of file