7. Guidance for Future Upgrade Tokens

This section preserves the RFC text for optimistic HTTP/1.1 protocol transitions, including request smuggling risks, parser exploit risks, existing Upgrade tokens, HTTP CONNECT requirements, and IANA status.

7.  Guidance for Future Upgrade Tokens

   There are now several good examples of designs that reduce or
   eliminate the security concerns discussed in this document and may be
   applicable in future specifications:

   *  Forbid optimistic use of HTTP Upgrade (Section 4.1 of [WEBSOCKET]
      and Section 11 of [CONNECT-IP]).

   *  Embed a fixed preamble that deliberately terminates HTTP/1.1
      processing (Section 3.4 of [HTTP/2]).

   *  Apply high-entropy masking of client-to-server data (Section 5.1
      of [WEBSOCKET]).

   Future specifications for upgrade tokens should account for the
   security issues discussed here and provide clear guidance on how
   implementations can avoid them.

7.1.  Selection of Request Methods

   Some upgrade tokens, such as "TLS", are defined for use with any
   ordinary HTTP method.  The upgraded protocol continues to provide
   HTTP semantics and will convey the response to this HTTP request.

   The other upgrade tokens mentioned in Section 6 do not preserve HTTP
   semantics, so the method is not relevant.  All of these upgrade
   tokens are specified only for GET requests with no content.

   Future specifications for upgrade tokens should restrict their use to
   GET requests with no content if the HTTP method is otherwise
   irrelevant and the request does not need to carry any message
   content.  This improves consistency with other upgrade tokens and
   simplifies server implementation.