-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Proposed "snappy" vs "x-snappy-framed" content-type confusion #12825
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
Changes from all commits
e3698d8
81cb6fe
dd4f97d
a73dd08
4ecfa24
7621d8c
db48f79
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,37 @@ | ||
# Use this changelog template to create an entry for release notes. | ||
|
||
# One of 'breaking', 'deprecation', 'new_component', 'enhancement', 'bug_fix' | ||
change_type: enhancement | ||
|
||
# The name of the component, or a single word describing the area of concern, (e.g. otlpreceiver) | ||
component: confighttp | ||
|
||
# A brief description of the change. Surround your text with quotes ("") if it needs to start with a backtick (`). | ||
note: "Fix handling of `snappy` content-encoding in a backwards-compatible way" | ||
|
||
# One or more tracking issues or pull requests related to the change | ||
issues: [10584, 12825] | ||
|
||
# (Optional) One or more lines of additional information to render under the primary note. | ||
# These lines will be padded with 2 spaces and then inserted directly into the document. | ||
# Use pipe (|) for multiline entries. | ||
subtext: | | ||
The collector used the Snappy compression type of "framed" to handle the HTTP | ||
content-encoding "snappy". However, this encoding is typically used to indicate | ||
the "block" compression variant of "snappy". This change allows the collector to: | ||
- The server endpoints will now accept "x-snappy-framed" as a valid | ||
content-encoding. | ||
- Client compression type "snappy" will now compress to the "block" variant of snappy | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Please don't do this, since as @jpkrohling explained, this will break existing servers that are not updated. First we need to add support for both on both server/client. The "hack" for the server can also go now. Then wait for few versions until you can change the client. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What specific behavior do we want here? I tried to avoid breaking receiving as right now that felt like the pain point. Should we add x-snappy-framed as a type first, and then at some point later switch the compression to use non-framed for "snappy"? If I changed the PR to do this, would this satisfy the path forward and start the ball rolling? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Your PR avoids breakage in the situation where the receiver is updated but not the sender (and that's great!), but not in the opposite scenario: if the sender is updated but not the receiver, the sender will switch to block mode, and the receiver will not accept it. Of course, the sender can "just" update their config to explicitly switch back to framed mode, but this could still be a source of breakage. Bogdan's suggestion is to add the protocol detection in the receiver (and the explicit framed mode) now, but to wait a few versions before switching "snappy" to use the block mode. This means that breakage will only occur if the sender gets both updates and the receiver gets none, which is less likely. I think one additional possibility, to ease the transition and minimize how much code change needs to be postponed, would be to put the switch of snappy from framed to block mode behind an Alpha (off by default) feature gate, and add a warning log in confighttp when "snappy" is used with the gate disabled. Then later, we will only need to switch it to Beta (this is where the breaking change would be). What do you think? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I like this suggestion. For the components that need to use snappy encoding/decoding correctly, we just need to document that the new feature gate is required for them to work. I don't see anybody else requiring this besides the prometheus remote-write receiver, which is not even an alpha component yet, so it sounds reasonable There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. +1 with all the comments. |
||
instead of "framed". If you want the old behavior, you can set the | ||
compression type to "x-snappy-framed". | ||
- When a server endpoint receives a content-encoding of "snappy", it will | ||
look at the first bytes of the payload to determine if it is "framed" or "block" snappy, | ||
and will decompress accordingly. This is a backwards-compatible change. | ||
- In a future release, this checking behavior may be removed. | ||
|
||
# Optional: The change log or logs in which this entry should be included. | ||
# e.g. '[user]' or '[user, api]' | ||
# Include 'user' if the change is relevant to end users. | ||
# Include 'api' if there is a change to a library API. | ||
# Default: '[user]' | ||
change_logs: [user] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely not
enhancement
, this is a complete breaking change.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we keep it as
enhancement
if we switch the strategy to using feature flags?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it would no longer be a breaking change if we delay the client changes (unless there are bugs in the protocol detection).