-
Notifications
You must be signed in to change notification settings - Fork 635
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
client-only permessage-deflate still sends server headers #2671
Comments
Decorators do the job, but just feel super clunky since the option to use client or server compression was all ready specified.
|
have you tried setting |
@klemens-morgenstern yes, setting it to anything in a valid range has it sent as a header, and attempting to set it to an an invalid value gives beast errors about invalid values. Aside from the decorator above, I'm not sure how to only send the client PMD header. |
Sorry for the late response. The decorator solves it? |
While I can suppress the server headers with the decorator, it seems strange that they're sent at all when we specify no server headers in the |
I'm using boost 1.81 and beast to connect as a client to a remote websocket host, and with compression disabled, everything works fine.
This endpoint supports permessage-deflate from clients, and will also fail to upgrade if any server deflate headers are included.
If I try to add compression like so:
The upgrade headers still include
server_max_window_bits
, and the websocket upgrade is rejected. The issue seems to be in the translation betweenpd_option
and beast's internalpmd_offer
; the latter seems to support client and server at once only.Attempts to set the server window size to 0 to prevent the field from being written (looking at the source of pmd_extension.ipp) yield an invalid value error.
Would it be possible for
pmd_offer
to respect thepd_option
's server_enable flag and not send those headers?The text was updated successfully, but these errors were encountered: