[grpc-transcoder] Add option to pack unknown parameters into HttpBody extension #34999
Conversation
… extension Signed-off-by: Raven Black <ravenblack@dropbox.com>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
/retest |
2 similar comments
|
/retest |
|
/retest |
|
/lgtm api |
| // If true, query parameters that cannot be mapped to a corresponding | ||
| // protobuf field are captured in an HttpBody extension of UnknownVariableBindings. | ||
| // This overrides ``ignore_unknown_query_parameters`` and ``reject_unknown_query_parameters``. | ||
| bool capture_unknown_query_parameters = 17; |
There was a problem hiding this comment.
IMO rather than override we should reject a config which suggests doing 2 different things to unknown config params.
There was a problem hiding this comment.
That makes a transition to this new behavior difficult for us, because config and binary can be pushed separately and we're currently operating on a patch that does the new behavior with the old config.
The transition plan for me is to push a new config that specifies both the things, then push the new binary, thereby rolling onto the non-patch implementation of the behavior.
I'd be much more comfortable if I could make this change in a followup if that would be okay?
There was a problem hiding this comment.
I think API changes which make previously valid config invalid are disallowed unfortunately.
Options would be to have a runtime guard default-false for the allow behavior, and you could flip it internally, or just allow it and I will put up with it with mild crankiness as I have in the myriad other instances I've asked folks to not allow for confusing behavior and the harsh realities of production have made it impossible =P
As a compromise how about at least logging a warning below if the prior config knob is ignored?
There was a problem hiding this comment.
I started to do that, then realized it doesn't make sense - "warning, your ignore directive is being ignored in favor of another setting that does still ignore it in the way you meant".
So instead I made the protodoc less confusing about what overrides what; capture doesn't really override ignore, it just also does ignore whether you set both or not. The only thing it really overrides is the same thing ignore also overrides, and that wasn't documented on ignore, it was only documented on the overridden field, so I've made the documentation for the new field match that.
There was a problem hiding this comment.
well in that case there should be a warning for both ignore and send iff strict but there's prior art for not warning about that so I'm just going to declare myself an api grinch and LGTM this.
| // ``UnknownVariableBindings`` is added as an extension field in ``HttpBody`` if | ||
| // ``GrpcJsonTranscoder::capture_unknown_query_parameters`` is true and unknown query | ||
| // parameters were present in the request. | ||
| message UnknownVariableBindings { |
There was a problem hiding this comment.
ooc why bindings rather than UnknownQueryParams or something?
There was a problem hiding this comment.
Because renaming it would be a massive deployment pain for us, as this message is all throughout a whole bunch of client code already. :D
There was a problem hiding this comment.
On second thought, maybe it makes more sense to bind this with a different extension with a better API, have the patch and the new one both operating during the transition with the client preferring the new encoding, and that way I can do an API that isn't as bad as the original one.
| proto_config.set_capture_unknown_query_parameters(true); | ||
| JsonTranscoderConfig config(proto_config, *api_); | ||
|
|
||
| Http::TestRequestHeaderMapImpl headers{{":method", "GET"}, {":path", "/shelves?foo=bar"}}; |
There was a problem hiding this comment.
can you test with multiple query params, and multiple params with the same name?
e.g. foo=bar+dsa&eep=baz&foo=asd?
just want to make sure we're thoughtful about the lack of normalization here
There was a problem hiding this comment.
Done, along with an updated API that does key -> [values] rather than key -> value
Signed-off-by: Raven Black <ravenblack@dropbox.com>
Signed-off-by: Raven Black <ravenblack@dropbox.com>
| // If true, query parameters that cannot be mapped to a corresponding | ||
| // protobuf field are captured in an HttpBody extension of UnknownVariableBindings. | ||
| // This overrides ``ignore_unknown_query_parameters`` and ``reject_unknown_query_parameters``. | ||
| bool capture_unknown_query_parameters = 17; |
There was a problem hiding this comment.
I think API changes which make previously valid config invalid are disallowed unfortunately.
Options would be to have a runtime guard default-false for the allow behavior, and you could flip it internally, or just allow it and I will put up with it with mild crankiness as I have in the myriad other instances I've asked folks to not allow for confusing behavior and the harsh realities of production have made it impossible =P
As a compromise how about at least logging a warning below if the prior config knob is ignored?
Signed-off-by: Raven Black <ravenblack@dropbox.com>
| // If true, query parameters that cannot be mapped to a corresponding | ||
| // protobuf field are captured in an HttpBody extension of UnknownVariableBindings. | ||
| // This overrides ``ignore_unknown_query_parameters`` and ``reject_unknown_query_parameters``. | ||
| bool capture_unknown_query_parameters = 17; |
There was a problem hiding this comment.
well in that case there should be a warning for both ignore and send iff strict but there's prior art for not warning about that so I'm just going to declare myself an api grinch and LGTM this.
Commit Message: [grpc-transcoder] Add option to pack unknown parameters into HttpBody extension
Additional Description: We've been using this behavior for years, with PR #15338 as a patch. Finally getting around to trying to upstream the behavior to make it available for others, and to make it so I don't have to keep repositioning the patch. Unlike #15338 I'm also adding a configuration option so that no behavior change will occur without a corresponding configuration change.
Risk Level: Very low, guarded by a new config field.
Testing: Added positive unit tests, added conditions to other tests for the negative case.
Docs Changes: Autogen
Fixes #14710