feat(websocket): support per-message compression (RFC7692) (IDFGH-16651)

[huming2207]

Description

This PR is for add the support for per-message compression (deflate) for websocket client.

Please note that this PR is depends on its parent PR in ESP-IDF: espressif/esp-idf#17746

Related

See:

• feat(transport_ws): add support for per-message compression (RFC7692) handshakes (IDFGH-16647) esp-idf#17746
• WebSocket client per-message compression (RFC7692) support (IDFGH-16641) #912

Testing

I will test with a Node.js and/or Bun.js server and see if it actually works or not.

Checklist

Before submitting a Pull Request, please ensure the following:

• 🚨 This PR does not introduce breaking changes.
• All CI checks (GH Actions) pass.
• Documentation is updated as needed.
• Tests are updated or added as necessary.
• Code is well-commented, especially in complex areas.
• Git history is clean — commits are squashed to the minimum necessary.

[cursor]

This PR is being reviewed by Cursor Bugbot

Details

Your team is on the Bugbot Free tier. On this plan, Bugbot will review limited PRs each billing cycle for each member of your team.

To receive Bugbot reviews on all of your PRs, visit the Cursor dashboard to activate Pro and start your 14-day free trial.

[huming2207]

I guess I will change this to a draft PR first until the parent PR espressif/esp-idf#17746 is merged to ESP-IDF.

[gabsuren]

@huming2207
Thank you for your contribution!

Before proceeding, I wanted to point out that libwebsockets, which is already integrated into esp-protocols, natively supports per-message compression (RFC 7692).

A few questions to help evaluate the best approach:

1. Have you evaluated whether libwebsockets' existing compression support could meet your needs?
2. Are there specific limitations or advantages that prevent using libwebsockets for this use case?

Best regards,
Suren

[huming2207]

Hi @gabsuren

Thanks for your reply. The major reason for why we are not using libwebsocket are because:

• We had a look in libwebsocket a few years ago, probably around 2018, and I wasn't quite satisified with libwebsocket so we chose not to use it. Reasons are:
  • Back then the libwebsocket on ESP32 does not have a few features like TLS connections. Later they added the support for TLS but required to use their own mbedTLS. Then only until 2025 (or 2024?) you guys (Espressif) ported the libwebsocket to get TLS works properly.
  • The library itself is also a bit too heavy for a microcontroller. My understanding is it's more like a framework for network protocols. We don't want a turn-key framework solution. We just want a WebSocket library that does WS only, and the rest should be done by our own.
• We have written an internal networking management library for ESP32 over the years for our products. It's a library for managing the state of the 4G modem, WiFi and ethernet, plus the state of the network protocol clients. It depends on esp_websocket_client for all high-level websocket access, and tcp_transport for all low-level stuff like proxy support.
  • We have partially open sourced some key parts of our networking manager library. For example, our library also supports WebSocket over HTTP proxy via my library. Here's the repo: https://github.com/huming2207/esp_tcp_transport_addons .
  • We have no time to move to libwebsocket for our network manager library for now. It's just waste of time for us. I'd rather make changes and get our stuff working first, then consider submit a PR to upstream (like this one for RFC7692 support).

I know you may ask what if later we somehow don't want to use Espressif chips any more. If that's the case then indeed we can't use esp_websocket_client any more. But that's for later to discuss. 😅 For now we are happy with Espressif's ecosystem. For example if we want to move to a Linux-based application processor solution, we might just use Node.js/Bun.js or Python for scripting or write a new Rust-based solution instead.

Regards,
Jackson

[huming2207]

@gabsuren As you guys stated in the libwebsocket README:

It consumes approximately 300 kB of program memory.

It's just too much. It won't even run on ESP8684. 😅

I also remember back in 2018 this thing will blow up the stack easily. Therefore from our impression this thing isn't designed for small embedded systems.