Skip to content

compressor: expose compressor_library for per-route overrides#41177

Merged
KBaichoo merged 7 commits intoenvoyproxy:mainfrom
agrawroh:feat-compressor
Oct 1, 2025
Merged

compressor: expose compressor_library for per-route overrides#41177
KBaichoo merged 7 commits intoenvoyproxy:mainfrom
agrawroh:feat-compressor

Conversation

@agrawroh
Copy link
Member

Description

We have a requirement to select GZip vs. Brotli on some specific routes. In this PR, we are adding support for per-route compressor library override in the compressor filter. With this change, routes would be able to specify a different compressor library (e.g., gzip, brotli) via the compressor_library field on a per-route basis.

This would allow different routes to use different compression algorithms and settings while maintaining the same filter configuration.


Commit Message: compressor: expose compressor_library for per-route overrides
Additional Description: Added support to allow different routes to use different compression algorithms and settings while maintaining the same filter configuration.
Risk Level: Low
Testing: Added Unit + Integration Tests
Docs Changes: Added
Release Notes: Added

@repokitteh-read-only
Copy link

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #41177 was opened by agrawroh.

see: more, trace.

@repokitteh-read-only
Copy link

CC @envoyproxy/api-shepherds: Your approval is needed for changes made to (api/envoy/|docs/root/api-docs/).
envoyproxy/api-shepherds assignee is @abeyad
CC @envoyproxy/api-watchers: FYI only for changes made to (api/envoy/|docs/root/api-docs/).

🐱

Caused by: #41177 was opened by agrawroh.

see: more, trace.

@agrawroh agrawroh force-pushed the feat-compressor branch 2 times, most recently from d6b7121 to 946d93b Compare September 23, 2025 00:39
Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
@agrawroh agrawroh marked this pull request as ready for review September 23, 2025 01:49
Copy link
Contributor

@abeyad abeyad left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/lgtm api

Copy link
Member

@wbpcode wbpcode left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the contribution. One high level comment to start the work :)

Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
@KBaichoo
Copy link
Contributor

I think this was stuck waiting on a reviewer from the compressor extension side.

As I am one of the owners there...

/assign @KBaichoo

Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Copy link
Contributor

@KBaichoo KBaichoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

/wait

return std::make_shared<CompressorPerRouteFilterConfig>(proto_config);
Server::Configuration::ServerFactoryContext& context,
ProtobufMessage::ValidationVisitor& validator) {
// Create a temporary factory context that wraps the generic factory context.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you help me understand the changes in this file / why they're needed?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's needed because compressor library factories require FactoryContext but in the per-route config we only get ServerFactoryContext. If you have another recommendation, I can look at a reference and do that instead.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT from the public compressor filters usage -- it seems like these only use the serverFactoryContext if they use anything beyond the configuration proto.

I'd be surprised if we needed anything listener related given our impl here for listener is effectively NOPed. Does it make more sense to downgrade the compressor filter to only need a GenericFactoryContext instead? It'd get rid of some of the NOP stuff we end up working around.

It might just have incidentally been added as the arg for the ctor in #20434

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see. Thanks for sharing the reference.

Are you okay if we keep the current approach for now and follow-up with the interface refactor rather than doing the full refactor now by changing all the compressor factories?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we can do this as a follow up

@KBaichoo
Copy link
Contributor

would you also be able to update the docs: https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/compressor_filter#per-route-configuration with this since it's pretty neat

Signed-off-by: Rohit Agrawal <rohit.agrawal@databricks.com>
Copy link
Contributor

@KBaichoo KBaichoo left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks otherwise LGTM

return std::make_shared<CompressorPerRouteFilterConfig>(proto_config);
Server::Configuration::ServerFactoryContext& context,
ProtobufMessage::ValidationVisitor& validator) {
// Create a temporary factory context that wraps the generic factory context.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT from the public compressor filters usage -- it seems like these only use the serverFactoryContext if they use anything beyond the configuration proto.

I'd be surprised if we needed anything listener related given our impl here for listener is effectively NOPed. Does it make more sense to downgrade the compressor filter to only need a GenericFactoryContext instead? It'd get rid of some of the NOP stuff we end up working around.

It might just have incidentally been added as the arg for the ctor in #20434

@KBaichoo KBaichoo merged commit e3e4f29 into envoyproxy:main Oct 1, 2025
24 of 25 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants