From e8594c70568e477ce0ce1edee070cd09e0be39ef Mon Sep 17 00:00:00 2001 From: Ben Schwartz Date: Fri, 12 Jul 2024 10:16:30 -0400 Subject: [PATCH] Remove deprecation assumption --- draft-ietf-httpbis-optimistic-upgrade.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/draft-ietf-httpbis-optimistic-upgrade.md b/draft-ietf-httpbis-optimistic-upgrade.md index 69fcd0010..ff7ca3303 100644 --- a/draft-ietf-httpbis-optimistic-upgrade.md +++ b/draft-ietf-httpbis-optimistic-upgrade.md @@ -139,11 +139,13 @@ There are now several good examples of designs that prevent the security concern Future specifications for Upgrade Tokens MUST account for the security issues discussed here and provide clear guidance on how clients can avoid them. -## Use of Request Bodies with Upgrade +## Selection of Request Methods with Upgrade -With the deprecations noted in this document, all remaining HTTP Upgrade Tokens apply only to GET requests with an empty body. While HTTP Upgrade is well-defined for requests using any HTTP method, with or without a request body, implementation of Upgrade with a request body may be more difficult. +The "HTTP" and "TLS" Upgrade Tokens can be used with any ordinary HTTP Method. The upgraded protocol continues to provide HTTP semantics, and will convey the response to this HTTP request. -Future specifications for Upgrade Tokens SHOULD restrict their usage to GET requests if possible, for consistency and simplicity. +The other Upgrade Tokens presently defined do not preserve HTTP semantics, so the method is not relevant. All of these Upgrade Tokens are specified only for use with the "GET" method. + +Future specifications for Upgrade Tokens SHOULD restrict their use to GET requests if the HTTP method is otherwise irrelevant. This simplifies server implementation and reduces the risk of errors when processing request bodies. # IANA Considerations