envoyproxy/envoy

http: gRPC-web filter does not clear the route cache

Open

#5,914 opened on Feb 11, 2019

View on GitHub
 (18 comments) (0 reactions) (0 assignees)C++ (5,373 forks)batch import
bughelp wanted

Repository metrics

Stars
 (27,997 stars)
PR merge metrics
 (Avg merge 8d) (378 merged PRs in 30d)

Description

Title: gRPC-web filter does not clear the route cache

Description:

source/extensions/filters/http/grpc_web/grpc_web_filter.cc checks if the incoming request is a gRPC-web request and transforms it to gRPC proper. The transformation involves changing the content type to application/grpc. Unlike the JSON transcoding filter, gRPC-web one does not however clear the route cache making it harder to route the "upgraded" request the same way one would route a native gRPC request.

Envoy version: master @ 97d259d43a4f9b7c6d798804b4b2c9ffbd2d285d (02/11/2019)

Repro steps: Define a route explicitly matching gRPC traffic:

...
    "match": {
      "prefix": "/",
      "grpc": {}
    },
    "route": {
      "cluster": "lo_svc_grpc",
      "max_grpc_timeout": {
        "seconds": 0
      }
    },
  {
    "match": {
      "prefix": "/"
    },
    "route": {
      "cluster": "lo_svc_http",
      "timeout": {
        "seconds": 60
      }
    }
  }
...

Define the http filters in the following order:

...
    "http_filters": [
      {
        "name": "envoy.grpc_web"
      },
      {
        "name": "envoy.router"
      }]
...

Send a gRPC-web request through Envoy

Expected: the request is upgraded to gRPC proper and routed to lo_svc_grpc Actual: the request is upgraded to gRPC proper and routed to lo_svc_http (the cached route)

Why is this a bug?

  1. JSON transcoding filter clears the cache and supports such routing - consistency issue.
  2. The documentation states the filters are executed in order of their definition, since the router was defined as the last one, it should pick up the changes made by the previous filters.
  3. The routing supports matching on gRPC requests and when the gRPC-web request reaches the router, it is a gRPC request at that point and should be routed as such.

Workaround: Insert a route matching the initial request on gRPC-web explicitly:

  {
    "match": {
      "prefix": "/",
      "headers": [
        {
          "name": "content-type",
          "prefix_match": "application/grpc-web"
        }
      ]
    },
    "route": {
      "cluster": "lo_svc_grpc",
      "max_grpc_timeout": {
        "seconds": 0
      }
    }
  },

Proposed fix:

decoder_callbacks_->clearRouteCache();

after the line https://github.com/envoyproxy/envoy/blob/master/source/extensions/filters/http/grpc_web/grpc_web_filter.cc#L60

Contributor guide