From 939d01d11ecf00294c75af8a5c5e0babffb9b990 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 22 Oct 2020 15:47:24 +1100 Subject: [PATCH 1/2] Talk about field backwards compatibility Fixes #448 --- draft-ietf-httpbis-semantics-latest.xml | 46 +++++++++++++++++++------ 1 file changed, 35 insertions(+), 11 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index 76e8c890d..65e9eef5f 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -9717,9 +9717,33 @@ Content-Type: text/plain -
+
+ + HTTP's most widely used extensibility point is the definition of new header and + trailer fields. + + + New fields can be defined such that, when they are understood by a + recipient, they override or enhance the interpretation of previously + defined fields, define preconditions on request evaluation, or + refine the meaning of responses. + + + However, by their nature HTTP fields cannot be required to be understood + by recipients without previous arrangement. For example, a new request + precondition cannot be assumed to be supported by servers; a server that + has not yet implemented it will ignore the field and process the request + as usual. Therefore, a function that uses new fields needs to either + degrade gracefully when handled by a recipient who does not understand + them, or use negotiation mechanism to establish whether the recipient + supports the fields in question. Typically, this will be out of band; for + example, using a particular media type might imply support for associated + header fields, or interacting with a defined well-known URI might do so. + +
@@ -9798,16 +9822,6 @@ Content-Type: text/plain
- - There is no limit on the introduction of new field names, each presumably - defining new semantics. - - - New fields can be defined such that, when they are understood by a - recipient, they might override or enhance the interpretation of previously - defined fields, define preconditions on request evaluation, or - refine the meaning of responses. - Authors of specifications defining new fields are advised to choose a short but descriptive field name. Short names avoid needless data transmission; @@ -12483,6 +12497,15 @@ Content-Type: text/plain + + + Well-Known Uniform Resource Identifiers (URIs) + + + + + + Hypertext Transfer Protocol Version 3 (HTTP/3) @@ -13382,6 +13405,7 @@ transfer-coding = <transfer-coding, see
    +
  • In , explain why new fields need to be backwards-compatible ()
From 949a490347999e70e9c5d0b3265808234d8a13d0 Mon Sep 17 00:00:00 2001 From: Mark Nottingham Date: Thu, 12 Nov 2020 16:41:48 +1100 Subject: [PATCH 2/2] Update draft-ietf-httpbis-semantics-latest.xml Co-authored-by: Roy T. Fielding --- draft-ietf-httpbis-semantics-latest.xml | 21 ++++++++++----------- 1 file changed, 10 insertions(+), 11 deletions(-) diff --git a/draft-ietf-httpbis-semantics-latest.xml b/draft-ietf-httpbis-semantics-latest.xml index fe39f005c..36182d5f1 100644 --- a/draft-ietf-httpbis-semantics-latest.xml +++ b/draft-ietf-httpbis-semantics-latest.xml @@ -9733,17 +9733,16 @@ Content-Type: text/plain refine the meaning of responses. - However, by their nature HTTP fields cannot be required to be understood - by recipients without previous arrangement. For example, a new request - precondition cannot be assumed to be supported by servers; a server that - has not yet implemented it will ignore the field and process the request - as usual. Therefore, a function that uses new fields needs to either - degrade gracefully when handled by a recipient who does not understand - them, or use negotiation mechanism to establish whether the recipient - supports the fields in question. Typically, this will be out of band; for - example, using a particular media type might imply support for associated - header fields, or interacting with a defined well-known URI might do so. + However, defining a field doesn't guarantee its deployment or recognition + by recipients. Most fields are designed with the expectation that a recipient + can safely ignore (but forward downstream) any field not recognized. + In other cases, the sender's ability to understand a given field might be + indicated by its prior communication, perhaps in the protocol version + or fields that it sent in prior messages, or its use of a specific media type. + Likewise, direct inspection of support might be possible through an + OPTIONS request or by interacting with a defined well-known URI + if such inspection is defined along with + the field being introduced.