Compression Context State After Refused Messages in WebSocket Per-Message Compression
draft-srivastava-websocket-pmce-state-reset-00

Network Working Group                                      A. Srivastava
Internet-Draft                                            13 August 2026
Intended status: Informational                                          
Expires: 14 February 2027

   Compression Context State After Refused Messages in WebSocket Per-
                          Message Compression
             draft-srivastava-websocket-pmce-state-reset-00

Abstract

   RFC 7692 defines Per-Message Compression Extensions for the WebSocket
   Protocol, including the "permessage-deflate" extension.  When context
   takeover is in effect, the LZ77 sliding window is retained across
   messages, so the decompression of one message can depend on the
   plaintext of earlier messages.

   RFC 7692 does not state what the sliding window contains after a
   message has been successfully decompressed but subsequently refused
   by a check applied to the decompressed plaintext, such as UTF-8
   validation, a payload size limit, or an application-level policy.  An
   implementation that retains the refused plaintext in the window
   violates no stated requirement, yet the content of a refused message
   can then influence the decompression of a later message that is
   accepted.

   This document describes the gap, contrasts it with the corresponding
   situation in QPACK where RFC 9204 specifies the required behavior,
   and recommends behavior for implementations.  It defines no new
   protocol element and updates no existing specification.

Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at https://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on 14 February 2027.

Srivastava              Expires 14 February 2027                [Page 1]
Internet-Draft      PMCE State After Refused Messages        August 2026

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.  Code Components
   extracted from this document must include Revised BSD License text as
   described in Section 4.e of the Trust Legal Provisions and are
   provided without warranty as described in the Revised BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  The Unspecified Case  . . . . . . . . . . . . . . . . . . . .   3
     3.1.  What RFC 7692 Specifies . . . . . . . . . . . . . . . . .   3
     3.2.  What Is Not Specified . . . . . . . . . . . . . . . . . .   3
     3.3.  Observed Behavior . . . . . . . . . . . . . . . . . . . .   4
   4.  Comparison with QPACK . . . . . . . . . . . . . . . . . . . .   5
   5.  Recommendations . . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  For Implementations . . . . . . . . . . . . . . . . . . .   6
     5.2.  For Implementations Exposing Codec Interfaces . . . . . .   6
     5.3.  For Configurable Termination Behavior . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   8
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .   8
     8.2.  Informative References  . . . . . . . . . . . . . . . . .   8
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .   8
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   8

1.  Introduction

   The "permessage-deflate" extension defined in [RFC7692] compresses
   WebSocket message payloads using DEFLATE [RFC1951].  Unless
   "no_context_takeover" has been negotiated, the LZ77 sliding window
   persists across messages on a connection.  This is the behavior that
   makes the extension effective: repeated content across messages
   compresses well precisely because the window retains earlier
   plaintext.

Srivastava              Expires 14 February 2027                [Page 2]
Internet-Draft      PMCE State After Refused Messages        August 2026

   Retaining state across messages means the interpretation of one
   message can depend on the content of earlier ones.  A back-reference
   in a later message resolves against whatever the window currently
   holds.

   Implementations commonly apply checks to the decompressed plaintext
   after decompression has completed.  UTF-8 validity for text messages
   is required by [RFC6455].  Payload size limits are common in
   deployment.  Applications frequently apply their own content policy.
   When such a check refuses a message, decompression has already
   succeeded and the plaintext is already in the window.

   [RFC7692] does not say what the window should contain at that point.
   This document describes that gap and its consequences, and recommends
   behavior.

2.  Terminology

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described in
   BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

   This document uses "refused message" to mean a message whose payload
   was successfully decompressed by the extension, and which was then
   rejected by a check applied to the decompressed plaintext.  A message
   that fails to decompress is not a refused message in this sense.

3.  The Unspecified Case

3.1.  What RFC 7692 Specifies

   Section 7.1.1.1 of [RFC7692] describes the
   "server_no_context_takeover" extension parameter, and Section 7.1.1.2
   describes "client_no_context_takeover".  Absent these parameters, an
   endpoint retains the LZ77 sliding window across messages.

   Section 7.2.2 of [RFC7692] describes decompression and the conditions
   under which the sliding window is reset.  The specification is
   written in terms of successful message processing and of
   decompression failure.  It does not address the case where
   decompression succeeds and the message is refused afterwards.

3.2.  What Is Not Specified

   Consider a connection with context takeover in effect:

Srivastava              Expires 14 February 2027                [Page 3]
Internet-Draft      PMCE State After Refused Messages        August 2026

   1.  An endpoint receives message A.  The payload decompresses
       successfully.  The resulting plaintext enters the sliding window,
       because that is what context takeover requires.

   2.  A check applied after decompression refuses message A.  The check
       may be UTF-8 validation, a payload length limit, an opcode
       constraint, or an application policy.

   3.  The endpoint continues processing the connection.

   4.  The endpoint receives message B, which decompresses successfully
       and passes every check.  Message B contains an LZ77 back-
       reference that resolves into the region of the window occupied by
       the plaintext of message A.

   5.  Message B is delivered to the application.  Its content includes
       material from message A, which was refused.

   At no point in this sequence does an implementation violate a stated
   requirement of [RFC7692].  Retaining the plaintext of a refused
   message in the window is neither required nor forbidden.

   The consequence is that a check applied to decompressed plaintext
   does not, on its own, prevent that plaintext from reaching the
   application.  It prevents delivery of the message that carried it.
   The content remains available to be reproduced by a subsequent
   message that the same check accepts.

3.3.  Observed Behavior

   Implementations vary in how they handle this case, and the variation
   does not appear to be the result of differing interpretations of
   [RFC7692].  It appears to result from properties of the surrounding
   implementation.

   Some implementations terminate the connection whenever a post-
   decompression check fails.  In those implementations the sequence in
   Section 3.2 cannot complete, because there is no connection on which
   message B could arrive.  The compression context is not reset; it
   simply becomes unreachable.

   Other implementations allow a post-decompression check to fail
   without terminating the connection, either by default or under a
   configuration option.  In those implementations the sequence can
   complete.

Srivastava              Expires 14 February 2027                [Page 4]
Internet-Draft      PMCE State After Refused Messages        August 2026

   The distinction that determines the outcome is therefore the
   connection lifecycle policy of the surrounding implementation, not
   any property of the compression extension.  An implementation that is
   safe for this reason may cease to be safe if its termination behavior
   is made configurable, or if its compression codec is exposed as an
   interface that other software drives directly.

   A related concern was raised against one implementation in a public
   issue report [NETTY6209], which discusses the state of the
   compression context following an error.  The general question of what
   the window should contain after a refused message does not appear to
   have been treated in the specification.

4.  Comparison with QPACK

   QPACK [RFC9204] presents a structurally similar hazard.  The dynamic
   table persists across field sections on a connection, so the
   interpretation of one field section can depend on earlier ones.  If a
   field section were refused after decoding, and the dynamic table
   retained its effects, a later accepted field section could reference
   entries derived from the refused one.

   Section 6 of [RFC9204] addresses this directly.  It specifies that
   certain decoding failures MUST be treated as connection errors of the
   relevant type.  The result is that a QPACK implementation cannot
   continue on a connection whose decoder state is in question, because
   the specification does not permit it to.

   The two cases are worth stating side by side:

   *  Both protocols maintain state across message or field-section
      boundaries, and in both the state affects how later input is
      interpreted.

   *  RFC 9204 states what must happen when that state is in question.
      An implementation that continues is non-conforming.

   *  RFC 7692 does not state what must happen.  An implementation that
      continues is conforming.

   The difference in outcome between implementations of the two
   protocols appears to follow from this difference in what the
   specifications require, rather than from differences in
   implementation quality.

Srivastava              Expires 14 February 2027                [Page 5]
Internet-Draft      PMCE State After Refused Messages        August 2026

5.  Recommendations

   The following recommendations are addressed to implementers of
   [RFC7692] and to applications built on it.  They are stated as
   recommendations rather than as updates to [RFC7692]; this document
   does not update that specification.

5.1.  For Implementations

   When a message is refused by a check applied to its decompressed
   plaintext, an implementation SHOULD do one of the following:

   1.  Fail the WebSocket Connection as described in Section 7.1.7 of
       [RFC6455], so that no further message is processed using the
       affected compression context; or

   2.  Reset the LZ77 sliding window for the affected direction, so that
       the plaintext of the refused message cannot be referenced by a
       later message.

   The first option is what several implementations already do as a
   consequence of their error handling.  Making it an explicit
   consequence of the refusal, rather than an incidental one, means the
   property is preserved if the surrounding error handling changes.

   An implementation that continues processing a connection after
   refusing a message, without resetting the window, SHOULD document
   that behavior, so that applications relying on post-decompression
   checks are aware that a refused message's content remains
   referenceable.

5.2.  For Implementations Exposing Codec Interfaces

   An implementation that exposes its compression codec as an interface
   which other software may drive directly, separately from its own
   connection handling, SHOULD document whether the safety of that codec
   depends on connection termination performed elsewhere.

   Software driving such an interface does not necessarily inherit the
   error handling of the implementation that provides it.  A codec whose
   safety in practice depends on a connection teardown performed by a
   separate component is not safe when driven without that component.

Srivastava              Expires 14 February 2027                [Page 6]
Internet-Draft      PMCE State After Refused Messages        August 2026

5.3.  For Configurable Termination Behavior

   Where an implementation provides a configuration option that
   suppresses connection termination on protocol violations, the
   documentation for that option SHOULD state which components the
   option governs.

   An option described in general terms as controlling behavior on
   protocol violations may in practice govern only some of the
   components that can refuse a message, leaving the compression context
   outside its scope.  An operator selecting such an option is unlikely
   to infer that from the option's name.

6.  Security Considerations

   The concern described in this document is that a check applied to
   decompressed plaintext may not have the effect an application
   expects.  Refusing a message prevents its delivery.  It does not
   necessarily prevent its content from being delivered later, inside a
   message that the same check accepts.

   Applications that rely on post-decompression validation as a security
   control should be aware of this.  A UTF-8 validity check, a payload
   size limit, or a content policy applied after decompression
   constrains which messages are delivered, not which plaintext can
   reach the application.

   The severity of this in any particular deployment depends on factors
   outside the scope of this document, including whether the affected
   compression context is shared between security principals.  In the
   common case where a WebSocket connection carries traffic for a single
   client, both the refused and the accepted message originate from that
   client, and the content that reaches the application is content the
   client already possessed.  In that case the concern is the bypass of
   a validation control rather than disclosure of information belonging
   to another party.

   Implementations that terminate the connection when a message is
   refused are not affected by the sequence described here, because the
   affected compression context becomes unreachable.  As noted in
   Section 3.3, this property may be incidental to the implementation's
   error handling rather than a deliberate defense, and may therefore
   not survive changes to that error handling.

7.  IANA Considerations

   This document has no IANA actions.

Srivastava              Expires 14 February 2027                [Page 7]
Internet-Draft      PMCE State After Refused Messages        August 2026

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC6455]  Fette, I. and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, DOI 10.17487/RFC6455, December 2011,
              <https://www.rfc-editor.org/info/rfc6455>.

   [RFC7692]  Yoshino, T., "Compression Extensions for WebSocket",
              RFC 7692, DOI 10.17487/RFC7692, December 2015,
              <https://www.rfc-editor.org/info/rfc7692>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

8.2.  Informative References

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, DOI 10.17487/RFC1951, May 1996,
              <https://www.rfc-editor.org/info/rfc1951>.

   [RFC9204]  Krasic, C., Bishop, M., and A. Frindell, Ed., "QPACK:
              Field Compression for HTTP/3", RFC 9204,
              DOI 10.17487/RFC9204, June 2022,
              <https://www.rfc-editor.org/info/rfc9204>.

   [NETTY6209]
              Netty Project, "WebSocket permessage-deflate decoder state
              after error", GitHub issue netty/netty#6209, 2016,
              <https://github.com/netty/netty/issues/6209>.

Acknowledgements

   The comparison with QPACK arose from examining implementations of
   both protocols side by side.  The author thanks the maintainers of
   the WebSocket and HTTP/3 implementations whose source and issue
   history made that comparison possible.

Author's Address

   Aviral Srivastava
   Email: aviralyash27@gmail.com

Srivastava              Expires 14 February 2027                [Page 8]