Add upstream HTTP filter support to http-filter-cc example

[Copilot]

Adds upstream filter chain support to the http-filter-cc example, demonstrating how to register a filter for both downstream and upstream use. Previous attempt (#1047) failed due to redefinition errors from duplicate REGISTER_FACTORY calls.

Changes

factory/factory.cc

• Add type alias to enable dual registration without symbol conflicts:

using UpstreamFilterFactory = FilterFactory;

REGISTER_FACTORY(FilterFactory, Server::Configuration::NamedHttpFilterConfigFactory);
REGISTER_FACTORY(UpstreamFilterFactory, Server::Configuration::UpstreamHttpFilterConfigFactory);

• Update createRouteSpecificFilterConfigTyped return type to absl::StatusOr<Router::RouteSpecificFilterConfigConstSharedPtr> for consistency with current Envoy API

envoy.yaml

• Add upstream filter chain configuration in cluster typed_extension_protocol_options:

clusters:
- name: service_backend
  typed_extension_protocol_options:
    envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
      http_filters:
      - name: sample
        typed_config:
          "@type": type.googleapis.com/sample.Decoder
          key: "x-upstream-header"
          val: "upstream-value"
      - name: envoy.filters.http.upstream_codec

example.rst

• Document upstream filter functionality with usage examples and common use cases (authentication, metrics, request transformation)
• Explain dual registration pattern with type alias requirement
• Add reference to upstream HTTP filter documentation

verify.sh

• Add test case for upstream filter header injection

This follows the standard pattern used in Envoy's test filters (see test/integration/filters/crash_filter.cc, add_body_filter.cc, etc.).

Original prompt

Background

This PR adds upstream HTTP filter support to the http-filter-cc example, as suggested by @ravenblackx in #1041. The previous attempt in #1047 failed because the agent incorrectly handled the REGISTER_FACTORY macro - it encountered a redefinition error and instead of fixing it properly, it removed the upstream registration entirely.

What needs to be done

1. Fix factory.cc with correct dual registration pattern

The current factory.cc only registers the filter for downstream use. To support both downstream AND upstream filter chains, you need to follow the pattern used throughout Envoy's codebase (see test/integration/filters/ for many examples):

Current code (WRONG - only downstream):

REGISTER_FACTORY(FilterFactory, Server::Configuration::NamedHttpFilterConfigFactory);

Required fix (CORRECT - both downstream and upstream):

// Type alias is REQUIRED to avoid redefinition error
using UpstreamFilterFactory = FilterFactory;

REGISTER_FACTORY(FilterFactory, Server::Configuration::NamedHttpFilterConfigFactory);
REGISTER_FACTORY(UpstreamFilterFactory, Server::Configuration::UpstreamHttpFilterConfigFactory);

The type alias is critical - without it, REGISTER_FACTORY creates duplicate static symbols and you get redefinition errors. This is the standard pattern used in Envoy.

Also update the return type of createRouteSpecificFilterConfigTyped to use absl::StatusOr:

absl::StatusOr<Router::RouteSpecificFilterConfigConstSharedPtr>
createRouteSpecificFilterConfigTyped(const sample::DecoderPerRoute& proto_config,
                                      Server::Configuration::ServerFactoryContext&,
                                      ProtobufMessage::ValidationVisitor&) override {
  return std::make_shared<PerRouteFilterConfig>(proto_config);
}

2. Add upstream filter configuration to envoy.yaml

Add the upstream filter to the cluster configuration in http-filter-cc/envoy.yaml:

clusters:
- name: service_backend
  # ... existing config ...
  typed_extension_protocol_options:
    envoy.extensions.upstreams.http.v3.HttpProtocolOptions:
      "@type": type.googleapis.com/envoy.extensions.upstreams.http.v3.HttpProtocolOptions
      explicit_http_config:
        http_protocol_options: {}
      http_filters:
      - name: sample
        typed_config:
          "@type": type.googleapis.com/sample.Decoder
          key: "x-upstream-header"
          val: "upstream-value"
      - name: envoy.filters.http.upstream_codec
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.http.upstream_codec.v3.UpstreamCodec

3. Update example.rst documentation

Add a new step documenting the upstream filter functionality:

• Explain that the filter runs in upstream filter chains
• Show how to test it with curl
• Explain use cases for upstream filters
• Update the "How it works" section to correctly explain the dual registration pattern (NOT the incorrect claim that DualFactoryBase "automatically" handles it)
• Add reference to upstream HTTP filter documentation in the "See also" section

4. Update verify.sh to test upstream filter

Add a test case:

run_log "Test upstream filter header"
responds_with \
    '"x-upstream-header": "upstream-value"' \
    "http://localhost:${PORT_PROXY}/"

Key References

From Envoy's source/docs/upstream_filters.md:

Add using UpstreamMyFilterFactory = MyFilterFactory; in your config.h file and REGISTER_FACTORY(UpstreamMyFilterFactory, Server::Configuration::UpstreamHttpFilterConfigFactory); to your config.cc file.

Examples of this pattern in Envoy's test filters:

• test/integration/filters/crash_filter.cc
• test/integration/filters/add_body_filter.cc
• test/integration/filters/async_upstream_filter.cc

Acceptance Criteria

• factory.cc has the type alias using UpstreamFilterFactory = FilterFactory;
• factory.cc has both REGISTER_FACTORY calls (downstream and upstream)
• factory.cc uses absl::StatusOr return type for createRouteSpecificFilterConfigTyped
• envoy.yaml has upstream filter configuration in the cluster
• example.rst documents upstream filter support correctly
• verify.sh tests the upstream filter header
• The example builds and all tests pass

This pull request was created from Copilot chat.

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.