parameters (meaning that context takeover is allowed) likely would be pretty tricky because I don't think the DEFLATE code inside Fiddler is able to reuse a single compression context across multiple operations.
If you need to manipulate this stream, you could write a FiddlerScript rule that removes this header from the WebSocket handshake and this should force the communication to fall back to uncompressed traffic.
Alternatively, on a one-off basis, you can use the Inspect As Response button to add a message to the WebSessions list:
Use F2 to enable editing of the response and add a Content-Encoding: deflate header:
Hit F2 to save the change, and you can now use the Transformer or yellow bar to decompress the text:
Note, supporting permessage-deflate without the
parameters (meaning that context takeover is allowed) likely would be pretty tricky because I don't think the DEFLATE code inside Fiddler is able to reuse a single compression context across multiple operations.
Workarounds Today: